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
gallery: "…", //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:
1. Clients should be able to differentiate between content URLs and API URLs easily
2. We should decide on using mobile vs desktop URLs or both and clearly marking them up