RE: What do we get with PUT/DELETE?

["Thompson, Bryan B." <BRYAN.B.THOMPSON@xxxxxxxx>]

Ken,

Nice summary.

-bryan

-----Original Message-----
From: owner-atom-syntax@xxxxxxxxxxxx
To: atom-syntax@xxxxxxx
Sent: 2/25/2004 12:18 AM
Subject: What do we get with PUT/DELETE?


In <http://www.russellbeattie.com/notebook/1006253.html#040436>, Don
Park writes:
>  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

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

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

 * 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

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

 * an obvious pattern for application-specific extension

 * API extensions with at least one less dimension of lock-in


Take a look at <http://www.xmlrpc.com/manilarpc>.  Feature-wise, it's
fine.  In fact, it is one of the richest I polled when I reviewed API
requirements on the wiki.  Would you expect *any* other CMS to come
close to agreeing on that API?  I don't.  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."

Do I think the SOAP wrapper is too much?  Yes, I do.  I think the
*Atom XML wrapper* is too much for most cases.  Get rid of MIME
<content> altogether, it's a freakin mess compared to a photoblog just
PUTting a JPEG image, with a .meta resource nearby as necessary.
Surely HTML and XHTML *items* can have their metadata internal to the
item, yet a wiki's plain text file could have a nearby .meta file too.

You wanna know the biggest thing I'm tired about this argument,
though?  It is that it's not about PUT or DELETE.

This argument is not about HTTP's PUT and DELETE methods or toolkit
support thereof.  That's a red herring.

Let's suppose for just a moment that not only did we specify a
trivially simple fallback, such as an HTTP header (X-Atom-Method), but
that we actually made that the sole way of specifying the action:
X-Atom-Method can be one of GET, PUT, POST, or DELETE.  Who's on-board
with this now that wasn't on-board before?  No one?  I didn't think so.*

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

Forget that it far surpasses the 80/20 mark, forget that it works
within and exactly to widely documented standards, forget that the
very first web-based tool used it, forget that it makes the majority
of interactions no different than choosing "Open" and "Save" from your
GUI menu, forget the large number of implementations that *do* support
it exactly as intended.

REST is bad because it's not an Object Oriented Procedural Functional
Atheistic Interface Type Strict Whatever.  Oh, and a few tools don't
support HTTP's PUT/DELETE correctly.

----

Ok.  Sorry for building up to that rant.  I really do wish someone
would sit down and sketch out what their overall alternative is,
because I strongly doubt it is as simple as "deprecating" HTTP's
PUT/DELETE.  Take a look at the ManilaRPC link above, as I believe it
is representative of the breadth of support that publishers would like
to extend to and beyond.  The current, minimal, Atom API spec is just
the beginning.  I want to know what *your* plan for growth is.

  -- Ken

* If you are on board with that, over all the tools that *do* support
  those methods in the obvious way you would expect them to, then
  you're not making yourself very clear.