Skip to content
This repository has been archived by the owner on Mar 3, 2022. It is now read-only.

Version in Accept Header rather than URL #17

Open
joewood opened this issue Mar 25, 2013 · 4 comments
Open

Version in Accept Header rather than URL #17

joewood opened this issue Mar 25, 2013 · 4 comments

Comments

@joewood
Copy link

joewood commented Mar 25, 2013

Generally, it's better practice to put the version of the service in the HTTP Accept Header. The URL should uniquely identify the identities, independent of the representation of those entities on the wire. The version of the schema should be seen as a representation of the entities.

@mstade
Copy link

mstade commented Apr 22, 2013

While your advice is correct I think, it's also worth noting that many user agents have a rather naive cache that won't consider various headers when making requests, particularly the Accept header. I noticed that when using the same URL for multiple different representations, where the only difference in the requests was indeed the Accept header, some user agents would simply ignore it and just return whatever was in the cache. It was particularly tricky to figure out since whenever the cache was invalidated, it would work fine. The culprits in our environment were IE (of course) and Chrome (less obvious) where Firefox worked fine. Of course, any UA that doesn't cache – such as curl or many http libraries – worked just fine.

Now, this was for the actual media type, but I can't imagine user agents would care much more about parameters. In the end, we just used plain ol' cache busting techniques, like using query strings or changing the path altogether. Unfortunately I didn't have time to investigate other solutions.

@joewood
Copy link
Author

joewood commented Apr 22, 2013

Hi Marcus - that's interesting, and definitely does not respect the REST pattern. A quick workaround would be to include a dummy mime type in the URL (as you suggest) and it should be raised as a bug.
Even so, I would prefer to keep the versioning as content negotation, rather than part of the URI. The fact that some browsers are not respecting it shouldn't leak into the architecture IMO.

@mstade
Copy link

mstade commented Apr 22, 2013

I agree, it's not very RESTful. There's a bug filed about it and later additions to that thread seems to suggest that it's been fixed, but I've not been able to verify this myself yet. I also agree these kinds of things shouldn't affect the architecture, but unfortunately when you have to live in a world with faulty UAs you kind of have to stay pragmatic. Or just target Firefox. :)

@mstade
Copy link

mstade commented Apr 22, 2013

Here's a nice blog post that explains the situation a bit better:
http://blog.sdqali.in/blog/2012/11/27/on-rest-content-type-google-chrome-and-caching/

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants