In response to David Peterson's The SimpleDB Epiphany: I Finally GET It... Why RFC 2616 Is To Blame I posted a quick note here, and a few comments on his blog. He asked a few questions, but as I got caught up with my day job, I could not completely elaborate my comment on why idempotency for pipelined requests is a protection and not a limitation. Here is the rest.
Here is why his assertion is inaccurate. Let's say, a client pipelines four requests to a server:
- Get (GET) something
- Update (PUT) something
- Update (PUT) something else
- Delete (DELETE) something
Now, let's imagine that the server started processing these pipeline of requests and responded with the the first response. At this time, let's say the client lost the connection to the server. But the client can not tell whether (a) the server processed all or some of the remaining requests but the response did not reach the client, or (b) whether the server did not process any of the remaining. The client can retry these requests, but doing so should not have side effects, e.g., creation of duplicate records, or deleting data that is not supposed to be deleted. But since all the requests in the above pipeline are idempotent, the client can safely retry the entire pipeline. That's the role of idempotency. Executing idempotent requests more than once yields the same result as would result by executing it once, barring bad server implementations.
In my version of SimpeDB, the following requests could safely be pipelined.
- Delete (DELETE) a domain
- List (GET) domains
- Update (PUT) attributes
- Delete (DELETE) attributes
- Get (DELETE) attributes
- Query (GET) items
All these are idempotent requests. The only non-idempotent requests in this API are:
- Create (POST) a domain
- Create (POST) attributes
These two kinds of requests can not safely be retried as doing so would have negative side-effects, e.g. creation of duplicate domains or attributes, and hence should not be pipelined irrespective of what RFC 2616 says. Fixing 2616 to allow non-idempotent requests in a pipeline is not the solution.
Overloading GET for all types of operations does not necessarily give the ability for clients to pipeline requests and thereby, for the server to provide the parallelization needed for a service like SimpleDB. The same rules still apply.