Sam Ruby wrote: >[snip] > 1) Is it possible for implementations to outright fail to operate as > epxected if this constraint is not satisfied? > > If NO, consider MAY. Avoid making additional judgement calls. Accept > the additional complexity and interopability issues that this creates. > > If YES, ask yourself if there still are reasons why an implementation > might rightfully and willfully chose to ignore this. If so, chose > SHOULD. Else chose MUST. >
The main consideration for me on this are post-only, moderated an access-controlled collections. In such cases, server implementations should be able to choose not to return a Location header or have the newly posted entry appear in any feed that a client can see. That said, it should likely be tied to the type of response. If the server responds with a 201 Created, then I'd likely agree that the response ought to contain a Location header. If the server responds with a 202 Accepted, then the response shouldn't contain a Location header. Regarding whether or not the entry should appear in the feed is a separate question. If the response is 201 Created, I would say it likely SHOULD be listed in the feed *that the posting client sees*, but there are conceivable reasons why it would not (e.g. read permissions not currently granted to the client requesting the feed, the entry may be awaiting moderation, etc). If the response is 202 Accepted, I would say that it SHOULD NOT appear in the feed, at least not right away. Consider the following: In our implementation, we have an entry collection to which all users can POST new entries. Clients can only view entries for which they are the owner (original creator) or have been granted permission to read. When I post an entry to the collection, and Sam subsequently reads the feed, his view of the feed will not contain the entry I posted. Is that an error? - James >> Joe Gregorio wrote: >> >>> 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 > > - Sam Ruby > > P.S. Yes, I'm aware that it generally is easier to get a group > consensus around a word like "Should". To counter balance that natural > tendency, I'd like to challenge anybody who proposes such to justify > that the extra complexity and n**2 interop issues are vital to the > success of this protocol. >
