The responsibility to handle this falls on the server. Our implementation throws away client provided atom:id's in favor of unique, server generated id's.
- James Thomas Broyer wrote: > 2006/3/13, Henry Story <[EMAIL PROTECTED]>: >> What happens if an edit (POST or PUT) creates two entries with the >> same id and updated time stamp? If this were allowed then the >> Collection would end up returning a broken feed. >> >> There are a couple of solutions I can think of: >> >> 1. When POSTing an entry with the same id and updated time stamp as >> an entry that already exists, overwrite that entry > > -1 > POST in the APP means "create", not "update if something with the same > id already exists, create otherwise". > It's barely equivalent to the proposed WebDAV ADDMEMBER > [http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-latest.html] > >> 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, 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… > > -- > Thomas Broyer > >
