Die Entwicklung einer REST-API in WordPress ermöglicht den sicheren Datenaustausch zwischen Ihrer Website, einem separaten Frontend und externen Diensten via JSON. Sie können Standard-WordPress-Routen verwenden oder einen eigenen Endpunkt erstellen und dabei Datenstruktur, Anfragemethoden und Zugriffsregeln im Voraus definieren.

Inhalt

In diesem Leitfaden erfahren Sie, wann eine REST-API benötigt wird, wie Sie eine Route entwerfen und konfigurieren. permission_callback und wählen Sie eine Autorisierungsmethode. Wir behandeln außerdem die Frontend-Konnektivität, den Katalogzugriff über die API, die Fehlerprüfung, das Caching und die Versionsverwaltung unter Berücksichtigung der Einschränkungen Ihres Themes, Ihrer Plugins und der installierten WordPress-Version.

Vor Änderungen sollten Sie mit einer Testumgebung arbeiten und ein Backup der Website erstellen: Die Kompatibilität der Lösung muss mit einer spezifischen Konfiguration getestet werden. Jeder Endpunkt, der Daten empfängt, muss Benutzerberechtigungen überprüfen, Eingabewerte validieren und Ausgaben sicher maskieren.

Die Rolle der API im Zusammenhang mit Themes, Blöcken und Plugins wird beschrieben in Überprüfung der individuellen WordPress-Entwicklung. Nachfolgend finden Sie den Routen- und Zufahrtsplan.

Wann sollte man die WordPress REST-API verwenden?

Die REST-API eignet sich, wenn Sie WordPress-Daten von einer separaten Anwendung, Schnittstelle oder einem externen System abrufen oder ändern müssen. Der Server liefert strukturiertes JSON, sodass die Inhalte unabhängig von den Website-Templates verwendet werden können. Wenn die Aufgabe vollständig durch ein Theme und Standard-PHP-Templates gelöst ist, würde das Hinzufügen einer API-Schicht die Architektur nur unnötig verkomplizieren.

Integrierte Routen und benutzerdefinierte Endpunkte

Die WordPress REST API bietet integrierte Routen für Beiträge, Seiten, Kategorien, Kommentare, Mediendateien und weitere unterstützte Entitäten. So kann eine Anwendung beispielsweise eine Liste veröffentlichter Beiträge anfordern, einen einzelnen Beitrag anhand seiner ID abrufen oder Filter- und Paginierungsparameter übergeben.

Eine Route definiert die Adresse einer Ressource. Ein Endpunkt verknüpft eine Route mit einer bestimmten HTTP-Methode und einem Handler: GET wird typischerweise zum Lesen, POST zum Erstellen, PUT oder PATCH zum Ändern und DELETE zum Löschen verwendet. Eine einzelne Route kann mehrere Operationen verarbeiten.

Verwenden Sie zunächst die integrierten Routen, sofern deren Struktur für die Aufgabe geeignet ist. Dies reduziert den Umfang des benutzerdefinierten Codes und vereinfacht die zukünftige Wartung. Für einen benutzerdefinierten Beitragstyp wird der Zugriff über die REST-API separat konfiguriert: Bei der Registrierung wird der entsprechende Parameter festgelegt. show_in_rest. Prüfen Sie die Kompatibilität mit der von Ihnen verwendeten WordPress-Version, dem Theme und den Plugins.

WordPress REST API benutzerdefinierter Endpunkt Dies ist erforderlich, wenn Standardressourcen Ihre Geschäftslogik nicht abbilden. Beispielsweise müssen Sie Informationen aus mehreren Entitäten kombinieren, einen berechneten Bestellstatus zurückgeben oder Daten aus einem internen System empfangen. Erstellen Sie jedoch keine benutzerdefinierte Route nur zum Umbenennen von Feldern: Prüfen Sie zunächst, ob Sie eine Standardantwort verwenden oder eine bestehende Ressource korrekt erweitern können.

Frontend- und Integrationsszenarien

WordPress REST API Frontend-Verbindung Es ist sinnvoll, wenn die öffentliche Schnittstelle separat von WordPress implementiert wird, beispielsweise als Single-Page-Anwendung (SPA), mobile App oder Online-Shop auf einem anderen Technologie-Stack. In diesem Fall ist WordPress für die Speicherung und Verwaltung der Inhalte zuständig, während das Frontend JSON-Daten anfordert und Seiten unabhängig generiert.

