Joe Gregorio wrote:
> [snip]
>> Also, the protocol indicates that POST is used for creation of
>> resources, however, POST is only defined on the Collection URI. There
>> has been discussion about and there is an example of (gdata) using the
>> POST method on Member resource edit URI's for purposes other than
>> creation of resources. Perhaps it would make sense to include a note
>> that the behavior of the POST operation on any URI other than the
>> Collection URI is undefined.
>
> We don't say what the response for HEAD for any resource is, or MKCOL,
> or PROPFIND, do you see where this is leading? The 'undefined-ness' of
> methods we don't specify is part and parcel of working with HTTP.
>
I mentioned POST specifically because we explicitly state that POST is
used for creation of entries without qualifying that it's only POSTs on
collections that is defined.
>>
>> Section 5.3.2
>>
>> 1. The client PUTs an updated representation to the Member's URI.
>>
>> This should probably be "The client PUTs an updated representation to
>> the Member's edit URI" given that there is a distinction between the
>> Location URI and the edit URI as specified by the edit via (e.g. the
>> gdata api).
>
> The text you quoted says Member's URI and not Location URI, so I'm
> not quite sure it needs to be changed.
>
Either way, it's not clear. e.g., In the gdata API, which URI is the
"member URI" ?
>>
>> Also,
>>
>> 2. Upon a successful update of the resource the server responds with
>> a status code of 200.
>>
>> Would not a 204 No Content be appropriate as well given that we're not
>> requiring or recommending the update to return a response?
>
> Agreed.
>
>> Also, should we recommend that a PUT response contain the entry just
>> like with POST requests?
>
> I don't believe so, the reason it is a SHOULD on the original POST is that
> it allows the client to get the atom:id. We don't need that for
> subsequent PUTs.
>
Fair enough.
>>
>>
>
>>
>> Section 7.2.2
>>
>> appCollection+ should be appCollection*
>
> Agreed.
>
>
>> Section 9
>>
>> The entries in the returned Atom Feed MUST be ordered by their "atom:
>> updated" property, with the most recently updated entries coming
>> first in the document order. Clients SHOULD be constructed in
>> consideration of the fact that changes which do not alter the entry's
>> atom:updated value will not affect the position of the entry in a
>> collection.
>>
>> If the client PUTs an atom:entry with an changed atom:updated, is the
>> server required to honor it?
>
> No.
>
> -joe
>
