2006/3/13, Henry Story <[EMAIL PROTECTED]>: > > On 13 Mar 2006, at 16:22, Thomas Broyer wrote: > >> 2. Alternatively any change that ends up creating conflicting entries > >> in a collection feed should return some error code. What should > >> that be? > > > > 422 (Unprocessable Entity) > > [http://www.webdav.org/specs/rfc2518.html#STATUS_422], or eventually > > 400 (Bad Request) > > [http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1], > > though we're not talking about a syntax error… > > > > Eventually, 409 (Conflict) could also fit, > > 409 indeed looks like the right response. > > > but it implies that the > > client/user could change the atom:id to successfully POST its entry > > (i.e. a real new entry which is a copy of the one he initially tried > > to POST), which is semantically very different from resolving a > > conflict… > > Why? The user could put the entry back with the same id and different > time stamp too of course if he did not want to change the id.
Depends whether your server accepts two distinct resources with the same atom:id as members of a single collection (or system-wide). I think many server implementations won't, and 422 (Unprocessable Entity) would be a better choice in this case. In my implementation, atom:id is used as the primary key in an RDBMS table used to map to the filesystem store. I will [1] also have a table mapping HTTP URLs to an atom:id. Those URLs will [1] behave like WebDAV "bindings" so that the same resource will be available through multiple HTTP URLs. [1] "will", because first versions won't allow bindings; I'll change the database schema when I'll add that functionality. -- Thomas Broyer
