Thread:Talk:Requests for comment/API Future/Cacheable requests, URLs, and cache purging?/reply (5)

While a request for the HTML of a specific page or a section of that page is highly cachable, the cache must be frequently purged/updated to reflect edits made to the page. I think other requests are also highly cachable with less need for the cache to be purged/updated because changes happen less often for other things.

Representational state transfer (REST) can reduce server load by allowing clients, proxies, and anything else sitting between clients and servers to participate in caching results too, possibly reducing or eliminating the need for any response from the servers. Using REST with the "If-Modified-Since" header could allow servers to send a "304 Not Modified" response. I think this also fits in well with the goal of only sending what the client requests.

As for multiple props, either don't support it to keep responses short or maybe use:

/w/api/v2/pages/categories|langlinks/Page

Support for multiple props could require props be listed in alphabetical order, or 301/302 HTTP redirection could be used to force alphabetical ordering.

No URL rewrite rules could be required if v2 is the script and the web server is relied on to set the environment variable PATH_INFO ("/pages/categories|langlinks/Page" in the above example).