Page MenuHomePhabricator

Curator reads a revision online
Open, MediumPublic

Description

"As a Curator, I want to read a revision online, so that I can read it with my browser or HTML widget and it will load fast."

Downloading a large document encoded in JSON, then loading the HTML from the JSON into a browser or native HTML widget, is much less efficient that letting the browser or widget download the HTML itself. So, if the user is "online", we want to have two endpoints: one for the JSON representation of the page without HTML, and one for HTML only.

This is similar in requirements to T234377, so we'll use the same structure (JSON-only for metadata, streaming HTML for the HTML part). The JSON-only metadata is already covered by T231345, so only one endpoint is defined here.

GET /revision/{id}/html

Returns the revision HTML.

Payload: empty

Request headers:

Status:
200 – this is the revision content
401 - user is not authenticated and this revision is only available to authenticated users
403 - authenticated user is not allowed to read the content of the revision
404 – revision does not exist (never created or deleted)

Headers: None

Body: HTML
Reversible HTML as generated by Parsoid for the revision. No skin or navigation.

Event Timeline

200 – this is the page
404 – revision does not exist (never created or deleted)

If the user doesn't have access to read a page, do we return 401/403?

This endpoint is very similar to RESTBase /page/html/{title}{/revision} endpoint, so when we move RESTBase functionality related to editing into core, do we envision this endpoint to power VE as well, or do we want to introduce special editing endpoint? Having them together will require some more parameters and headers added to this one, but the current specification doesn't prevent us from doing so. No need to decide now, just something to keep in mind.

If the user doesn't have access to read a page, do we return 401/403?

Yes, updated.

This endpoint is very similar to RESTBase /page/html/{title}{/revision} endpoint, so when we move RESTBase functionality related to editing into core, do we envision this endpoint to power VE as well, or do we want to introduce special editing endpoint?

I think that's a huge question, and I don't want to deal with it now. I agree, the endpoint as defined doesn't prevent merging the RESTBase functionality here.