Timeline for What does "side-effect" mean in the context of "Idempotent HTTP methods may not have side-effects when repeated multiple times"?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 17, 2020 at 13:37 | comment | added | mentallurg | @PhilipKendall: This a matter of interpretation :) Unfortunately the RFC is not so precise. We can say what if an exception occurred in the code? What if the database is not available at this moment? What if DB storage is full? Etc. I find that the intended effect is the same - to delete an object. But it is hard to argue if we didn't define terms - what is "intended effect", what are possible constraints, etc. | |
| Jun 17, 2020 at 13:27 | comment | added | Philip Kendall | @mentallurg I basically agree with you, but there's possibly an edge case if permissions exist in the system and the user making the DELETE call does not have permission to delete the recreated object. | |
| Jun 17, 2020 at 13:23 | comment | added | mentallurg | @MartinFürholz: ... If we apply this definition to your example with 10th DELETE: The purpose is to delete an object with particular ID. 1) If other methods created objects with other IDs, we ignore them because they are not the intended effect for particular DELETE request. 2) If a new object was created with the same ID, 10th call of DELETE will delete this newly created object. The intended effect (an object with given ID should not exist any more) is again reached. Thus, despite other calls in the meanwhile, DELETE is idempotent according to the given definition. What you think? | |
| Jun 17, 2020 at 13:19 | comment | added | mentallurg | @MartinFürholz: You right that RFC does not defines that clearly. You cited RFC 2616. The RFC 7231 gives better definition (also not perfect): if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. It still has room for interpretation. But in my opinion it implicitly separates different calls..... | |
| Jun 17, 2020 at 12:03 | comment | added | Philip Kendall | @MartinFürholz the RFC makes it clear that a sequence can be non-idempotent if something else is modifying the state of the system: "a sequence is non-idempotent if its result depends on a value that is later modified in the same sequence." | |
| Jun 17, 2020 at 11:58 | comment | added | Martin Fürholz | @mentallurg No, there can happen thousands of things between subsequent requests. Nowhere does it say, that nothing else may change the system state, or state of a resource/representation between those requests. | |
| Jun 17, 2020 at 11:37 | comment | added | mentallurg | @MartinFürholz: To "between the second and the 10th DELETE request?" - the RFC talks about subsequent requests. I.e. in this time there are no other requests. If some other requests happen, then such case says cannot be used to decide if it is idempotent or not. | |
| Jun 17, 2020 at 9:47 | comment | added | Philip Kendall | That definition of idempotence applies only if there are no other processes interacting with (the relevant bit of) the state of the system. If the system is in a state S'', different from both S and S', when the request is received, there is no requirement for the repeated request to transition to the state S'. | |
| Jun 17, 2020 at 9:38 | comment | added | Martin Fürholz | What if the resource was re-created between the second and the 10th DELETE request? | |
| Jun 17, 2020 at 9:23 | history | answered | Philip Kendall | CC BY-SA 4.0 |