On 3/29/06, James M Snell <[EMAIL PROTECTED]> wrote: > > > 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.
A resource is a resource, if the server created it there shouldn't be a problem with returning a Location: header. The server can enforce the read-only nature of that resource using authentication. You aren't suggesting using security through obscurity, are you? > > If the server responds with a 201 Created, then I'd likely agree that > the response ought to contain a Location header. SHOULD > If the server responds with a 202 Accepted, then the response shouldn't > contain a Location header. MAY NOT > 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. You are necessarily constrained to talking about the 'posting client' only since we are talking about a URI returned in the Location: header. > 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? No, see above about the Location: header. Now a 202 does not indicate a successful creation, only that the server is in the process of working on it, so I don't see any of the above discussion contradicting anything in -08, but I do see a need to add a clarifying sentence or two to Section 8.1: """If a POST to a collection results in a member resource being successfully created then an entry SHOULD appear in the collection feed that has a link/@rel='edit' with an @href that matches the URI returned in the Location: header. Some reasons that an entry might not appear in a collection feed include: the member may have been deleted between creation and the time the client retreives the collection document, or the collection may represent a blind dropbox where collection members may be created by one groupd of people but can only be read by a third party, for example a collection for students to POST homework results to that can only be read by the teacher. """ -joe -- Joe Gregorio http://bitworking.org
