On 3/15/06, Thomas Broyer <[EMAIL PROTECTED]> wrote:
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
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)
