Re: Does idempotence include the response codes?

On Tue, Oct 15, 2013 at 06:30:44PM -0400, cowwoc wrote:
> On 15/10/2013 5:33 PM, Martin Thomson wrote:
> >On 15 October 2013 14:24, Mark Nottingham <mnot@mnot.net> wrote:
> >>>Yes. Adding "on the server" and an example would definitely help.
> >>Seems like a reasonable editorial clarification to me.
> >It's low cost and improves comprehension.  SGTM.
> 
>     A lot of my interpretation is coming from reading "RESTful Web 
> Services" published in 2007. Unfortunately, I'm seeing more and more 
> contradictions between this book and what I'm reading on Stackoverflow. 
> Just one example I got today:
> 
> http://restfulwebapis.org/RESTful_Web_Services.pdf page 274 says to 
> return 301 from operations that rename a resource, but the answer found 
> at http://stackoverflow.com/a/19388228/14731 recommends to return 200 
> and 301 to subsequent requests to the old URI. To be honest, both 
> approach have their downsides and both make sense. The spec doesn't seem 
> to point towards one solution or the other which leaves me wondering 
> which is the best approach.
> 
>     Is there a better/newer book I should read? httpbis contains many 
> useful pieces of the puzzle but it's not nearly as "complete" as reading 
> a book focused on authoring REST APIs.

I've read your comment about renaming a company and the risk of reusing
the same name for a new company later. I think you're having your mind
confused because of the difference between "network time" and "human time".

The main idea behind idempotence is to know whether or not a client can
safely resend a request that failed because of network errors. For example,
sending a request over an established connection may result in an error if
the server decided to close at the same time. But the client has no way to
know if the request was considered or not, so it must resend it. If the
previous request was correctly processed, the second one may return an
error, but it's the client's job to handle this. I can give you an example
here with unix commands :

  $ mv a b
  ... phone rings ...
  ... Hmmm where was I. Ah, I was about to rename "a" to "b"
  $ mv a b
  mv: cannot stat `a': No such file or directory
  ... Ah yes, I already did it, let's go on with next operation.

In my opinion it is reasonable to think that during this short retransmit
time, the company name "A" will not be reused to name a new company. And
if it's not true (eg: an application that many people are using in parallel
for a lot of administrative stuff), then it means that the company name is
not a safe key to proceed with operations, so your application needs to use
a permanent ID :

   GET /id-by-name/A

   { "owner" : "smith", "location" : "NY", "id" : "12345" }

   PUT /rename-id/12345

   { "name" : "B" }

But as you can see, the protocol in its current state offers everything
needed to handle this correctly. However it will not make an unsafe
application suddenly safe. The application needs to be safe in its
sequences and use the protocol correctly.

Hoping this helps,
Willy

Received on Wednesday, 16 October 2013 04:00:46 UTC