RE: questions -- clarifications requested

Shel writes:
]
] More ruminations.
]
] Paul Leach writes:
]  > For POST, the situation is more complex, since it says that the entity
]  > returned is
]  > 	"an entity describing or containing the result of the action"
]  > If there were a way to determine that it contained the result of the
]  > action,
]
] What does that mean?  By definition what is returned as the result of
] an action is the result of the action.

I didn't write it! Here's what I thought it was saying:  there could be 
two flavors of POSTs; an example of each might be:
Flavor 1:
The entity-body in the request says "order 17 gross of 3 penny nails"; 
and the the entity-body in the response says: "your order has been accepted".
Flavor 2:
The entity-body in the request says: "fetch me item 33" and the 
entity-body in the response is item 33.

The first is an example of the entity-body describing the result of the 
action; the second is one containing the result of the action.

In flavor 2, one could expect to do a GET on the URL in the Location 
header field in the response, and get item 33 again. For flavor 1, 
although it conflicts with your observation below, it doesn't seem to 
me to make sense that there _must_ exist a URL to put in the Location 
header such that a GET on it would return an entity containing "your 
order has been accepted" again.  Nor does it seem very useful to cache 
either "order 17 gross..." or "your order has been accepted".  Is that 
really the intent?

]
]    and some guarantee that a subsequent GET (of the URI specified
]  > by the Location header in the response) would fetch this entity,
]
] That is what the Location header is defined to do.  The alpha 1.1 spec
] says:  "For 2xx responses, the location should be the URL needed to
] retrieve that same resource again ...".  This presumably means, e.g.,
] by using GET.

That's what it says all right. Inattentive me -- I didn't mentally 
integrate the it with the semantics of POST (or PUT) properly -- I was 
reading it in the context of GETs that did content negotiation. For 
PUT, that certainly seems to be strong enough to allow the caching of 
the request entity-body using as a key the URL specified in the 
Location header in the response. For POST, I still have the 
reservations noted above.

Paul

Received on Tuesday, 29 August 1995 20:56:18 UTC