Typische Anwendungsfälle:

Datenübertragung an ein separates Frontend. Die Redakteure arbeiten im Admin-Panel, und die Anwendung empfängt Titel, Texte, Bilder und Metadaten über eine API.
Das Verzeichnis wird über die API gelesen. Der externe Shop fragt Artikel, Kategorien und verfügbare Funktionen ab. Die Datenzusammensetzung hängt von der Katalogimplementierung und deren Plugin-Funktionen ab.
Austausch mit einem externen System. Das CRM-System, der Analysedienst oder das interne Dashboard empfängt autorisierte Daten oder sendet Änderungen an WordPress.
Teilweise Aktualisierung der Benutzeroberfläche. Ein separater Seitenblock lädt aktuelle Beiträge, ohne dass die gesamte Seite neu geladen werden muss.

Vor der Wahl einer API-Architektur sollten Sie das Volumen und die Häufigkeit der Anfragen, den Bedarf an Datenänderungen, Caching-Anforderungen und die Zielgruppe berücksichtigen. Für eine kleine Content-Website kann eine REST-API überdimensioniert sein. Bei mehreren Schnittstellen, die eine einzige Datenquelle nutzen, hilft sie zwar, Inhalt und Präsentation zu trennen, erfordert aber eine sorgfältige Abwägung des Antwortformats und der Integrationsgrenzen.

Route und Daten entwerfen

Bevor Sie mit dem Programmieren beginnen, definieren Sie den API-Vertrag: die Routenadresse, die HTTP-Methode, die Eingabeparameter und die JSON-Antwortstruktur. Dieser Ansatz vereinfacht die Entwicklung der WordPress REST-API und trägt zur separaten Abstimmung von Frontend und Backend bei.

Methode, Schema und Antwort

Eine Route besteht aus einem Namensraum und einem Pfad. Zum Beispiel könnte man für ein Verzeichnis Folgendes verwenden: /wp-json/project/v1/catalog, Wo Projekt/v1 — Namespace mit Version und /Katalog — Route. Ein Endpunkt ist eine Kombination aus einer Route und einer spezifischen HTTP-Methode.

ERHALTEN — Lesen eines Verzeichnisses oder eines einzelnen Eintrags;
POST — eine Ressource erstellen oder einen Vorgang starten;
SETZEN Und PATCH — vollständige oder teilweise Aktualisierung;
LÖSCHEN — Löschen einer Ressource.

Für ein bestimmtes Frontend sollten die Feldnamen und -typen im Voraus festgelegt werden. Beispielsweise könnte eine Katalogantwort Folgendes enthalten: Artikel, Seite, pro Seite Und gesamt. Übertragen Sie nicht alle Datensatzfelder «nur für den Fall»: Dies erhöht die Antwortgröße und kann interne Daten offenlegen.

Bei einem großen Katalog empfiehlt sich die Verwendung von Paginierung, Filtern und einer stabilen Sortierung. Für häufig abgerufene und selten geänderte Daten ist das Zwischenspeichern von GET-Antworten ratsam. Eine Version mit Namensraum ermöglicht eine spätere Veröffentlichung. Projekt/v2, ohne den Vertrag des bereits verbundenen Frontends zu ändern.

Eine einfache Registrierung einer öffentlichen Leseroute könnte folgendermaßen aussehen:

add_action( 'rest_api_init', function () {
    register_rest_route( 'project/v1', '/catalog', array(
        'methods'  => WP_REST_Server::READABLE,
        'callback' => 'project_get_catalog',
        'permission_callback' => '__return_true',
        'args' => array(
            'page' => array(
                'type'    => 'integer',
                'default' => 1,
                'minimum' => 1,
            ),
            'per_page' => array(
                'type'    => 'integer',
                'default' => 20,
                'minimum' => 1,
                'maximum' => 100,
            ),
        ),
    ) );
} );

__return_true Nehmen wir an, es ist nur für die wirklich öffentliche Lesbarkeit bestimmt. Um Daten zu ändern oder auf private Felder zuzugreifen, benötigen Sie eine separate Anwendung. permission_callback Führen Sie Benutzertests durch. Bevor Sie Code hinzufügen, arbeiten Sie in einer Testumgebung und erstellen Sie ein Backup. Die Kompatibilität muss mit der verwendeten WordPress-Version, dem Theme und den Plugins getestet werden.

