3 ms·
A real-world example from my previous job. You have a chat in your mobile app. Messages are sent using HTTP requests, and received using HTTP long polling. Now
by grishka 5y ago
A real-world example from my previous job. You have a chat in your mobile app. Messages are sent using HTTP requests, and received using HTTP long polling. Now imagine sending a message over a slow network while on a departing subway train (service is only at stations). TCP & SSL are established successfully, then the request itself is sent, but you leave the network coverage before you receive the response. So you have no idea whether the message was actually sent. When you reconnect at the next station, you receive a message over long poll, but — because the request failed as far as you're concerned — you have no idea whether it's the message you sent. To resolve this, you need to have the ability to ask the server for a response to a previous request, but without actually performing that request a second time. Or, alternatively in this particular case, you need the server to accept a unique client-generated ID in the request and return it to you over long poll.
- quesera 5y agoThat's one valid use of an idempotency token. Also e.g. POST submission of an order or transaction. But these are implementation-specific, and available (and in active use) today under a few common HTTP header names. It's not clear why the header name should be standardized. You could move idempotency implementation up to the load balancer or the proxy layer. I'm not convinced that would be useful, because to implement the hard parts of idempotency (esp across instances), you'd need to add a bunch of extra complexity there, which is already a committed cost at the application layer. But if, say, haproxy or nginx release a new distributed idempotency caching feature, maybe that would change my mind.
- ec109685 5y agoAll that layer really needs to do is support caching objects. When response is returned, cache based on idempotent cache key, and on subsequent requests, lookup that value before making downstream requests. Also, should extend the key’s value with an unguessable session id, so folks can’t can’t guess the key and read someone else’s data.
- quesera 5y agoYep, but that idempotency caching layer would need to share keys across all instances, possibly even geographically. This is a solved problem at the application layer of course, but adding complexity at the higher (LB or proxy) layer ... well, adds complexity there and the benefit is not clear to me.
- tptacek 5y agoI think you're misunderstanding my question. I understand why idempotency tokens are valuable. What's not clear to me is why HTTP would need an "official" idempotency token. The behavior of APIs that run over HTTP is not properly part of the HTTP specification.
- aenis 5y agoMaybe to make it easier for people to understand the concept - and reinforce a good design pattern? I implemented this stuff my own way whenever I needed it (e.g., for a chatbot), and every time i needed to take the time to explain it to the client app dev teams. Sometimes it took longer than desired, and pointing them to a well written RFC would help.
- tptacek 5y agoThis is a little like saying there should be an RFC for understanding and defending against SQL injection, isn't it? Like, there are a lot of concepts that would be well-served by an "official document", but that's not the purpose of IETF RFCs.