I am going to try to answer myself. On 10/31/05, Luke Arno <[EMAIL PROTECTED]> wrote: > On 10/31/05, Joe Gregorio <[EMAIL PROTECTED]> wrote: > > On 10/31/05, Luke Arno <[EMAIL PROTECTED]> wrote: > > > I think that Atom syntax provides us with what we need. > > > > > > Not only do I think that we can deal in valid entries, I > > > strongly believe that we need *no* extensions for the > > > core protocol. > > > > A Pace with camera ready copy that explains > > the disposition of atom:link and atom:id on a POST > > would be most appreciated. > > > > That is a tall order and I think it requires some > discussion as to how. :-) > > I would like to start with atom:id. > > Should it be generated client side? >
It seems like that could work. > Does anyone have suggestions for a client side > algorithm? > That is a dumb question. Most methods of producing an id are fine on the client side. If a conflict comes up the server can reject the POST. > Should the server pass them out? > Na. That would be pain. > If so how? > See above. > Should whole entry templates be served up? > Forget that. That was a straw man proposal. > Should the "POST id" be reset by the server? > No. What about moving entries from one collection to another? The id shouldn't change. A DELETE/POST combo can be used to "move" an entry. > Can our use of id at POST time address our > idempotency concerns? > Hmmm. That is tougher. Try this: If identical entries (id and all) are POSTed within X time go ahead and just issue the same 201 for each. Would this break down? What am I missing? - Luke
