Hacker News Reader

Comment by lcw | Hacker News Reader

Although PUT is not necessary using it for idempotent calls like it was designed to do actually helps developers using the API understand the intent of the call better. They don't have to worry about undesired consequences/side effects. Which I think is a useful pattern.

View on HN

> Although PUT is not necessary using it for idempotent calls like it was designed to do actually helps developers using the API understand the intent of the call better. They don't have to worry about undesired consequences/side effects.

This can also be solved by futures. Any POST that you'd like to retry, which will be any of them given the unpredictability of network partitions, can be bound to a future so the operation is applied only once and all future attempts simply return the bound value.

The point of having something like PUT (that is known to be imdepotent) is that it can be retried by any of the layers in the stack, instead of having a full roundtrip back to the client on every retry.

And it's not always safe to retry POSTs. If POST is an insert, for example, retrying it would produce two inserts. And this can have interesting consequences when processing responses. Suppose that you have sent a POST request, but before you could read the response, connection dropped. You didn't get a chance to read the status code, so you don't know if your insert succeeded or not. If it didn't, you want to retry - but you'll need to do a GET first to check the current state of affairs. OTOH, if you're doing a PUT, you can just retry immediately without re-checking.

> And it's not always safe to retry POSTs. If POST is an insert, for example, retrying it would produce two inserts. [...] Suppose that you have sent a POST request, but before you could read the response, connection dropped.

My previous post already covered idempotent POSTs via futures. The fact is, only the application can decide whether a POST is safe to retry arbitrarily or must be made safe by binding to a future. The PUT is merely a small optimization that is now obviated by the spread of HTTPS.

You assume the entire stack is HTTP end-to-end, which is not always the case.

How am I assuming that exactly?

"The PUT is merely a small optimization that is now obviated by the spread of HTTPS."

Still not seeing how that line means I'm assuming HTTP end to end.

If I understand your point correctly, you're saying that when something is talking over HTTPS, the middleware doesn't get to see the verbs, and so it can't optimize for them anyway. But if part of your connection is using different transports, then middleware in those segments can observe the verbs and react accordingly (including e.g. local retries in face of adverse network conditions, to avoid expensive end-to-end roundtrips).

While technically correct, I'm not sure how this is useful. You use HTTPS to communicate with an endpoint you trust, and anything beyond that is internal network infrastructure which is much more reliable than the HTTPS hops. The utility of local retries on this last hop don't seem compelling.

> The PUT is merely a small optimization that is now obviated by the spread of HTTPS.

Idempotence can be useful knowledge for client-side caches, so HTTPS doesn't obviate the value of the PUT (or, for the same reason, DELETE) vs. POST distinction.

I agree that it's potentially useful, but it also adds it's share of complexity to any implementation I've come across. And most proposed uses I've seen do not obviously benefit from the idempotent approach, from my experience it often complicates the server implementation. I've found using the REST approach for URLs, separating reads from writes and using status codes a good compromise.

Reply on news.ycombinator.com