RESTBase
RESTBase ist derzeit veraltet. See RESTBase/deprecation for details. |
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
- Sieh dir die API-Endpunkte an
- Übersicht
- Architektur
- Sieh dir die Dokumentation an
- Entwicklungsprozess
- Liste aktueller Benutzer
Installation
Siehe auch
HyperSwitch
|
- Sieh dir den Quellcode an
- Folge den Architektur-Diskussionen über RESTBase, indem du dem Projekt RESTBase-architecture beitrittst & es beobachtest
- Melde Fehler im Phabricator, Projekt 'RESTBase'
- RESTBase/Alternative architectural options considered
- RESTBase/Table storage backend options
- Ursprüngliche Umfrage: Storage service (talk) und Content API (talk)