Timeline for Deciding on method idempotency approach
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 6, 2016 at 21:01 | answer | added | gbjbaanb | timeline score: 1 | |
| Apr 6, 2016 at 15:30 | comment | added | JimmyJames | What is the issue with creating the object again? Are there sideeffects to object creation? The easiest solution is to create the new object and let it replace the existing one. | |
| Apr 6, 2016 at 15:13 | comment | added | dstr | @JimmyJames: We want to able to do this so our web service consumers call the create method again if anything goes wrong on their end after calling our create method. They should call the create method with the same parameters again we will return "created" result but not create the same object again. | |
| Apr 6, 2016 at 14:35 | comment | added | JimmyJames | Indempotecy simply means that if you write the same request multiple times, the resulting state will be the same as if you only did it once. What you are describing here seems to be something different. I think you are trying to avoid dirty writes. Idempotency doesn't prevent that. Can you clarify what you are looking to do? | |
| Apr 6, 2016 at 10:03 | comment | added | dstr | @gbjbaanb: it's not the id clashes we are worried about, it's the duplication of the object. | |
| Apr 6, 2016 at 8:57 | comment | added | gbjbaanb | GUIDs are supposed to be globally unique. If you assign them on the server then they will be guaranteed to be unique, so let the client assign a temporary one for creation but if you're worried about GUID clashes give it a new one when it gets stored. | |
| Apr 6, 2016 at 8:51 | history | asked | dstr | CC BY-SA 3.0 |