Re: REST and DELETE?

On Aug 25, 2012, at 12:50 AM, Jan Algermissen wrote:

I admit, though, that I'd love spending an hour of Roy's time on that topic :-)

Jan

> 
> On Aug 24, 2012, at 9:47 PM, Darrel Miller wrote:
> 
>> 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.
> 
> Think about it this way:
> 
> Because REST explicitly allows the server to independently change at any time, the messages sent by the client must be 'designed' to allow the server to detect any mismatch between the client's intent and what the server is about to do as a result of the request.
> 
> POSTing an explicit cart much more meets that goal that POSTing a URI does.
> 
> IOW, the semantics of the message (the deducable intended effect) must, under no cicumstances, be dependent on the nature of the recipient.
> 
> Makes sense?
> 
> Jan
> 
> 
> 
>> 
>> 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
>> 
>> 
>> 
>> 
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/rest-discuss/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/