5 ms·
This just moves the concurrency issue to the client, particularly for xhr requests. Say you double click on some action with a one time token, the first reques
by mbell 12y ago
This just moves the concurrency issue to the client, particularly for xhr requests.
Say you double click on some action with a one time token, the first request gets to the server and succeeds while the second request fails due to the token being used. But, the response to the first request is delayed and the second response (failure) gets to the client first. The client can either 'obey' this failure response or wait till all in flight requests return (or maybe till one comes through with success). The solutions to dealing with this look a lot like debouncing/throttling the requests in the first place.
Using a one time token is very useful for avoiding multiple executions of non idempotent operations but it's really a separate issue from dealing with multiple requests/responses on the client. i.e. the UX.
- scrollaway 12y agoSubsequent requests to the same token don't have to fail - they just have to silently pass.
- mbell 12y agoThat doesn't make the situation any better. Request 1 takes the 'token' Request 2 sees the token gone, returns 'silent success' Request 2 response reaches client, client assumes success. Request 1 fails somewhere internally Request 1 returns failure to client, which has already acted on the success of request 2 User thinks the action was successful, when it wasn't. Now, you can build yourself a lovely two phase commit system around the token and the operations performed by the action to deal with a UI issue, or you can just throttle the requests.
- scrollaway 12y agoIf the first request errored, you can error on the second one as well. I don't see the problem.
- mbell 12y agoIf there is no throttling, there could be a dozen requests, with different responses arriving in arbitrary order. Which one do you believe to determine the outcome of the operation? How long do you wait for responses? etc. etc. If your going to build all the machinery in the client to deal with this situation, it's much easier to just throttle.
- scrollaway 12y agoI'm not saying "don't throttle". I'm just saying tokens can work pretty well too...
- yesiamyourdad 12y agoWhy not treat this the way a REST web service would? Request 1 submits token Request 2 submits token Response 2 returns first with a 409 conflict Response 1 returns with a 200 OK It's a question of handling the error codes properly. 409 means resubmit with a new If-Match. Other 400-series errors indicate some other problem with the client's submission. Actually, if I were reviewing the original author's proposal, I'd say that double-click should be disabled only on <form method="post">
- mbell 12y agoThis has nothing to do with REST, the same issues exist.
- yesiamyourdad 12y agoWhat do you mean it has nothing to do with REST? It's an application built on HTTP. The same issues do not exist. Response 2 does not return "silent success" it returns 409 Conflict. The client can distinguish between conflict & success.
- mbell 12y agoThe error codes nor the transport are important here. You can make an arbitrary number of requests that can respond with various responses (or fail) in arbitrary order. Who do you listen to? Which response is 'correct'? Sure you can build a service on the client to track the requests, the order they are issued in, what responses supersede other responses, how long to wait for all responses, etc, etc. But why build such a complicated solution to such a simple problem?