Originally discussed here:
T169761#3422369
and here:
T169761#3424801
This is pushing forward the notion of returning the data that clients need and remove the need for client side processing.
In particular, clients create a small number of URLs from titles. @phuedx proposed a dictionary like (I have made a few changes/additions):
content_urls: { page: "…", revisions: "..." editor: "…", talk_page: "...", }, api_urls: { summary: "...", //The URL to this response mobile_sections: "...", //return for now, but will be deprecated read_html: "...", //new PCS endpoint content_html: "...", //new PCS end point metadata: "…", //new PCS end point references: "…", //new PCS end point media: "…", //new PCS end point revisions: "...", edit_html: "..." //Parsoid HTML url talk_page_html: "...", //Parsoid HTML url for the talk page },
This seems like a good path forward. We need to bike shed on a few specifics, and should do that here. Some things to consider for the final structure:
- Clients should be able to differentiate between content URLs and API URLs easily
- We should decide on using mobile vs desktop URLs or both and clearly marking them up
- We need to ensure that clients will not be redirected using the URLs we provide.