This page is a translated version of the page RESTBase and the translation is 22% complete.
Outdated translations are marked like this.

O RESTBase é um proxy para a API de armazenamento / cache que dá suporte à Wikimedia REST API . Sua configuração baseia-se nas especificações do Swagger, e seu backend de armazenamento primário usa o Apache Cassandra. Ele alimenta a “rest_v1”, a API de conteúdo para o REST usada pelo Editor Visual para recuperar o HTML das páginas para edição. Por motivos de desempenho (tarefa T95229), alguns endpoints do serviço também estão disponíveis nas wikis, por exemplo, nesta wiki.

Como proxy, o RESTBase não realiza nenhum processamento significante de conteúdo. Em vez disso, ele solicita transformações no conteúdo de serviços de backend quando necessário, e tipicamente (dependendo da configuração) armazena-as para recuperá-las mais tarde. Para endpoints estáticos de alto-volume, a maioria das solicitações serão satisfeitas diretamente do armazenamento.

Its storage backends expose a RESTful storage API similar to Amazon DynamoDB and Google DataStore. The primary implementation uses Apache Cassandra. Notable features include automatically maintained secondary indexes and some lightweight transaction support. A SQLite backend has been developed and is the default backend in the package.

RESTBase automatically emits statsd metrics about all storage and backend requests. This provides a good baseline level of performance and error instrumentation in a micro-service architecture.

Use cases

Our first use case is speeding up VisualEditor by reducing HTML size, and eliminating Varnish cache misses. RESTBase stores Parsoid metadata separately from the HTML of the page, which reduces the size of the latter by about 40%. RESTBase provides only this HTML to VE, which reduces network transfer and processing latency significantly. In the longer term, we are aiming to bring down the size of the HTML to that of current PHP parser output to make it suitable for regular page views. This has the potential to make switching to visual editing instantaneous and free of any scrolling.

If parse time is not a pressing concern for your wiki (for example it does not have complex templates or large transclusion counts), then accessing Parsoid directly may make more sense than introducing a dependency on RESTBase.

Another use case we are strongly interested in is providing a section-level editing API for micro-contributions and extremely fast VisualEditor saves, even faster than wikitext.



Ver também