Validierung der Eingabedaten

Ein benutzerdefinierter WordPress-REST-API-Endpunkt sollte Anfrageparametern nicht blind vertrauen. Prüfen Sie zunächst Format und zulässigen Wertebereich und normalisieren Sie anschließend die Werte. Die Validierung beantwortet die Frage «Sind die Daten akzeptabel?», und die Bereinigung gewährleistet ihre Sicherheit.

Ein Kategoriestringfilter könnte beispielsweise wie folgt beschrieben werden:

'category' => array(
    'type'              => 'string',
    'required'          => false,
    'validate_callback' => function ( $value ) {
        return is_string( $value ) && strlen( $value ) <= 100;
    },
    'sanitize_callback' => 'sanitize_key',
),

Wählen Sie die Verarbeitungsfunktion anhand der Bedeutung des Feldes aus: sanitize_text_field() geeignet für normalen Text, sanitize_key() — für Kennungen und Slugs, absint() — für nicht-negative ganze Zahlen. SQL-Parameter können nicht durch Zeichenkettenverkettung in eine Abfrage eingefügt werden; verwenden Sie stattdessen die WordPress-API oder vorbereitete Anweisungen.

Formuliere die Antwort explizit und gib sie zurück. rest_ensure_response() oder WP_REST_Response. Numerische Bezeichner in Zahlen umwandeln und HTML nur dann einbinden, wenn dies vertraglich vorgeschrieben ist. Einen Fehler zurückgeben. WP_Fehler mit verständlichem Maschinencode und korrektem HTTP-Status, ohne Dateipfade, SQL-Abfragen und andere interne Informationen preiszugeben.

Vor der Implementierung sollten Sie sich auf eine Beispielanfrage und eine JSON-Antwort einigen. Dies ist besonders wichtig bei der Frontend-Integration der WordPress REST API: Das Kundenteam kann sich so auf ein stabiles Schema anstatt auf die internen Abläufe von WordPress verlassen.

Berechtigungen und Autorisierung einrichten

In WordPress legt die Authentifizierung fest, wer die Anfrage sendet, während die Autorisierung bestimmt, ob dieser Benutzer eine bestimmte Aktion ausführen darf. Für jede Route werden separate öffentliche Operationen, das Lesen privater Daten und das Ändern von Inhalten definiert. CORS, Nonces und versteckte URLs allein ersetzen die Berechtigungsprüfung nicht.

Öffentliche und private Daten

Der öffentliche Endpunkt eignet sich für einen veröffentlichten Katalog, eine Kategorienliste oder andere Informationen, die den Besuchern der Website bereits zur Verfügung stehen. permission_callback Eine solche Route kann genutzt werden. __return_true, Aber nur, wenn die Offenlegung tatsächlich zulässig ist. Geben Sie in Ihrer Antwort keine Servicefelder, internen Kommentare, persönlichen Daten oder Informationen über unveröffentlichte Aufzeichnungen an.

Abgeschlossene Transaktionen erfordern eine Identitätsprüfung. Die gewählte Methode hängt vom Standort und den Zugriffsrechten des Kunden ab.

Autorisierungsmethode	Szenario	Einschränkung
Cookie-Authentifizierung und REST-Nonce	Anfragen vom WordPress-Adminbereich oder Frontend eines bereits angemeldeten Benutzers	Nonces konzentrieren sich auf Interaktionen vor Ort und reduzieren das Risiko von CSRF, ersetzen aber nicht die Überprüfung der Fähigkeiten.
Anwendungspasswort	Serverintegration, Datenimport, WordPress-Verbindung mit einem separaten, vertrauenswürdigen Dienst	Zugangsdaten sollten ausschließlich über HTTPS übertragen werden. Das Geheimnis sollte nicht in öffentlichem JavaScript oder einem Repository gespeichert werden.
Zusätzliches Schema über Plugin	Architektur mit OAuth oder einem anderen Protokoll, falls dies durch die Integration erforderlich ist	Kompatibilität und Sicherheit hängen vom jeweiligen Plugin, Theme und der WordPress-Version ab und erfordern separate Tests.

