Subject: Re: [core] RE AW: Response codes for POST

From: Matthieu VIAL <[email-masked]>
Date: Tue, 1 Feb 2011 09:11:42 +0100

Klaus,

>An intermediary that sees an exchange like this

>> REQ: POST /alrm
>> <alrm type="fire"/>
>> RES: 2.01 Created /alrm/1
>>
>> REQ: GET /alrm/1
>> RES: 2.00 OK
>> <alrm id="1234" type="fire"/>

>knows exactly what's going on and will do the right thing regarding,
>e.g., cache invalidation and updating. A client receives the location
>of the created resource and can decide what it wants to do next. The
>two operations are decoupled and can evolve independently. These all
>are good properties of a RESTful design.

draft-ietf-httpbis-p2-semantics section 7.5 POST says:
Responses to POST requests are only cacheable when they include
   explicit freshness information (see Section 2.3.1 of [Part6]).  A
   cached POST response with a Content-Location header field (see
   Section 6.7 of [Part3]) whose value is the effective Request URI MAY
   be used to satisfy subsequent GET and HEAD requests.

so it seems to be allowed with HTTP but not for a new subordinate 
resource. 
The following response would be cacheable.
REQ: POST /alrm
<alrm type="fire"/>
RES: 2.04 Changed /alrm Max-Age=60
<alrm id="1234" type="fire"/>

Matthieu