WebDAV vs HTTP method semantics
Sat, 25 Aug 2001 11:26:57 -0400 (EDT)
I've been thinking more about some of WebDAV's methods, specifically
LOCK, COPY, and MOVE.
LarryM pointed out this FoRK post on xml-dist-app. Having made the
"Linda/HTTP mental leap" after that post was made, I wasn't in a position
to respond. I feel I am now. In it, Jim gives a number of alternatives
that were considered about how to extend HTTP. Curiously, the only
mention of using POST or PUT is in point #2 where he talks about
using RPC and tunneling over POST. I agree that that approach would have
been a mistake, but it's not the only possibility for a use of POST.
There's also an extensibility mechanism not mentioned in that post that
would have been useful, I believe.
My hypothesis is that, at least in theory, all operations with side
effects on resources can be represented with only PUT or POST. Here's
an attempt to recast LOCK, COPY, and MOVE in that way.
LOCK's side effect is to change the state of the resource identified by
the Request-URI to one of locked (per WebDAV lock semantics). It does
this relative to the current state of the resource, not to the exclusion
of it (duh), so this should use POST not PUT. But how do we use POST?
We POST a lock entity, describing the type of lock.
<lock xmlns="http://www.ietf.org/rfc/rfc2518.txt" />
The use of an XML namespace being the extensibility mechanism I mentioned
above. Content-Type on the POST wouldn't have been appropriate because it
is an attribute of the representation, not the resource itself. The
namespace describes the resource.
COPY is a means of taking the state of one resource, and creating a new
resource with that state. This can be done with PUT. 2616, 9.6 describes
exactly this scenario;
The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already
existing resource, the enclosed entity SHOULD be considered as a
modified version of the one residing on the origin server. If the
Request-URI does not point to an existing resource, and that URI is
capable of being defined as a new resource by the requesting user
agent, the origin server can create the resource with that URI. If a
new resource is created, the origin server MUST inform the user agent
via the 201 (Created) response.
So COPY would be GET+PUT. The downside there being the extra hop, but
I think that is more than compensated for the by simplicity. Plus,
as I'm thinking about it now, making an atomic operation like COPY or
MOVE between two distributed resources seems like it's breaking REST's
concept of moving state to the user agent, plus it seems to be making
distribution a lot more transparent than HTTP has. Hmm..
I believe MOVE would simply be COPY+DELETE, aka GET+PUT+DELETE.
What say ye Jim?
(I've gotta put this in the Wiki)