Bei der Verwendung des Szenarios «WordPress REST API-Frontend-Verbindung» ist zwischen Browser- und Serveranfragen zu unterscheiden. Wenn ein separates Frontend auf ein öffentliches Verzeichnis zugreift, ist möglicherweise keine Authentifizierung erforderlich. Für administrative Aktionen ist der Zugriff auf WordPress über die serverseitige Anwendungsschicht sicherer: So wird das Anwendungspasswort dem Benutzer nicht angezeigt. Die CORS-Einstellung erlaubt dem Browser lediglich den Zugriff auf eine andere Domain und gewährt keine Lese- oder Änderungsberechtigungen.

Überprüfung der Fähigkeiten

Jeder benutzerdefinierte Endpunkt der WordPress REST API muss einen aussagekräftigen Namen haben. permission_callback. Überprüfen Sie die Fähigkeiten einer Rolle nicht anhand ihres Namens, sondern anhand ihrer current_user_can(). Dieser Ansatz berücksichtigt das standardmäßige WordPress-Berechtigungssystem sowie Änderungen, die von Plugins vorgenommen werden.

Wählen Sie eine Berechtigung basierend auf dem Vorgang aus. Um einen bestimmten Datensatz zu bearbeiten, übergeben Sie dessen ID an die Prüfung. current_user_can('edit_post', $post_id). Zum Löschen verwenden Sie das entsprechende Löschrecht und für allgemeine administrative Einstellungen die Berechtigung, die für diesen Vorgang tatsächlich erforderlich ist. Verwenden Sie nicht manage_options automatisch auf alle geschlossenen Routen: Dies könnte Redakteure unnötig einschränken und gleichzeitig ein ungenaues Zugriffsmodell verbergen.

Wenn der Zugriff verweigert wird, kehren Sie zurück WP_Fehler Mit einem eindeutigen Fehlercode und dem korrekten HTTP-Statuscode (typischerweise 401 für fehlende Authentifizierung oder 403 für einen Benutzer ohne die erforderlichen Berechtigungen). Geben Sie in der Nachricht keine Tokens, SQL-Abfragen, Serverpfade oder andere interne Informationen preis.

Öffentlichen Zugriff erst nach Prüfung der Zusammensetzung der JSON-Antwort gewähren.
Prüfen Sie die Leistungsfähigkeit jeder Operation, einschließlich des Lesens von Entwürfen und des Änderns von Datensätzen.
Überprüfen Sie die Eingabeparameter und bereinigen Sie die Daten vor dem Speichern.
Daten müssen maskiert werden, bevor sie anschließend im entsprechenden HTML-, URL- oder anderen Kontext ausgegeben werden.
Geheimnisse dürfen nur über HTTPS übertragen und außerhalb des Client-Codes gespeichert werden.
Bieten Sie Integrationen mit separaten Anmeldeinformationen an, die über die minimal erforderlichen Rechte verfügen und die Möglichkeit bieten, diese zu widerrufen.
Testen Sie die Implementierung nach einer Datensicherung in einer Testumgebung; ohne Tests kann die Kompatibilität des Themes, der Plugins und der WordPress-Version nicht gewährleistet werden.

Überprüfen Sie den Endpunktvorgang

Testen Sie den Endpunkt in einer Testumgebung, bevor Sie ihn mit einem Produktivsystem oder einem externen System verbinden. Stellen Sie sicher, dass die Route die vorgesehene HTTP-Methode akzeptiert, gültiges JSON zurückgibt, Parameter korrekt verarbeitet und keine Daten an unbefugte Benutzer weitergibt.

Antwort- und Fehlercodes

Beginnen Sie mit einem positiven Szenario: Senden Sie eine gültige Anfrage mit zulässigen Parametern und den entsprechenden Anmeldeinformationen. Prüfen Sie nicht nur den Antworttext, sondern auch den HTTP-Statuscode, den Content-Type-Header, die JSON-Struktur und das Vorhandensein der erforderlichen Felder. Clientseitiger Code sollte sich nicht auf die zufällige Feldreihenfolge oder den Text von Fehlermeldungen verlassen.

Reproduzieren Sie anschließend die Fehlerabfragen nacheinander:

ohne Autorisierung und mit ungültigen Anmeldeinformationen;
von einem Benutzer ohne Rechte;
mit fehlendem erforderlichen Parameter;
mit ungültigem Parametertyp, -format oder -wert;
mit einem nicht existierenden Objektbezeichner;
mit nicht unterstützter HTTP-Methode;
mit beschädigtem JSON im Anfragetext.

