Page MenuHomePhabricator

Parsoid REST API Client gets a speedy result
Closed, InvalidPublic

Description

"As a Parsoid REST API Client, I want to get my results fast from the parser cache, so that I don't have to route my requests through RESTBase."

The Parsoid REST API endpoints should check for cached results before regenerating them.

TODO: add checkboxes or tickets for each endpoint.

Event Timeline

If this task is about Parsoid API, it's invalid. At least in the context of the ParserCache project. Parsoid itself will not be using ParserCache, its clients will.

If this task is about MW REST API, backed by Parsoid, it's already speedy. So the task should probably be changed to "MW REST API backed by Parsoid use ParserCache instead of calling out to RESTBase"

Ok, there's T262605 for MW REST API, so this is indeed invalid.

Hey, @Pchelolo.

What I mean is the Parsoid API implemented inside MediaWiki. That can be hit directly by front-end clients, and I believe it works that way currently for some private wikis at WMF.

I think that without RESTBase in front of it providing caching services, it's pretty important that the read API endpoints check the cache before parsing a page or revision.

Parsoid REST API is internal and is not intended to be used by any clients. @ssastry correct me if I'm wrong, but the intention would be to drop Parsoid REST API once we migrate off RESTBase?

What happens to all the external clients who are currently hitting the RESTBase API? I was under the impression that the REST API in MediaWiki was going to subsume the RESTBase REST APIs and expand on it. If so, Parsoid's REST API would be part of that MediaWiki (public) REST API, isn't it?

@ssastry I call 'Parsoid API' something that's implemented in Parsoid codebase.

All RESTBase API backed by Parsoid and any relevant APIs implemented in Parsoid repo will migrate away into MW codebase, so Parsoid itself will have no REST API and RESTBase will disappear entirely

Ok, we are all talking about the same thing then (independent of which codebase the implementation lives in). Yes, eventually the REST API endpoints backed by Parsoid will be in core. And, AFAICT, that is what @eprodromou is referring to.

EDIT: Note that there is no other Parsoid API right now either besides the REST API endpoints which happen to live in the Parsoid codebase.

Ok, we are all talking about the same thing then (independent of which codebase the implementation lives in). Yes, eventually the REST API endpoints backed by Parsoid will be in core. And, AFAICT, that is what @eprodromou is referring to.

EDIT: Note that there is no other Parsoid API right now either besides the REST API endpoints which happen to live in the Parsoid codebase.

Yeah, there's also T262608 - my argument is that T262608 should stay and this should go away.

Ah, sure, this isn't necessary given T262608's existence.