About me: software developer who is into JavaScript and NodeJS and constantly working on one or another side project and/or open source. I have a blog at https://alex-rudenko.com
for something that is a single operation, actually
I would argue that one can view it as two operations: 1) getting an id for a new resource and 2) creation of the resource using PUT.
it is not very RESTful, since you are basically introducing state
The Request ID also introduces state because the second request with the same ID is rejected. Also, it changes the usual way POST requests work.
Then you have records you need to cleanup.
Indeed, you can clean them up later. It's easier than to cancel a duplicate payment though.
If sending a request ID is required for your use case, then you can use that field and be done with it, isn’t it so?
I would, and I would advocate for providing it, at least. Unfortunately, in practice, it's not always available because it's not a standard way of doing things. I would prefer to have a solution which eliminates duplication by design.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is true. I mention this in the post.
I would argue that one can view it as two operations: 1) getting an id for a new resource and 2) creation of the resource using PUT.
The Request ID also introduces state because the second request with the same ID is rejected. Also, it changes the usual way POST requests work.
Indeed, you can clean them up later. It's easier than to cancel a duplicate payment though.
I would, and I would advocate for providing it, at least. Unfortunately, in practice, it's not always available because it's not a standard way of doing things. I would prefer to have a solution which eliminates duplication by design.