RESTBase

From mediawiki.org
This page is a translated version of the page RESTBase and the translation is 100% complete.

RESTBase ist ein API-Proxy zum Cachen/Speichern hinter der Wikimedia REST API . Seine Konfiguration basiert auf Swagger specs, das Haupt-Speicher-Backend nutzt Cassandra. Es unterstĂŒtzt "rest_v1", die Wikimedia REST-Inhalts-API, die von Visual Editor fĂŒr die Bearbeitung von empfangenem Seiten-HTML verwendet wird. Aus PerformancegrĂŒnden (task T95229) sind Service-Endpunkte in jedem Wiki verfĂŒgbar, z.B. in diesem Wiki.

Als Proxy fĂŒhrt RESTBase selbst keine signifikanten Inhaltsverarbeitungen aus. Stattdessen beantragt er Inhaltstransformationen von Backend-Diensten, wenn dies nötig ist und speichert sie (abhĂ€ngig von der Konfiguration) ĂŒblicherweise fĂŒr spĂ€tere Abrufe. Bei umfangreichen statischen Endpunkten werden die meisten Abfragen direkt vom Speicher erfĂŒllt.

Seine Speicher-Backends stellen eine REST-Speicher-API bereit, vergleichbar mit Amazon DynamoDB und Google DataStore. Die primĂ€re Implementierung nutzt Apache Cassandra. Zu den erwĂ€hnenswerten Funktionen gehören automatisch verwaltete SekundĂ€rindizes und einige einfache TransaktionsunterstĂŒtzungen. Ein SQLite-Backend wurde entwickelt und stellt in dem Paket das Standard-Backend dar.

RESTBase gibt automatisch Statsd-Werte ĂŒber alle Speicher- und Backend-Abfragen aus. Dies bietet ein gutes Basisniveau an Performance und Fehlerinstrumenten in einer Mikro-Service-Architektur.


AnwendungsfÀlle

Unser erster Anwendungsfall ist die Beschleunigung des VisualEditors durch Reduzierung der HTML-GrĂ¶ĂŸe und die Eliminierung von Varnish-Cache-Fehlern. RESTBase speichert Parsoid-Metadaten getrennt vom HTML der Seite, wodurch die GrĂ¶ĂŸe von Letzterem um etwa 40% reduziert wird. RESTBase ĂŒbergibt nur dieses HTML an den VE, wodurch die NetzwerkĂŒbertragungs- und Verarbeitungs-Verzögerung erheblich reduziert wird. LĂ€ngerfristig streben wir an, die GrĂ¶ĂŸe des HTML auf die aktuelle PHP-Parser-Ausgabe zu reduzieren, damit sie fĂŒr normale Seitenaufrufe geeignet ist. Dies hat das Potenzial, den Wechsel zur visuellen Bearbeitung ohne Verzögerung und Scrollen zu ermöglichen.

Wenn die Parsing-Zeit fĂŒr dein Wiki nicht besonders wichtig ist (zum Beispiel, weil es keine komplexen Vorlagen oder nur wenige Einbindungen gibt), kann es mehr Sinn machen, direkt auf Parsoid zuzugreifen, als eine AbhĂ€ngigkeit von RESTBase einzufĂŒhren.

Ein weiterer Anwendungsfall, an dem wir stark interessiert sind, ist es, eine API zur Abschnittsbearbeitung fĂŒr kleine Bearbeitungen und sehr schnelle VisualEditor-Speicherungen anzubieten, die sogar schneller als bei Wikitext sind.

Dokumentation

Installation

Siehe auch

Einzelnachweise