The difference between PUT and POST is weather the command is idempotent or not.
Some APIs us PUT for creating items and let the clients specify the ID. If the IDs are UUIDs, the risk of creating duplicates is so slim that it's neglectable, and if that should happen, it's easy for the client to call again with a different ID. The real advantage of this approach is that if the API call times out, the client can just PUT again without having to fear creating a duplicate record. Recovering from a create with POST that has timed out can be pretty difficult because it can happen that the record was created just fine, but the internet connection died before the OK response reached the client.
Aren't you basically describing that you want idempotency?
The RFC 9110 (and also the old 2616) clearly state PUT is idempotent while POST isn't.
9.3.4 PUT
"The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server."
9.2.2 Idempotent Methods
"Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ."
According to the RFC's PUT can be used to create a resource as long as the request has a clear target. That doesn't necessarily mean an ID, but just some kind of identifier (composite key, hash of content, url, etc.). When a create instead of update happens the server should respond with a 201 CREATED, which should indicate the location or identifier of the created resource.
Isn't it already supported by REST?
CREATE: POST
READ: GET (or QUERY if body is needed)
UPDATE: PUT for full update, PATCH for partial update
DELETE: DELETE
It's a (C)reate in CRUD, not an (U)pdate.
POST - Create, GET - Retrieve, PUT - Update, DELETE - Delete