4 ms·
Because that approach isn't recommended anymore. In short, it's much harder to for a cache to work effectively based upon Accept & Content-Type headers than it
by mfenniak 14y ago
Because that approach isn't recommended anymore. In short, it's much harder to for a cache to work effectively based upon Accept & Content-Type headers than it is for it to work on the URL.
For example, here's a quote from Roy Fielding: "In general, I avoid content negotiation without redirects like the plague because of its effect on caching.". In other words, content negotiation for a versioned content-type is OK... if it redirects to a URL that contains the version.
httpbis, the IETF working group in charge of maintaining and developing the core HTTP spec, has deprecated content negotiation: http://trac.tools.ietf.org/wg/httpbis/ticket/81 http://trac.tools.ietf.org/wg/httpbis/ticket/81; it's still part of a separate spec (RFC2295), but it's not a core component of HTTP anymore. Why? 'HTTP content negotiation was one of those "nice in theory" protocol additions that, in practice, didn't work out.'
Certainly you can still build an API that works fine using specialized content types. Versions in the URL are a pretty practical approach that work very well too.
- wahnfrieden 14y agoVery interesting, thanks. Your link 404s though. Also to you have a link to Fielding's quote?
- j_s 14y agoGoogle says: http://tech.groups.yahoo.com/group/rest-discuss/message/5857 http://tech.groups.yahoo.com/group/rest-discuss/message/5857 > Re: [rest-discuss] Request Header vs. Query String > On 4/11/06, Roy T. Fielding <fielding@...> wrote: > In general, I avoid content negotiation without redirects like the > plague because of its effect on caching.
- crescentfresh 14y ago404 fixed: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/81 http://trac.tools.ietf.org/wg/httpbis/trac/ticket/81
- mfenniak 14y agoThanks for posting the fixed link; I copied it from another computer, and missed a path. Doh.
- mudetroit 14y agoHaving admittedly not descended very deeply into the rules regarding HTTP caching, why should it be harder to cache based on the cross-section of the URL and the Accept-Header and not simply upon the URL? I am not certain which method I prefer more honestly, and could fall either way. The comment that it was nice in theory but didn't work in practice seems to more point to not following the spec as it was written then a problem with the spec itself.
- mfenniak 14y agoI would say it's far more difficult if you want to support the full range of capabilities that the Accept header supports. Accept can support more than a single mime-type, and can also include priorities on each mime-type accepted. If you combine that with multiple clients, I think caching based upon that header would be pretty difficult (or you'd have to make some simplifying assumptions). Impossible? No, not really. Worthwhile? My opinion is no. I haven't seen the practical benefits of the content-negotiation approach over the URL approach, but I have seen the practical difficulties, so I'm convinced.