On Wed, 2006-03-15 at 17:40 +0100, Thomas Broyer wrote: > 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).
Actually, based on prior discussions, I've been assuming that this sort of decoupling was already allowed by the spec, and that signaling write-only (or read-only) collections was to be done with HTTP OPTIONS. I wouldn't want to force decoupling on an implementation to get a simple workflow, though. It really shouldn't be necessary, given that collection feed contents can be user-specific. - Michael
