> The client might see an OK response to the first call and error responses to the others, but from the server's perspective, it's the same as if the call had only been made once. That's what makes it idempotent.
This seems like a rather hollow meaning of idempotency. HTTP is a communications protocol. Why bother specifying idempotency if it doesn't apply to the communications?
The client gets no benefit at all if the server doesn't faithfully serve idempotent responses, and in fact a great deal of the benefit of idempotency is lost. Specifically, the client cannot reasonably resume a dropped connection if the server changes its responses during a retry scenario (which RFC2616 says the client should do). Would it be idempotent if the first response to "PUT /foo" was 204 and the second response was 405?
You're mixing up safety with idempotency. What you call "idempotent communications" are only possible on a read-only server: if the state of a server can change, then the communications must change to reflect that. HTTP doesn't assume a read-only server: three of the common verbs (GET, PUT, and DELETE) are idempotent, but only one (GET) is safe.
No, I'm not. HTTP is a communications protocol. It doesn't dictate what a server should be doing internally, only how it should behave in the context of an HTTP session. If idempotency isn't important to the communications, why put it into the standard? For that matter, if idempotency is only relevant on the server side, then the server could do anything in response to a client request and it seems that the spec would be satisfied.
void processRequest(httpcontext c)
{
// who cares?; this looks "idempotent" to everyone
doSomethingArbitrary();
c.status = rand();
}
RFC 2616 specifically discusses resuming in the face of dropped connections. This is only feasible if calls are idempotent from the client perspective (as well as the server perspective).
This seems like a rather hollow meaning of idempotency. HTTP is a communications protocol. Why bother specifying idempotency if it doesn't apply to the communications?
The client gets no benefit at all if the server doesn't faithfully serve idempotent responses, and in fact a great deal of the benefit of idempotency is lost. Specifically, the client cannot reasonably resume a dropped connection if the server changes its responses during a retry scenario (which RFC2616 says the client should do). Would it be idempotent if the first response to "PUT /foo" was 204 and the second response was 405?