I don't think 1 additional line of code is much of a burden. If you put it in the URL you're forcing the server to ignore the Accept header that the browser sends and pay attention to some non-standard url substring instead.
I was fooling around with Javascript MVC lately, and came across a problem -- let's say I have this URL, "example.com/objects/1". If I open it in the browser, the server returns a barebones HTML page. JS in the page makes a separate ajax call to the same address, the server detects the accept header, returns JSON data, and the page is populated with content.
Now I navigate off the page to a different site, and press the back button. Instead of the HTML page, I get the cached JSON response. Now if I change the ajax call to "example.com/objects/1.json" instead, that keeps the URLs separate and the browser won't cache the wrong response. Is there a better way to solve this?
The problem I have with Vary headers is that many reverse proxies will just not cache anything with a Vary header. The reason is that if they add the value of the header that "varies" to the key of the cache, now they have to cache under many different keys the same content.
Think of all the different "Accept" headers that clients can send you, each one of these will get an entry in your cache. And now add other headers that should also be in "Vary" like "Cookies", "Accept-Language", etc. and your cache will be virtually useless.
Interesting. Perhaps, instead of relying on "Vary: Accept" the server should respond with: "Vary: YourCustomHeader". The API client, on the other hand, will include "YourCustomHeader: SomeConstantValue" when making requests to the server. That way, the reverse proxy will only store up to two versions in its cache.
It's not just one additional line of code. It is additional work every time you try to view result in the browser. Which you basically can't because you can't put accept header in url bar..
At least in python, making requests becomes quite a few more lines of code if you want to add headers. There's usually a short-hand command if you just want to get full data from an url and a "create-an-object, then set these parameters, then this, then open a connection then read what's there".
Mandatory headers are just a way to make life of a regular developer painful.
Sounds like you just need to abstract that part into a function. Much better solution than breaking HTTP. HTTP is not supposed to send the same results for a given URL, it is supposed to send the same results for the a given request. In the case of the browser, it asks for HTML.
I can see that using "Accept" can be considered a more elegant solution, I don't see how adding a parameter will break HTTP. There is nothing in the HTTP standard that says what an URL should or should not return. The Accept-header is just an additional source of information.
Not actually, the Accept header isn't a mere suggestion. If the server chooses not to fulfill it, the correct response is 406 Not Acceptable. This is why browsers send something like this in their Accept header:
This is exactly the reason why even the good standards fail. Instead of writing 10 lines of code to abstract your specific use case, you want it to be the default behavior. How many times have you cursed something like IE for not implementing CSS properly?
