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. If the created entry is given an "approval state" extension element, this allows the client to check the entry's "approval state" without looking at collections (which might not be possible, in the case of POST-only collections, or might not be fine-grain enough, in case of a multiple-step approval when you're only given an "approved" collection, or an "approved" / "pending" collection pair). If that sounds weird, we might consider decoupling creation and listing endpoints [1]. You could then have a single creation endpoint you'll POST entries to and multiple listing endpoints depending on the entry's "approval state" (step): - POST to /submit creation endpoint - first shown in /pending - next into /processing - then into /rejected if rejected, or /approved if approved. where /submit doesn't support GET for application/atom+xml (it might send back an HTML form, but does not "list" a collection membership) and /pending, /processing, /rejected and /approved doesn't support POST (you must go through /submit). [1] Both http://intertwingly.net/wiki/pie/PaceDecoupleCreateAndListEndpoints and http://intertwingly.net/wiki/pie/PaceDecoupleDiscoverAndCreate have proposed such things, but with different goals, and the proposed solutions don't really help in our current use case (PaceDecoupleCreateAndListEndpoints seems to be modular enough to accomodate it _and_ the current "collection-as-a-whole" model, but has a bad rationale –I wrote, so I can criticize :-p –). -- Thomas Broyer
