A couple of weeks ago I finally got down to implementing the JSR-311 Restful web services specification I talked about in a previous blog. In reading the JSR mail list and looking into HTTP content negotiation, a few questions popped up in regards to the programmatic web.
- Why would a client ever send more than one Accept header?
- Why would a client or server ever produce or consume wildcard content types? i.e. “text/*” or even “*/*”?
I know in theory that the idea is that an application can dynamically search for resources, on the web and just invoke on them. But when does any real application not have complete determinism? When you’re writing a distributed application, you research the services you are going to interact with. What exact data formats do they product? What exact formats do they consume? Otherwise its nearly impossible to implement your application. Coding isn’t guess work. You’re not going to invoke a service and hope it gives you back something you understand and vice-versa. So please, somebody, give me real live use cases for this type of complex content negotiation.
Bill the Plumber 
Nov 30, 2007 @ 22:36:54
“When you’re writing a distributed application, you research the services you are going to interact with”
You think Googlebot was written that way? Or curl? Or browsers? No, they just support HTTP plus whatever data formats they need to get their job done. But they have no idea which resources will or won’t emit or consume this data at design time: it’s all discovered at runtime (save for the initial URI which is provided at configuration time).
I deployed a system a few years ago that exposed streaming data feeds with their own URIs, but the feeds could be expressed in two ways; HTML, for when somebody typed that URI into a browser, and a proprietary compressed binary format for automata interested in consuming that data. There’s no magic to it. That said, it’s long been recognized that the Accept header is a broken way to do negotiation, and that something like the Alternates response header is superior.
To answer your bullet questions, a client would use multiple Accept headers (or multiple types in a single header – same thing) to let the server know what formats it consumed. And the use of “text/*”, in practice, really just means that the client implements the fallback behaviour of all text/* types: that they can all be treated as text/plain (not particularly valuable, but that’s what it means at least). Using application/* would be meaningless. image/* is used when the client supports all the common image formats.
Mark.
Nov 30, 2007 @ 22:57:58
Thanks Mark for providing your insight to a REST noob…
Aren’t the examples you gave (Googlebot, browsers) really special cases in that they are really just only reading content and not really interacting with the resource. In the browser’s case, its really just acting a dispatcher to a specific renderer plugin. I’m thinking more of the programmtic web, web applications (specifically Ajax + REST), or even BPM orchestrating a set of distributed services.
Apr 25, 2008 @ 16:50:30
“Why would a client ever send more than one Accept header?”
Special purpose clients are not likely to send more than one.
“Why would a client or server ever produce or consume wildcard content types? i.e. “text/*” or even “*/*”?”
IMO, wild card types apply to general purpose clients like browsers.