0

I'm considering the design of a ReST service where resources can be served with multiple representations.

My preferred method of doing this is for client to make a request with appropriate Accept header, and for the response to be made with a Vary header set on Accept:

Vary: Accept

My question is, will this be respected by various hardware (proxy layers etc.) out there on the internet, or do I risk some piece of hardware serving one of my clients a pdf representation of my resource when they asked for some kind of xml representation?

My alternative would be to run conneg through a uri extension 

~/resource.pdf  ||   ~/resource.xml)

or more likely through a querystring parameter:

~/resource?content-type=application/pdf    ||    ~/resource?content-type=application/vnd.mytype+xml

So: Am I gonna be alright with Vary:Accept, or do I need to play it safe by messing with my Url? Which pieces of hardware will cause me problems? Is there anything else I should be considering?

Thanks

Paul
  • 5,514
  • 2
  • 29
  • 38
  • Have you seen these [excellent SO answers](http://stackoverflow.com/questions/1975416/trying-to-understand-the-vary-http-header) on the Vary header usage? As I understand it, `Vary: Accept;` tells the proxy layers to mark the cached response as "fresh" when the request `Accept:` header is an exact match. If the client sets `Accept:` to a particular content type then its that type that is returned assuming it is consider "fresh" based on eTag or the other caching settings. – Sixto Saez Jan 28 '13 at 15:25
  • @SixtoSaez I have seen those answers - I'm just concerned about any machines that the request hits before it gets to my API not respecting this header and serving up the wrong representation of the content. e.g. corporate proxy servers / other things out of my control. Is this a valid concern - has anyone directly run into problems with this sort of thing. – Paul Jan 28 '13 at 16:48
  • In my very limited experience, I haven't seen a situation where the `Accept` header was ignored by a proxy layer but that's no real assurance. My understanding is HTTP proxies cache responses consistent with the HTTP headers. If a set of headers define an inconsistent state, they fall back to passing the request on. This [portion of RFC 3143](http://tools.ietf.org/html/rfc3143#section-2.1.1) may have some bearing on your question. – Sixto Saez Jan 28 '13 at 18:37

0 Answers0