On Mon, Dec 28, 2009 at 10:01 AM, Joe Gregorio
<joe@xxxxxxxxxxxxxx> wrote:
On Mon, Dec 28, 2009 at 12:08 PM, DeWitt Clinton <
dewitt@xxxxxxxx> wrote:
> You wrote that post a few years back, but I take your mentioning it again to
> mean your opinion hasn't changed?
> Bummer, because some form of content
> negotiation would certainly still be valuable.
> But wouldn't the particular problems you describe be mitigated if the server
> additionally exposed an explicit 'format' parameter on the URL to force a
> particular media type? (This seems to be common practice today anyway.)
The explicit query parameter makes it a different URI, so that does
solve the problem, and while it has become a common practice, we only
have convention at this point, no standard way of discovering the available
representations and their URIs.
What use cases are you thinking of that would benefit from conneg?
The one on my mind lately has been Webfinger (
http://code.google.com/p/webfinger/). The standard content type for /.well-known/host-meta/ queries and webfinger queries is XRD (
http://www.oasis-open.org/committees/download.php/35274/xrd-1.0-wd10.html). However, there seems to be both interest and value in returning these documents in other formats -- in particular JSON and HTML, though Atom entries are also a strong possibility if we can align XRD's link element a bit better -- hence the desire to perform some sort of content negotiation. This can be implemented via a URL-modifying switch (i.e., a 'format' flag), such as I do at
http://webfingerclient-dclinton.appspot.com/, but there's no reason the server shouldn't be able to infer the client's desired media type given enough hints in the request.
Also, given the ever-increasing popularity of JSON as an alternative to XML, I suspect that many Atom-based servers would also like to offer a negotiated option of a JSON return format. I know I'd like that for syndicated search results, for example.
Sorry, this has strayed off topic -- I'll pick up this thread elsewhere if needed.
-DeWitt