incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Allow overridden request methods
Date Thu, 14 May 2009 16:01:35 GMT
On Thu, May 14, 2009 at 11:39 AM, Adam Kocoloski <kocolosk@apache.org> wrote:
> On May 14, 2009, at 11:35 AM, Paul Davis wrote:
>
>> On Thu, May 14, 2009 at 3:26 AM, Brian Candler <B.Candler@pobox.com>
>> wrote:
>>>
>>> On Wed, May 13, 2009 at 06:58:47PM +0200, Jan Lehnardt wrote:
>>>>>
>>>>> Sorry for responding to my original message instead of a reply in the
>>>>> thread, but I seem to be having some issues with the mailing list.
>>>>> Oliver, you are right, I could use a javascript wrapper for flash. The
>>>>> problem with that is that it introduces a second dependency to
>>>>> interact with the REST interface.
>>>>
>>>> It adds a second API and complexity to CouchDB to support
>>>> non-standard clients. I.e: If you don't speak HTTP, you can't
>>>> talk to CouchDB.
>>>
>>> I think you'll find this is extremely common; many clients especially
>>> don't
>>> implement DELETE.
>>>
>>> The way Rails deals with it is to allow a form POST to have a _method
>>> field,
>>> and if it's present, it takes precedence over the HTTP method.
>>>
>>> actionpack/lib/action_view/helpers/url_helper.rb:
>>>         method_tag = tag('input', :type => 'hidden', :name => '_method',
>>> :value => method.to_s)
>>>
>>> Of course, CouchDB doesn't take a application/x-www-form-urlencoded, it
>>> takes an application/json body. So I think the nearest equivalent would
>>> be
>>> to allow a "_method" member in the JSON body and honour it for all POST
>>> requests [with JSON bodies]. Conveniently, CouchDB has already reserved
>>> all
>>> top-level keys beginning with underscores for its own purposes.
>>>
>>> Regards,
>>>
>>> Brian.
>>>
>>
>> Eww. I'm all for supporting clients that have a brain dead HTTP
>> interface, but piggybacking protocol information into the payload
>> seems like not a good idea. If we're going to allow method overrides
>> I'd vote +10 internets for the header version.
>
> I'm with Paul here.  So that's +20 internets.
>
>> But until someone shows me something that can't be accomplished using
>> the _bulk_docs API I'd be -0 on supporting the header even.
>
> Hmm, I don't know about this one.  If Mikael is right and
> X-HTTP-Method-Override is becoming a de facto standard, I think supporting
> that would be preferable to playing up our non-RESTful _bulk_docs hacks.
>

Its got google blessing in one form or another which I take to mean
they see a noticeable amount of traffic that requires it. I wouldn't
really mind this header. It should be trivial to implement, I'm just
trying to rack my brains and see if there might be dragons lurking
somewhere.

> Adam
>
>

Mime
View raw message