A similar scenario: http connection is interrupted (timeout? API service restart? etc) but the resource is created by the service on the far end of the internal RPC bus. The client has no resource identifier to issue a GET to determine if it was successful or not, so they will re-issue POST and generate a duplicate resource -- or worse, if the resource contains a natural primary key, they'll unexpectedly get a duplicate error and have to search for the resource to find its identifier.
If clients were required to generate the resource identifier when creating a resource, this would not be a problem.
A similar scenario: http connection is interrupted (timeout? API service restart? etc) but the resource is created by the service on the far end of the internal RPC bus. The client has no resource identifier to issue a GET to determine if it was successful or not, so they will re-issue POST and generate a duplicate resource -- or worse, if the resource contains a natural primary key, they'll unexpectedly get a duplicate error and have to search for the resource to find its identifier.
If clients were required to generate the resource identifier when creating a resource, this would not be a problem.