Ein Fehlercode 400 deutet in der Regel auf eine ungültige Anfrage hin, 401 auf fehlende Autorisierung, 403 auf unzureichende Berechtigungen, 404 auf eine unbekannte Route oder Ressource und 405 auf eine nicht unterstützte Methode. Ein Fehlercode 500 erfordert eine Überprüfung der Serverlogik. Der tatsächliche Status kann von der Endpunktimplementierung, den Sicherheits-Plugins, dem Webserver und dem Proxy abhängen. Prüfen Sie daher unbedingt die tatsächliche Antwort für Ihre spezifische Konfiguration.

Bei einem benutzerdefinierten Endpunkt sollten Sie aussagekräftige Fehler zurückgeben, beispielsweise über das WP_Error-Objekt mit einem für Menschen lesbaren Maschinencode, einer Fehlermeldung und dem HTTP-Statuscode. Vermeiden Sie es, SQL-Abfragen, Dateipfade, Tokens, Aufruflisten und andere interne Informationen in die Antwort aufzunehmen. WordPress REST API Frontend-Verbindungen Bieten Sie eine Behandlung für Timeouts, ungültiges JSON und Antworten ohne erwartete Felder an, nicht nur für Erfolgsmeldungen.

Protokolle und Testumgebung

Änderungen sollten zunächst auf der Testumgebung implementiert werden, nachdem ein Backup erstellt wurde. Ohne Überprüfung der WordPress-Version, des aktiven Themes, der Plugins, der PHP-Konfiguration und der Servereinstellungen kann die Kompatibilität nicht gewährleistet werden. Besonders wichtig ist die Neukonfiguration von Cache, Permalinks und Sicherheitsfunktionen, die REST-Anfragen beeinflussen.

Für Diagnosezwecke in einer Testumgebung können Sie die WordPress-Protokollierung vorübergehend aktivieren. Zeigen Sie Besuchern keine technischen Fehlermeldungen an und deaktivieren Sie den Debug-Modus auf der Live-Website. Die Protokolldatei kann personenbezogene Daten, Abfrageparameter und Konfigurationsfragmente enthalten. Beschränken Sie daher den Zugriff darauf und löschen Sie die Diagnoseeinträge nach dem Testen.

Protokollieren Sie in Ihren Logs die Anfragezeit, die Route, die HTTP-Methode, den Status und die interne Vorgangs-ID. Passwörter, Anwendungspasswörter, Cookies, der Authorization-Header und der vollständige Inhalt personenbezogener Daten dürfen nicht protokolliert werden. Falls die Anfrage über ein separates Frontend läuft, korrelieren Sie dessen Log mit den WordPress-Logs mithilfe einer sicheren ID.

Prüfen Sie beim Lesen des Katalogs zusätzlich auf leere Selektionen, Paginierung, Filter, große verfügbare Datenmengen und das Verhalten des Caches. Führen Sie nach der Behebung dieser Probleme alle Abfragen erneut aus: Ein erfolgreiches Ergebnis bestätigt nicht, dass die Zugriffsbeschränkungen und die Fehlerbehandlung weiterhin korrekt sind.

Unterstützung und Einschränkungen

Sobald ein Endpunkt eingerichtet ist, stellt er eine stabile Verbindung zwischen WordPress und dem externen System dar. Änderungen an Feldnamen, Datumsformaten oder der JSON-Struktur können die Frontend-, Mobil-App- oder Importfunktionen beeinträchtigen. Daher umfasst die API-Unterstützung Kompatibilitätsüberwachung, Versionsverwaltung, Caching und Fehlerüberwachung.

Versionierung und Kompatibilität

Geben Sie die Version im Routen-Namensraum an, zum Beispiel Projekt/v1. Falls eine inkompatible Änderung erforderlich ist, erstellen Sie Projekt/v2, und behalten Sie vorübergehend die alte Version für bestehende Kunden bei. Das Hinzufügen eines optionalen Feldes ist in der Regel sicherer als das Löschen oder Umbenennen eines bereits verwendeten Feldes.

