Re: REST and DELETE?

Hey Mark,

Thanks for the response.  The first two examples were really kind of a lead
in to the third which you didn't comment on.  Based on your explanation, it
would seem that as long as the user is confident that the server isn't
going to mess with their stored cart, then there is no reason why the user
cannot request that the contents of their stored cart be ordered.

The reality is that there needs to be a certain level of trust by the user
in the service they are using.  Whether, the user-agent downloads the cart
and re-posts it to an order processor, or the user-agent posts a link to
stored cart, the intent of the user is the same and a user-agent can quite
easily allow the user to preview the stored cart before posting the link to
be ordered.  I fail to see how a message that refers to a resource loses
its self-descriptiveness.

Regarding the need for the resource to be invariant is also a concern for
me.  Consider the following processing endpoint that stores images of
weather maps of cities.  If you post a text/url-list to it then it
dereferences those urls and stores the resulting image.

POST /WeatherSnapshots
content-type: text/url-list
http://weathernetwork.com/miami/currentweather

I don't see the benefit of forcing all the extra data transfer required to
do the following,

GET http://weathernetwork.com/miami/currentweather
=>
200
Content-type: image/jpeg
[bytes]

POST /WeatherSnapshots
content-type: image/jpeg
[bytes]

Imagine the scenario where several times a day a user wanted to take
snapshots of many cities at the same time.  It would be far more efficient
for the client to request that the server perform those requests on it's
behalf than have the client download each than then post them back to the
server.

Sorry for belabouring the point but it is an issue that does comes up
fairly regularly and when asked about it I don't like having to respond,
"you aren't supposed to do this, but I don't understand why".  There's
already enough dogmatic REST advice going around and I'd rather not
contribute to it.

Darrel