On Mar 26, 2009, at 1:54 PM, Eric Van Hensbergen wrote:
I have thought about that too, but became convinced that POST is more
like create (or more like write on a subdirectory -- hence the
original
question). With the clone operation it is the *opening* of the clone
device that provides you with a new fid. In HTTP that would be like
getting
a redirection on GET. Don't you think?
Except that Creates give an ID/path for creation instead of receiving
one -- that's the key thing that makes it like clone, the most
important bit being that this sort of mechanism avoids collision.
I believe we're on the same page, but the wording is not always
accurate.
Whether or not that is critical depends on how you write your app. I
think the main difference here is you are trying to map HTTP syntax to
9P syntax, and I've been thinking of semantics -- an HTTP POST to a
subdirectory would equal the opening of a clone file (within that
subdirectory), and writing the metadata,
Interesting point. I guess it all depends on what is the model for
new nodes to be created in the URI tree. In fact, if I were to complete
the analogy, then POST to an existing URI (although, nothing really
exists
in the world of URIs) corresponding to a "subdirectory" would be, in
fact,
what you say. A POST/PUT to a non-existing URI could be considered
a creation of the named resource in its parent. Although I'm not sure
that
such a thing should be always allowed.
a read on that file would
return the ID -- this would be done atomically by the HTTP server to
service the POST not as a set of HTTP routines.
If you mean PRG (http://en.wikipedia.org/wiki/Post/Redirect/Get) then
yes.
I think the critical aspect from the REST/CRUD perspective is that
the POST
has to be idempotent
Not as per HTTP RFC:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
Outside of the ID bit, why wouldn't create suffice?
It would (just as Erik pointed out). I guess I was just looking for
symmetry (if POST is really a write(*), it should translate into
write
independent of whether the URI corresponds to a subdirectory or
not) and potential pitfalls that made 9P spec disallow writes on
subdirectories (and since nobody can identify any of those -- I'll
rest my case and proceed with translating POST into different
9P messages depending on the type of the URI).
I don't think the symmetry is worth altering the semantics of the
protocol -- its likely more trouble than its worth in the long run.
Agreed.
Thanks,
Roman.
P.S. I wonder if there's a general interest in REST from the Plan9
folks. I've seen your blog post on the subject, so there's that. It is
actually quite fun to see how things like Google App Engine and
http://konstrukt.dk/, etc can reap the same benefits from the elegance
of FS-aware design. Could it be that with the right approach
(lib9p/libixp plugin for apache?) writing web services could be
as much fun as writing filesystems for Plan9?
