Re: What do we get with PUT/DELETE?

[Dare Obasanjo <kpako@xxxxxxxxx>]

--- Ken MacLeod <ken@xxxxxxxxxxxxxxxx> wrote:
> 
> >  So exactly what do we get in return for doing all
> this? Using
> >  PUT/DELETE is designing for the future? All that
> does is replace
> >  four characters ('POST') at the head of a HTTP
> request with other
> >  characters ('PUT' or 'DELETE') which could have
> just as well been
> >  within the payload or headers.
> 
> Off the top of my head, we get:
> 
>  * more software that uses standards-level features
> in ways they are
>    supposed to be used

Standards compliance is a means to an end not an end
in itself. Having more checkboxes that software
satisfies (i.e. uses REST) is not a benefit unless you
can translate it to easier interoperability, more
productivity and cheaper software. 

>  * bug reports against tools and libraries that
> aren't implementing
>    standards

Same as above. 

>  * network effect with other tools, libraries,
> applications and
>    standards that already use these features in the
> same way

On the other hand, if the features of the standard you
are trying to evangelize aren't widely supported in
the first case then you are getting the opposite of
network effects which is what this whole debate is
about. 

>  * raising people's awareness to the fact that an
> X/HTML editor
>    "saving" its content via PUT, as _many_ do, is
> just as good as
>    PUTting an Atom entry

I'm not sure what this means exactly. 

>  * protocol compatibility (PUT/DELETE => FTP's
> STOR/DELE)

??? 

Being able to make analogies between HTTP & FTP is
nice but not something I'd consider to be beneficial
to developers or end users of ATOM enabled software.
This just seems like an arbitrary goal to have. 
Why not try to model it after NNTP or SMTP then? 

>  * an obvious pattern for application-specific
> extension

If it's so obvious why isn't it widely used and why is
there so much complaint about it? 

>  * API extensions with at least one less dimension
> of lock-in
>  Yet give
> me some URIs with
> GET/PUT/DELETE, and a light sprinkling of POST, and
> that API is a
> gimme, a no-brainer, and in no conflict with any
> other CMS, "You put
> your CSS, where?  Cool."

People will extend the API regardless of however it is
designed. Whether it is by having extra query
parameters in a GET, adding extra XML content in the
payload or coming up with new URI end points. 

Claiming that using REST somehow prevents this from
happening is wishful thinking and doesn't jibe with
reality. 

> This is about the Atom API's design pattern; its
> architectural style.
> This is about that bugaboo, "REST".  You see, REST
> is *too* simple.

The purpose of ATOM should be to build useful software
for end users that can be widely supported not pushing
one's pet design methodology du jour. 

If REST turns out to be the best way to design the API
so be it but let's debate the merits of the current
API design with regards to what can be widely
supported not whether it meets whatever biases one has
or perceives that others have for what are mostly
religious arguments about software architecture. 


=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.

__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools