incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Landolt <d...@deanlandolt.com>
Subject Re: Allow overridden request methods
Date Thu, 14 May 2009 17:04:08 GMT
On Thu, May 14, 2009 at 12:01 PM, Paul Davis <paul.joseph.davis@gmail.com>wrote:

> 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.


It's got Microsoft's blessing and they're recommending all throughout their
WCF restful stuff. As for what's that's worth, who am I to judge -- just
throwing it out there ;)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message