RE: NEW ISSUE: Methods and Caching

On Tue, 2008-11-18 at 06:39 -0600, Brian Smith wrote:

> It looks like something that was just overlooked to me. It almost never
> makes sense for the response to a POST to be returned for a GET request to
> the same request URI. It would be more useful for PUT (e.g. an AtomPub
> server could return a new representation of the entry in its response to a
> PUT).

The classic example of where a cacheable response to POST makes sense is
the guestbook example (or unmoderated blog comments for those needing a
more modern example, basically the same thing in a different era) where
the visitor POSTs an addition to the page currently viewed, or "separate
entity that accepts annotations" as it's expressed in the RFC. The
response given to the POST is the new representation of the page. Both
GET and POST uses the same URL in this example.

So you have the sequence

  GET /page

  200 OK, max-age=X

[user fills in comment form]

  POST /page

  200 OK, max-age=X

where the 200 OK response to POST is in all regards identical to that of
a GET following the POST.

Note that the POST request as such can never be satisfied from cache. A
repeated POST with the same form content will not yield the same result
even if the response is cacheable.

This only applies when the response to POST has explicit expiry
information as the response to POST has the duality of either being a
status message indicating the result of the action OR the modified
resource, both using the 200 OK status code. There was a discussion some
time ago about adding a new status code to separate the two cases to
make this property of POST more explicit, but iirc the conclusion were
that 200 OK is actually fine for both cases. But this property of POST
do need a better explanation.

PUT on the other hand is not really meant to perform any server-side
processing of the resource, only storing it "as-is" and adding relevant
meta data such as ETag (which returned in the response) and Content-Type
if not supplied by the client (not returned in the response). For all
practical purposes (i.e. continued authoring of the resource) the client
SHOULD be able to use the resource it sent in the PUT request as it's
current representation of the resource, even if it may differ slightly
from what the server actually stored. Because of this the response to
PUT is always a status message. There has been discussions about
extending PUT to allow it to return a modified representation, and any
such negotiated extension would place those responses in the same family
as POST above, returning a representation that is a valid representation
as if the request had been a GET request immediately after the PUT.

Regards
Henrik

Received on Tuesday, 18 November 2008 15:29:34 UTC