On Sun, 2007-02-18 at 20:50 +0000, wahbedahbe wrote:
> Hmmm not sure if I'm over simplifying but in a nutshell these
> protocols
> are just trying to repeatedly POST/PUT to a resource identified by a
> unique id. I think you can just rely on PUT for idempotency and the
> rest
> just depends on who you want to generate the id.
> If the clients can generate unique ids, then why don't they just
> repeatedly PUT to http://example.com/<myuniqueid> ?

I was having this thought just last night, and I can't say I disagree :)

Just use a PUT and let the client pick a globally unique ID. The server
can then either continue using the resource the client identified in the
first place for redirect the client for to the "real" name of the
resource further interactions. I would lean towards the former.

It's an interesting perspective that essentially elminates the POST at
most once issue by eliminating POST. Do we really need our scruffy
fourth method?

> If you'd rather the server "allocates" ids then
> >> POST /factory
> << 201 Created
> << Location: /factory/<auniqueid>
> Then then client repeatedly PUTs to
> http://example.com/factory/<auniqueid>

This was one of the proposals I wrote up early in the thread, though it
still has its problems in terms of server resources needing to be
cleaned up.

> There seems to be some worry about "reclaiming" an unused id after a
> period of time, but is that really a concern? You don't really
> "allocate" or "do" anything on the POST. You just make sure you never
> send back the same id twice which isn't that hard. You don't even need
> to keep track of what you've sent. If you're worried about the client
> making an id up, you could either a) not care -- this is essentially
> back to the client-generated-id case, or b) sign your ids so you can
> detect a fraud.

This would still be an issue if you did the redirection thing, or if the
resource was destroyed soon after creation. You would need to keep both
urls around in case the client continued to send PUT requests to their
defined url. It's a horizontal scalability thing. If you need to store
information based on a client request, then you need all of the servers
in your cluster that might recieve the next request to know that
information before the next request comes in. It's statelessness between
requests, a fuzzy but important constraint in REST. Ignore it at your
peril, but most of us will need to bend it to varying degrees. The long
an the short of it is whenever and however far you bend it, make sure
you're getting paid enough to deal with the scalability issues the
bending introduces.

Let me do the concrete proposal thing again.

Problem statement: (same as before)
I have some state that I want to append to a resource. The right method
according to HTTP is POST, but if I don't get a response to my POST I
don't know whether or not to retry.

Client algorithm:
...
guid = generateCryptographicallySafeGloballyUniqueID();
// Perhaps this uri template is retrieved from a GET to what would have
// been our factory resource, or from a broader form that the user
// filled-out.
request.populateURITemplate("http://airline.example.com/ticketsales/{user}/{guid\
}",user,guid);
startOrResetTimer(reasonable resource state retention period, eg 2min);
try
{
retryPUT:
factory.PUT(request);
}
catch (NoResponse) // aka GatewayTimeout
{
// One of two possibilities exist. Either,
// * our PUT didn't arrive, or
// * our created resource has been destroyed already
// We try to ensure that the latter doesn't
// happen by giving up after a reasonable
// period, though we may have confidence that it won't
// be destroyed quickly and just keep retrying
goto retryPUT;
}
catch (RetentionPeriodTimeout)
{
// It is still possible that we could successfully
// send the request at this point... but it could have
// been created and destroyed again given the time we
// have taken so far. We had better give up.
}
catch (...)
{
// Normal error handling
}

If we get a 201 we know that this is the first successful request. If we
get a 200 we know that a previous request had already succeeded, but we
have successfully changed state. A 410 Gone might indicate that the
resource was created and then subsequently destroyed. Some other return
codes might mean successful delivery, eg Not Modified might play some
part. However we should probably keep things simple.

I would suggest keeping the URI ranges user-specific for security and
cross-pollentation reasons. We don't want one user going and blatting
over the uri-space and preventing other valid requests from getting
through. Client GUIDs should probably be cryptographically safe to avoid
giving away secret information.

Server responsibilities:
* Don't destroy the resource too quickly, or the client won't know for
sure whether it was created in the first place. Consider leaving a 410
in place for some time if the resource is destroyed quickly.

Benjamin