So, to summarize, a server can return any status code when receiving a POST to create a new collection member. A Location: header may or may not be returned with the response.
If the Location: header *is* returned, MUST/SHOULD it appear in the collection feed document? -joe On 3/15/06, James Snell <[EMAIL PROTECTED]> wrote: > > > > On 3/15/06, Thomas Broyer <[EMAIL PROTECTED]> wrote: > > > > 2006/3/15, James Snell <[EMAIL PROTECTED]>: > > > The HTTP response that is returned back to the POSTing client is > required > > > only to reflect the specific context of that individual specific > > > transaction. That is, even if the POSTing results in the creation of > some > > > kind of resource, if that resource is not being made available to that > > > POSTing client to do anything with, or if the resource is being > > > automatically added to some moderation queue, it is appropriate to > return a > > > 202 Accepted. > > > > Yes, but... > > > > It's also appropriate to return a 201 (Created) to tell the client > > where the resource has been created (whether it is and/or will be > > editable is orthogonal). The fact that the entry doesn't appear (yet) > > in the collection it has been POSTed to (and/or appears in another > > collection) specifically means that, well, the entry is not yet > > visible to the user (or available) in the collection. > > > Yes, servers *could* return either which is why I don't think the spec > should dictate any single response code. In this use case, I would strongly > recommend 202, but servers should do whatever they feel is appropriate. > Determining the success of the operation should be based on the class of > response ( e.g.2xx, 4xx) rather than on any specific individual response > code (200, 201, 202, etc) > - James > -- Joe Gregorio http://bitworking.org
