This is to make sure clients can compare responses to see if they are from the same render.
For clarity:
The revision id works applies only to the content of the page
The Time UUID takes into account all transcluded content of a page (like templates). We get this tid from Parsoid.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T169242 Develop Page Content Service for Reading Clients | |||
| Resolved | • bearND | T177512 Ensure all APIs include the Time UUID and the Revision ID in the response payload |
I think this should be in the payload, where we would use the revision number and tid we get from Parsoid.
The headers will have similar values embedded in the ETag. The revision would be the same but I think the render tid would be different for each endpoint.
Yes, this is now supposed to be in the payload. Good catch - feel free to update and repurpose this ticket for that
metadata: I see both revision and tid on https://en.wikipedia.beta.wmflabs.org/api/rest_v1/page/metadata/Foobar, so is this done?
For PCS content-html and read-compat-html: There's a meta tag with mw:TimeUuid in head, another with mw:revisionSHA1, and the <html> tag has about="…/wiki/Special:Redirect/revision/15">, which is not the JSON representation above but does this count as close enough?
→ Resolved?
@Jdforrester-WMF Yes, I think the task is done. The Content-html has the revision number appearing in the root <html> tag:
<html about="http://en.wikipedia.org/wiki/Special:Redirect/revision/845401280"
and the tid appearing in the <head>:
<head> <meta property="mw:TimeUuid" content="f64d87fb-6d89-11e8-a82b-44beea8dd094">
I removed the PCS compat HTML since that one is not going to be exposed anytime soon.
I removed CSS from the list since I don't think those endpoints need to have the rev and tid in the payload, as long as they are not page specific.