[openstreetmap/openstreetmap-website] Idempotency for API 0.6 (#2201)

[mmd]

@simonpoole : right, this inevitably includes ideas like throwing away the whole changeset unless the changeset is properly closed  ([link](https://wiki.openstreetmap.org/wiki/Original_Changesets_and_Reverts_Proposal_2008#Outlook:_transcations)). Clearly, that's something well beyond the scope of this issue. We would immediately inherit all of the issues of the asynch queues (https://github.com/openstreetmap/openstreetmap-website/issues/2201#issuecomment-484484302). That's all not too far away from having some kind of staging area to stash all changes. Say Hello to the world of branches, commits and merge (conflicts), this time with OSM data.

@mvl22 : there are some similarities to https://github.com/openstreetmap/openstreetmap-website/issues/2201#issuecomment-480499265 in the "let's handle all POST requests approach", only that you're creating the key based on a payload hash - which is something we discussed in https://github.com/openstreetmap/openstreetmap-website/issues/2201#issuecomment-485143934 as calculating a checksum. As I noted in https://github.com/openstreetmap/openstreetmap-website/issues/2201#issuecomment-485145410 this may or may not be possible, depending on the endpoint semantics and needs to be clarified. Keeping the full blown XML response around in a table was already questioned in https://github.com/openstreetmap/openstreetmap-website/issues/2201#issuecomment-484396809. 





-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/2201#issuecomment-488992236
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20190503/361d921e/attachment-0001.html>