-
Notifications
You must be signed in to change notification settings - Fork 902
Version in Accept Header rather than URL #17
Comments
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 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. |
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. |
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. :) |
Here's a nice blog post that explains the situation a bit better: |
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.
The text was updated successfully, but these errors were encountered: