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

RESTBase est une API de proxy pour la mise en cache et la restitution derrière l'Wikimedia REST API . Sa configuration est basée sur les spécifications de Swagger, et la zone de stockage primaire du noyau utilise Cassandra. Elle fait tourner "rest_v1", l'API Wikimedia REST de contenu utilisée par l'Editeur visuel pour récupérer le code HTML de la page à modifier. Pour des raisons de performance (tâche T95229), les points d'accès du service sont aussi disponibles sur chaque wiki, par exemple sur ce wiki.

En tant que proxy, RESTBase ne réalise aucun traitement significatif lui-même sur le contenu. A la place, il demande les transformations du contenu aux services du noyau si nécessaire, et typiquement (en fonction de la configuration) les stocke pour qu'ils puissent être récupérés ultérieurement. Pour les points de terminaison statiques à grand volume, la plupart des requêtes seront satisfaites directement à partir de la mémoire.

Le stockage au niveau du coeur présente une API de stockage REST similaire à Amazon DynamoDB et Google DataStore. L'implémentation initiale utilise Apache Cassandra. Les fonctionnalités notables incluent les index maintenus automatiquement et quelques prises en charge de petites transactions. Un coeur SQLite a été développé et c'est le coeur par défaut dans le paquet.

RESTBase produit automatiquement les statistiques statsd pour toutes les demandes à la mémoire et au coeur. Ceci fournit un bon niveau de référence de base pour les performances et l'instrumentation des erreurs dans une architecture de micro service.


Cas d'utilisation

Notre premier cas d'utilisation est l'accélération de l'Editeur visuel en réduisant la taille du HTML, et en éliminant les erreurs de cache Varnish. RESTBase stocke les métadonnées Parsoid séparément du code HTML de la page, ce qui réduit la taille de ce dernier d'environ 40%. RESTBase ne fournit cet HTML qu'à l'Editeur visuel, ce qui réduit de manière significative le transfert par le réseau et la latence du traitement. A long terme nous pensons réduire la taille du HTML à celle de la sortie actuelle de l'analyseur PHP pour la rendre compatible avec les vues régulières des pages. Ceci donne la possibilité de passer directement à l'Editeur visuel et libère le défilement.

Si le temps d'analyse n'est pas crucial pour votre wiki (par exemple s'il ne contient pas de modèle complexe ni un grand nombre de transclusions), alors l'accès direct à Parsoid peut avoir plus de sens que l'introduction d'une dépendance sur RESTBase.

Un autre cas d'utilisation qui nous intéresse particulièrement est de fournir une API d'édition au niveau de la section pour les micro contributions et les enregistrements très rapides de l'Editeur visuel, et même plus rapides que pour le wikicode.

Documentation

Installation

Voir aussi

Références