Geek Answers Handbook

Content Consolidation and Content Caching

I am wondering how caching works with the API for content negotiation. Since to get the 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 an Accept header. How smart are hiding places?

For example:

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

Does checking cache / content types in general? Or will this cause the JSON requester to receive XML data since the server has been cached? I hope this is so obvious that it has already been taken care of, otherwise, is it not a very big argument to include .xml / .json in the URI?

I assume that my question is mainly, can I safely use content negotiation when using standard caching methods?

+7
content-type rest caching content-negotiation
source share
2 answers

Darrell is right because the Vary header tells the client who is requesting the headers, he can change to get different views of the resource.

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

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

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

+2
source share

Yes. See Vary header description in RFC 2616

In my simplified understanding of the change header, caches will use the header fields named in the change header to uniquely identify the cached view.

+2
source share

More articles:


All Articles