Re: http get safeness

On Thu, 5 Feb 2009, Doug Davis wrote:

> I understand the dropped connection issue, but that can happen with
> anything. So regardless of the verb if you want to ensure 'something'
> happens then you'll need to add some sort of QoS to your interactions.

Well, if you know you can safely retry a request, having a simple 
timeout+retry system on the client side is sufficient, no need to rely on 
specific characteristic of the whole system. It's given by the safeness of 
the operation.

> However, I don't understand the notion of using POST to get the head.  I
> thought POST was for updating the resource. As a client trying to 'pull'
> the top item in the queue I certainly can't POST the new head - I have no
> idea what it is. Thinking more about my previous note... GET+DELETE isn't
> right either since DELETE would delete the resource and the URI should be
> bad after that - which isn't what I want either.

Well, in that case you are not just peeking the head of the list, you are 
also modifying it by removing the first item, so reorganizing the list. 
And yes DELETE will delete the resource (but perhaps not the object 
exported as a representation of this resource, if its goal was "delegate 
to this item in the list")

Note that you can have a URI for "head of the list" a potentially 
different URI for "this particular item in the list, which can be or not 
the head", and other ones for modifying the list or elements of the list. 
You are not limited by "one object == one URI", which is a common way of 
seeing things when you export an object via WS and use SOAP/wsa:action to 
pass the function name to the object.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Thursday, 5 February 2009 15:06:18 UTC