5 ms·
Auth requests are for a new session ID, not a new user ID. It's a (C)reate in CRUD, not an (U)pdate. POST - Create, GET - Retrieve, PUT - Update, DELETE - Del
by sublinear 3y ago
Auth requests are for a new session ID, not a new user ID.
It's a (C)reate in CRUD, not an (U)pdate.
POST - Create,
GET - Retrieve,
PUT - Update,
DELETE - Delete
- plextoria 3y agoPUT can be used for Create too, if the user ID is generated by the client
- ascar 3y agoAccording 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.
- rvnx 3y agoThe protocol could be: CREATE /xxx READ /zzz UPDATE /yyy DELETE /abcd
- bayindirh 3y agoWhy not create an RFC and start the process? :)
- dgan 3y agoShould have SET, because CREATE implies error if anything already exists, but SET would override it
- maple3142 3y agoIsn'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
- andrewfromx 3y agohow can you leave out PATCH? POST - Create, GET - Retrieve, PUT - Upsert, DELETE - Delete, PATCH - Update
- ascar 3y agoIt's not part of RFC 9110, so why should it be included?
- robertlagrant 3y agoBecause this comment chain doesn't mention that RFC. That's in a different one.
- ascar 3y agoFair enough. I lost track of the correct comment chain there.
- janaagaard 3y agoThe 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.
- ascar 3y agoAren'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."