Skip to main content
Software Engineering

Return to Answer

added 210 characters in body
Source Link
Lorenzo Dematté
Lorenzo Dematté
  • 698
  • 1
  • 5
  • 14

We faced the same issue and, as others suggested in comments, we made our POSTs idempotent. You can return a different code (in the 200 family) if the file was already there, just to inform the client (or you can just answer "200"). In our experience, this also plays nicely with "not-so-connected" devices (smartphones); if you need to retry a submission, you just retry it, without worrying of duplicates. You can make (and store) a UID that is based on the document content (a MD5 or SHA hash) and maybe even use it as your primary document ID.

We also considered making the client code more complicated, adding a GET to check if a particular document was already inserted:

  • GET (is this document present?)
  • POST (insert document)
  • ...

but this make the client heavier (especially if you compute the hash twice). It does not really waste bandwidth (in our case, being on a cell network, it was an important issue); most of the time, you just POST once and receive a OK answer (document was not there).

AND it will not solve your issue anyway; if you POST the document from another page just after the GET? Still, you can combine the two approaches, if you see that the double POST happens many times in your web application.

We faced the same issue and, as others suggested in comments, we made our POSTs idempotent. You can return a different code (in the 200 family) if the file was already there, just to inform the client (or you can just answer "200"). In our experience, this also plays nicely with "not-so-connected" devices (smartphones); if you need to retry a submission, you just retry it, without worrying of duplicates. You can make (and store) a UID that is based on the document content (a MD5 or SHA hash) and maybe even use it as your primary document ID.

We also considered making the client code more complicated, adding a GET to check if a particular document was already inserted:

  • GET (is this document present?)
  • POST (insert document)
  • ...

but this make the client heavier (especially if you compute the hash twice). It does not really waste bandwidth (in our case, being on a cell network, it was an important issue); most of the time, you just POST once and receive a OK answer (document was not there).

We faced the same issue and, as others suggested in comments, we made our POSTs idempotent. You can return a different code (in the 200 family) if the file was already there, just to inform the client (or you can just answer "200"). In our experience, this also plays nicely with "not-so-connected" devices (smartphones); if you need to retry a submission, you just retry it, without worrying of duplicates. You can make (and store) a UID that is based on the document content (a MD5 or SHA hash) and maybe even use it as your primary document ID.

We also considered making the client code more complicated, adding a GET to check if a particular document was already inserted:

  • GET (is this document present?)
  • POST (insert document)
  • ...

but this make the client heavier (especially if you compute the hash twice). It does not really waste bandwidth (in our case, being on a cell network, it was an important issue); most of the time, you just POST once and receive a OK answer (document was not there).

AND it will not solve your issue anyway; if you POST the document from another page just after the GET? Still, you can combine the two approaches, if you see that the double POST happens many times in your web application.

Source Link
Lorenzo Dematté
Lorenzo Dematté
  • 698
  • 1
  • 5
  • 14

We faced the same issue and, as others suggested in comments, we made our POSTs idempotent. You can return a different code (in the 200 family) if the file was already there, just to inform the client (or you can just answer "200"). In our experience, this also plays nicely with "not-so-connected" devices (smartphones); if you need to retry a submission, you just retry it, without worrying of duplicates. You can make (and store) a UID that is based on the document content (a MD5 or SHA hash) and maybe even use it as your primary document ID.

We also considered making the client code more complicated, adding a GET to check if a particular document was already inserted:

  • GET (is this document present?)
  • POST (insert document)
  • ...

but this make the client heavier (especially if you compute the hash twice). It does not really waste bandwidth (in our case, being on a cell network, it was an important issue); most of the time, you just POST once and receive a OK answer (document was not there).