==TBD==
* [ ] Who the first round of users of this feature will be
* [ ] Request content type, headers, body model
* [ ] Response status, content type, headers body model
==Implementaiton notes==
Request to RESTBase: `GET /{domain}/v1/page/{name}/html/{revision}`
Restbase checks whether the HTML for that revision is found in storage. If not, then it asks Parsoid to generate it.
For a normal GET request, RESTBase checks whether the predecessor revision is found in storage (currently the predecessor revision is passed in an x-parsoid header, but we could also try the pagecontent revision table). If it is, then it retrieves the data for that and posts:
```
POST /v2/{domain}/html/{name}/{revision}
{
previous: {
revid: 12345, // The previous revision ID
html: {
headers: {
'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
},
body: "the original HTML"
}
'data-parsoid': {
headers: {
'content-type': 'application/json;profile=mediawiki.org/specs/data-parsoid/0.0.1'
},
body: {}
}
}
}
```
For a `no-cache` request, RESTBase instead first checks whether the *current* revision is found in storage. If it is, it sends the data for that in the `original` key:
```
POST /v2/{domain}/html/{name}/{revision}
{
original: {
revid: 12345, // The original revision ID
html: {
headers: {
'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
},
body: "the original HTML"
}
'data-parsoid': {
headers: {
'content-type': 'application/json;profile=mediawiki.org/specs/data-parsoid/0.0.1'
},
body: {}
}
}
}
```
This entry point returns both html and data-parsoid in one JSON blob, which restbase stores in html and data-parsoid buckets, and also returns to the client.
Example response from Parsoid:
```
{
revid: 12346, // The new revision ID (maybe?)
html: {
headers: {
'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
},
body: "the new HTML"
}
'data-parsoid': {
headers: {
'content-type': 'application/json;profile=mediawiki.org/specs/data-parsoid/0.0.1'
},
body: {}
}
}
```