Re:After 1 minute on my modem (2016)
by akiselev on Saturday January 14, 2017 @01:49PM
(#13399869)
Wouldn't it be easier to add a retry=true to the request, at least if your implementing exponential back off in an existing codebase? Then you just hash the request (minus the retry field) in your cache layer and send the saved response again. You'll need a little extra code to update timestamps on the client side but the server side can be implemented as middleware in most frameworks. Expire the cache after a reasonable total timeout and make the client do a new read if they try to retry after cache has cleared it.
[ Parent
| on HN ]
I think you need client side UUID instead of just retry=true for requests that can be repeated with the same params.
E.g. /inrement?retry=true, server gets 3 of them - how many times should it increment? Is it just that user still haven't received the first response, or should we increment 3 times because it was send/fail/retry/ok 3 times on the client side?
But with this UUID it still can be easily implemented as a middleware.
but you shouldn't use a GET request for incrementing, right? do people (or popular frameworks' defaults) really do that? frequently?