Wait a second - we just completely trashed the idea of a complete representation here. By definition, the "complete representation" of an entry is what is obtained by making a GET request on the href of the link/@rel='edit'
So, you are guaranteed to get a complete representation on a GET to that href. This is the mandate of RFC 5023.
Nikunj Subbu Allamaraju wrote:
That makes sense, but what is the guarantee that a response to a GET is complete? Looking at 5023, there is no MUST to return a complete representation on GET.Subbu On Apr 24, 2008, at 9:00 AM, James M Snell wrote:Yes, Content-Location does indicate that the body contains a representation of the resource; the question, however, is whether you can consider that to be a *complete* representation, which could be used for editing, etc. It's most reliable to not to assume that it's a complete representation and to always do a GET if you need the complete representation.- James Subbu Allamaraju wrote:Could you clarify? 2616#14.14 defines the Content-Location independent of the verb being used. My reading is that Content-Location does indicate that the body includes a representation of the resource.Subbu On Apr 24, 2008, at 7:15 AM, James M Snell wrote:PUT can return an entity. No the entity cannot be considered to be a complete representation, even if the response contains Content-Location. You'll need to issue a GET to retrieve the complete representation.- James Daniel Jalkut wrote:My current reading of the RFC indicates that PUT does not return an entity. Just a status code. Does anybody have an opinion as to whether it leaves room for an entity to be returned? I can't tell.Daniel On Apr 23, 2008, at 2:28 PM, Nikunj Mehta wrote:If the response to a PUT request on an entry's edit URL contains an entry document in a 200 response, then1. Can the response entity be considered a complete representation? 2. What if the response contains Content-Location header? The HTTP spec states that Responses to this [PUT] method are not cacheable.As per that, an HTTP cache is unlikely to hold on to the response entity and use it upon a subsequent GET to the same entry's edit URL, correct?Nikunj