Rest Content Negotiation and Caching

I'm wondering h开发者_运维问答ow caching works with content negotiation based API. Since the to get a resource in XML or JSON, the URI will be the same, for example:

http://example.com/bikes/mountain

The service returns JSON / XML based on the Accept type header. How smart are caches?

For example:

• if one client requested this using Accept type to return XML.
• the response is cached by web server for say 1 minute.
• second client requests same resource using Accept type to return JSON

Does caching check accept / content types at all? Or would this result in the JSON requester getting XML data back since thats what the server had cached? I'm hoping this is something so obvious its already been taken care of, otherwise, isn't that a pretty large argument to include .xml / .json in the URI?

I guess my question is basically, can i safely use content negotiation while still using standard caching techniques?

---

Darrel is correct in that the Vary header tells the client which request headers it can vary to get different representations of a resource.

That value tells the client that it can ask for the representation in a different file format, by setting or changing the Accept header (in your case, JSON or XML). You could also get a different representation of your mountain bike in English and in French if you use the Accept-Language header.

The two requests send different values, so they should always be cached separately.

When you use a value of '*' in Vary header, that means the response should not be cached.

---

Yes. Look at the description of the Vary header in RFC 2616

In my simplistic understanding of the vary header, caches will use the header fields that are named in the vary header to uniquely identify the cached representation.

---

As other have mentioned, one should Vary: Accept header in HTTP (REST) responses to make sure caches are aware that content changes based on negotiated content type. That works in the sense that browsers will not be served (or will not use) wrong cached variant for a different requested content type.

The issue is that even as of today (2022) Chrome in its HTTP cache cache only one variant per URL (Firefox seems to do the right thing). They will detect based on Vary header if you request once XML and once JSON representation and correctly download a new representation, but they will cache only the last one downloaded.

This can be a problem if you first load HTML contents at URL which then loads a content-negotiated JSON data at the same URL (using JavaScript fetch or something). Then in practice none of those two requests will really be cached: downloading JSON will remove the cached HTML, and next time user loads the page, cache will have JSON and not HTML, so HTML will have to be downloaded again, removing JSON from cache. Which then has to be downloaded again.

So in my view, this makes it required to include .json in URLs or something like that.

There is ongoing process on a new standard for HTTP Representation Variants. See also this Fastly blog post. And sadly even using service workers does currently not help you here in Chrome.