This meme has been floating around today. Here are some links, on both sides of the issue:
Dang! And we just added some code this week to optionally returns JSON or XML, depending on the HTTP Accept: header, from a REST service. It just seemed so ... natural. Yahoo! is doing it via a common query string parameter, which I guess you could say is the Lo REST way, whereas the Accept: header is the Hi REST way.
So I can see that maybe Lo REST is a more portable way to do this than the Hi REST way. Can I really set headers in my http client? Am I sure it's not going to futz with them? Maybe some proxy will lose them, or someone will reuse the URL without remembering to set the Accept: header. Query string parameters ALWAYS work.
That, I can buy, as an argument for not using Accept:. Or maybe, as an argument to allow both Accept: and the query string parameter (who wins?).
Anyway, I decided to check the trail on this a little more, by reading the notes that led up to Larry Masinter's response. OK, the cellmt guys, with their Accept: header of
is ... yeah ... a little over the top. Does anyone really do anything on the server with the q parameters? And those mime-types, with the version built into them ... whoa. *and* the "+xml" !
Then I read up on HTTP 1.1 Content Negotiation. Ok, sure. No one does any of this stuff. If I had waited just a few hours more, I could have used this to put me to sleep.
So Larry is right, "HTTP content negotiation was one of those "nice in theory" protocol additions that, in practice, didn't work out."
Ian is wrong, Content-Type still has value, although maybe it has none in a web browser rendering web pages. I don't really care.
Dare makes a little sense: I do think some Web/REST advocates need to look around and realize what's happening on the Web instead of arguing from an "ideal" or "theoretical" perspective. My take-away: use Lo REST vs. Hi REST. Dare also makes no sense, seemingly comparing the state of HTML and multi-media rendering (sucky support for content type) to web services via REST. They both use HTTP. And ... maybe that's about it! So the web browsers screwed up content type, that's their fault; why can't the RESTafarians try to do it right, if they want?
