RE: Associated resource for PUT

Amos Jeffries wrote:
> On 11.07.2012 05:12, Robert Brewer wrote:
> > Julian Reschke wrote:
> >> On 2012-07-10 16:55, Robert Brewer wrote:
> >> > Section 5.1 of draft-19 part 2 says, "An HTTP request
> > representation,
> >> > when present, is always associated with an anonymous (i.e.,
> >> > unidentified) resource." [1]  That makes perfect sense for POST,
> >> but
> >> for
> >> > PUT it makes sense IMO to declare that the representation is
> >> associated
> >> > with the target resource. Or is the intent that the representation
> >> "is
> >> > *to become* associated", and is therefore considered anonymous
> > before
> >> > the request had been handled?
> >>
> >> Yes, that's (IMHO) the intent. The decision is up to the server
> >> (after
> >> all, it could reject the request).
> >>
> >> > This is important for at least one reason: I believe this section
> >> in
> >> the
> >> > HTTP spec could be useful to establish a base URI for request
> >> entities
> >> > according to section 5.1 of the URI spec [2] (which itself might
> >> be
> >> > underspecified in this regard; it doesn't say much about
> >> operations
> >> > other than retrieval).
> >>
> >> Do you need that functionality until the time the PUT has succeeded?
> >
> > The server needs to establish a base URI for any relative URI's in
> > the
> > request entity. If the entity itself does not include a 'base'
> > attribute
> > (and many media types do not allow for one at all), it seems natural
> > for
> > PUT to default to the Request-URI, rather than leave it up to the
> > application to specify (and then document) for each URI.
> >
> 
> The same would appear to be true for POST entity relative URLs as well.
> Is there some problem I'm overlooking?

Yes, the server also needs to establish a base URI for POST entities. It's just not as clear-cut what that base should be for POST; for example, lots of resources have been designed as a collection to which one POSTs an item which then exists at a different URL chosen by the server. So the option of using the Request-URI isn't as obvious as it is for PUT, and it seems more natural to assume the server must decide and describe some application-specific default.

The base URI of a GET response is so obviously the Request-URI, it's a bit surprising that for some reason that hasn't been as obvious for the base URI of a PUT request, given their semantic symmetry. Is there any use case (or even any facility) to have the base URI of a PUT request be some other URI? Can you return 201 Created with a Location of some other URI for PUT? If not, then it's a bit misleading to say "An HTTP request representation is always associated with an anonymous resource."


Robert Brewer
fumanchu@aminus.org

Received on Tuesday, 10 July 2012 23:54:47 UTC