couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: switching between response content type in show? how to trigger html response inst of default xml
Date Tue, 04 Aug 2009 07:17:40 GMT
Moved this thread over from user@. The context was me being unhappy
with how browsers handle Accept headers.

Adam convinced me that they can be good, but our API needs to change
so that users can define an ordering. Often many accept headers match
a request, in which case the server can pick what they want. This
would prevent browsers getting XML when they'd be better with HTML,
for instance.

On Sun, Jul 26, 2009 at 1:54 PM, Adam Jacob<> wrote:
> On Sat, Jul 25, 2009 at 3:22 PM, Chris Anderson<> wrote:
>> You've got me thinking about how I can craft an API that makes all
>> this clearer for users, something like:
>> respondWith("html", function() { ... }");
>> respondWith("xml", function() { ... }");
> Totally - merb's provides api does something similar.
>> etc...
>> The difference between this and the current API is that it gets an
>> ordering for users. So the first matching function would be run to
>> generate the response. If no functions matched, the first function
>> would also be run (or maybe there should an option for strict 406
>> errors.)
> Well, if the Accept header contains */*, then you get to pick.  If it
> doesn't, then it's a 406.

I'm starting to implement this right now. I think this will be a
clearer API. The first function that matches the client's Accept
header is chosen.

provides("html", function() {
   ... generate html ...

provides("atom", function() {
   ... generate atom ...

provides("csv", function() {
   ... generate csv ...

I also like the provides() name better... thanks Merb.

What do people think? I think it should replace respondsWith() as the
API for Accept header / format switching. If there are a bunch of
people needing respondsWith to stay the same, we can do a deprecation
notice for 0.10, but the old API is more or less wrong, so it should
be removed eventually.

Maybe there should be an option, in the case of no match - either the
first function is run, or a 406 is returned. Maybe the spec has more
to say here.

Of course, all the list functions that don't use respondsWith will not
be effected.


Chris Anderson

View raw message