On Mar 26, 2009, at 12:44 PM, Eric Van Hensbergen wrote:
On Thu, Mar 26, 2009 at 2:31 PM, Roman Shaposhnik <r...@sun.com> wrote:
On Mar 21, 2009, at 12:00 AM, Roman Shaposhnik wrote:
The story here is that we are building a bunch of RESTful APIs
and my personal preference is to bend HTTP as close to 9P
as I can get (for obvious reasons). Now, the closest match
to "create" would be POST with a metadata payload on a
"subdirectory" URI. But of course, it is not a create at all.
It really is much closer to write on a subdirectory. Hence the
question: is there anything that HTTP makes us lose except
for the transactional nature of create?
So, my understanding is the function of POST to a collection/directory
was to create a new entry in the collection where the ID is assigned
automatically by the collection. The ID created is typically returned
by this operation.
If by ID you mean URI, that would be my current understanding as well.
Unlike create though, that is guaranteed to create an object in the
subdirectory
identified by an ID (fid), the POST can return any URI.
This actually sounds more like a (devip style) clone operation to me.
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?
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).
Thanks,
Roman.
(*) Now, POST really is *not* a write. PUT is. But current generation
of browsers can only "write" local files to remote destinations
with POST, not PUT. And even with JavaScript that restriction is too
painful
to overcome :-(
