From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <584ACAD1-5343-4656-AEBC-8C0BFDD5724C@sun.com> References: <3A09771D-9AD3-4499-A354-A3111F5AD0EF@sun.com> <584ACAD1-5343-4656-AEBC-8C0BFDD5724C@sun.com> Date: Thu, 26 Mar 2009 14:44:53 -0500 Message-ID: From: Eric Van Hensbergen To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9P writes for directories Topicbox-Message-UUID: ca300514-ead4-11e9-9d60-3106f5b1d025 On Thu, Mar 26, 2009 at 2:31 PM, Roman Shaposhnik 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. This actually sounds more like a (devip style) clone operation to me. Outside of the ID bit, why wouldn't create suffice? -eric