views:

158

answers:

2

My feeling is that Content-Type negotiation is one of those "should do" things for REST, but most frameworks, tools and apps punt on it - and don't, as far as I know.

Is this true?

What REST programming frameworks support content-type negotiation?

Should I expect it to broaden in usefulness? Will it become more common in REST frameworks? Are applications really delivering multiple formats for the same resource? Or will they? Is there a good reason to deliver multiple formats for a resource?

+2  A: 

Rails does it, and it is the blessed way of doing things in the REST world, so I would expect it to be increasingly common.

Hank Gay
You know Hank, I get that it is the "right thing" to do, but with so little interest in the question, I'm still wondering if content-type negotiation is relevant. Do people not care? Is it YAGNI?
Cheeso
It seems as easy/easier than any other method of providing multiple representations of the same resource, and it's the standard, documented way. I'd go for it unless I had a *really* good reason not to. I suspect there are multiple reasons why there is so little interest: a surprising number of people on SO aren't doing web apps at all, much less RESTful ones; a lot of the people on SO are using the MS stack, which emphasized SOAP and company (at least until recently); the question came in at a pretty slow time; and not many people provide multiple representations (I wish more did).
Hank Gay
My guess would have been that the last reason is the big one - not many people think about or consider multiple content-types for a single resource, and so negotiation is a non-issue.
Cheeso
I suspect that is the main reason as well, even though I think most resources should be available in at least two versions: HTML and JSON/XML(for AtomPub, etc.). Also, a lot of data would be handy in other formats: iCal, KML, csv, etc. Oh well, I can dream, I suppose.
Hank Gay
+2  A: 

On the .net side of things does it, OpenRasta does it, so does Ado.net Data services (albeit limited to xml and json).

Conneg is not only about content-types though, it also includes language and character sets.

It'll become more prevalent when more frameworks support it, but those frameworks are there now, so why not use them and leverage it now?

As for conneg being YAGNI, people already expect to have both json and xml representations for some of their resources, and with rdfa looming, they all become more and more important.

That said, conneg is not about REST, it's about HTTP and using it properly.

serialseb