mvl22
commented
5 years ago Rather than require clients to send a token and have responsibility for checking this, would one approach, which I suspect would not require substantial changes to the server infrastructure be:
- Whenever a POST comes in (for any API call), create some kind of hash of the incoming data, first omitting anything which is known to be different (e.g. the request time).
- Store the hash in a global table of
requests(hash, response)which is a table of incoming hashes and responses where each entry has a lifetime of say one day or a week (as users/clients are unlikely to retry after that). - When the server has processed the request and sends back the response set the
responsefield to the response XML and continue the response to the client as normal. - If the server receives a repeated request that has the same hash, i.e. the client has just resent the same request, immediately send back the same response, without any further processing. For good practice, send an additional header stating that this is a cached response.
This would seem to me to require no changes to any client, and eliminate almost all duplications on the server, with the code change essentially just a global interception to any POST request by implementing that cache at that level.
This approach admittedly does not solve Andy's point:
But that still doesn't work, since if the server receives a new trace, and then the owner changes the description 2 seconds later on the website, and the server receives the same creation request 2 seconds after that, it doesn't have enough information to know if it's an intentional recreation or just a resent request.
but I don't think that is actually solvable, because a changed description is by definition a change in the request and could constitute a deliberate and separate change to the data.
simonpoole
androideveloper
mmd-osm
API 0.6 has no concept to prevent duplicate POST operations, which could happen as a client retries a failed network operation. As per RFC 7231, POST operations are not idempotent, which is quite unfortunate in particular for diff uploads: assuming the changeset consists of "create" operations only, those objects might be created multiple times on the database.
I've created this issue to discuss different options (such as adding a downward-compatible HTTP Header "Idempotency-Key"), and find ways on how to implement it in the API.
Some pointers:
Link proposes as part of their RESTful API guidlines:
A client specific idempotency key provided via Idempotency-Key header in the request. The key is not part of the resource but stored temporarily pointing to the original response to ensure idempotent behavior when retrying a request (see May: Consider to Support Idempotency-Key Header).