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?
4 comments:
What doesn't make sense to you? REST is a model of how the Web works (i.e. transfering of representations of resources via HTTP). Thus how HTML browsers process content (including video) is very pertinent to discussions of REST.
It seems you are looking at REST out of the narrow lens of the perennial REST vs. SOAP discussions. From that perspective, I guess you wouldn't see how Web browsers work on the World Wide Web as being pertinent even though it is the entire point of Roy Fieldings's disertation which coined the term REST in the first place.
-- Dare Obasanjo
How web browsers use HTTP and how REST Ws use HTTP might be different. It's waay easy to futze with Accept: headers from a REST ws; reconfiguring your browser to do this isn't practical. The browsers did the right thing; I don't want my mom calling me asking me how to answer a question from the browser about how to handle content types!
That doesn't mean REST ws should have to guess also.
And BTW, you're starting to sound a bit like an evangelical preacher quoting chapter and verse from the Holy Bible.
There's nothign wrong with content-type; content-type is indespensible. And 'deprecate' was hyperbole. The only problem is with the general applicability of the 'accept:' header when the number of content-types you can accept is large. In that case, it isn't efficient, you need to do something else. Certainly for communication channels where the choices are limited (such as SOAP or RSS), using Accept: headers is fine.
-- Larry
Agree; like I said in the post, the whole q parm thing is over the top; basic Accept: handling seems ok though.
Post a Comment