Dokumentieren Sie den Endpunktvertrag: HTTP-Methode, Parameter, Pflichtfelder, JSON-Struktur, mögliche Antwortcodes und Zugriffsanforderungen. Geben Sie insbesondere an, welche Werte leer sein dürfen. Dies hilft, einen Integrationsfehler von einer gültigen Antwort ohne Daten zu unterscheiden.

Versprechen Sie keine Kompatibilität, ohne die WordPress-Version, das aktive Theme und die Plugins zu prüfen. Erweiterungen können eigene Routen registrieren, Beitragstypen ändern, die REST-API einschränken oder die Datenformatierung beeinflussen. Testen Sie Aktualisierungen daher zunächst auf einer Testumgebung mit der aktuellsten Konfiguration und einem Backup.

Datenvolumen und Caching

Beim Abrufen eines Katalogs über die API sollte nicht das gesamte Produktarray in einer einzigen Antwort übermittelt werden. Nutzen Sie Paginierung und Filter und wählen Sie nur die benötigten Felder aus. Je mehr Datensätze und zugehörige Daten der Client anfordert, desto höher ist die Belastung der Datenbank und desto länger dauert die Generierung einer Antwort.

Bei der Anbindung eines separaten Frontends sollte die Caching-Strategie im Voraus festgelegt werden. Öffentliche Katalogdaten können clientseitig, auf einem CDN oder serverseitig zwischengespeichert werden, sofern eine geringe Aktualisierungsverzögerung akzeptabel ist. Personalisierte Antworten und benutzerberechtigungsabhängige Daten sollten nicht in einem gemeinsamen öffentlichen Cache gespeichert werden.

Erwägen Sie, den Cache zu invalidieren: zeitbasiert, nach jeder Änderung eines Datensatzes oder über einen separaten Benachrichtigungsmechanismus. Andernfalls werden im Frontend möglicherweise veraltete Preise, Lagerbestände oder Veröffentlichungen angezeigt. Die konkrete Methode hängt von der Infrastruktur, der Aktualisierungshäufigkeit und der akzeptablen Gültigkeitsdauer ab.

Wie man den Umfang der Unterstützung abschätzt

Kriterium	Was zu prüfen ist	Mögliche Einschränkung
Datenvolumen	Anzahl der Datensätze, JSON-Größe, Anfragerate	Paginierung, Filter und Abfrageoptimierung sind erforderlich.
Zugriffsebene	Gibt es öffentliche, amtliche und personenbezogene Daten?	Mit derselben Caching-Strategie können keine unterschiedlichen Antworten bereitgestellt werden.
Zwischenspeicherung	Wie schnell sollten Änderungen im Frontend sichtbar sein?	Ein großer Cache verringert die Relevanz, ein kurzer spart weniger Ressourcen.
Versionierung	Die Anzahl der Kunden hängt vom aktuellen Vertrag ab.	Während der Übergangszeit müssen ältere Versionen weiterhin unterstützt werden.

Nach Aktualisierungen sollten Sie das Fehlerprotokoll, den Anteil der 4xx- und 5xx-Fehler, die Antwortzeit sowie leere oder unerwartet große JSON-Antworten überwachen. Es ist außerdem hilfreich, eine Liste der API-Nutzer und der von ihnen verwendeten Routenversionen zu führen. So können Sie die Teams rechtzeitig vor der Abschaltung des alten Endpunkts informieren.

Die WordPress REST API eignet sich für viele Integrationen, ersetzt aber keine Performance-Optimierung. Große Kataloge, komplexe Beziehungen zwischen Entitäten oder intensive Synchronisierung erfordern möglicherweise serverseitiges Caching, Hintergrundprozesse oder eine separate Integrationsschicht. Wählen Sie eine Lösung erst nach Prüfung der tatsächlichen Datenstruktur und -last und nicht nur basierend auf der Verfügbarkeit einer fertigen REST-Schnittstelle.

Offizielle Dokumentation: WordPress REST-API Und Genehmigung anfordern.

«Vor der Integration über die REST-API empfehle ich die Erstellung einer Berechtigungstabelle: Wer darf die Daten lesen, wer darf sie ändern und wie wird der Zugriff widerrufen? Eine erfolgreiche API-Antwort bedeutet nicht zwangsläufig einen angemessenen Datenschutz.»

Bogdan Rjaboschapka, Gründer und Autor des Blogs Web Raketa. Kommentar des Autors.