4 ms·

> I would personally perhaps protest against the use of PUT for POSTing JSON, but nobody asked me. Just wondering, if the resource ID is known, I thought PUT i

> I would personally perhaps protest against the use of PUT for POSTing JSON, but nobody asked me. Just wondering, if the resource ID is known, I thought PUT is the recommended method? We usually use POST for creating a new resource for which you don't know an ID yet.

omnibrain 2y ago
I also wondered, did some research and look at some examples and came to the opposite conclusion for my API.
sublinear 2y 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 2y ago
  PUT can be used for Create too, if the user ID is generated by the client
  - ascar 2y ago
    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.
- rvnx 2y ago
  The protocol could be: CREATE /xxx READ /zzz UPDATE /yyy DELETE /abcd
  - bayindirh 2y ago
    Why not create an RFC and start the process? :)
  - dgan 2y ago
    Should have SET, because CREATE implies error if anything already exists, but SET would override it
  - maple3142 2y ago
    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
- andrewfromx 2y ago
  how can you leave out PATCH? POST - Create, GET - Retrieve, PUT - Upsert, DELETE - Delete, PATCH - Update
  - ascar 2y ago
    It's not part of RFC 9110, so why should it be included?
    - robertlagrant 2y ago
      Because this comment chain doesn't mention that RFC. That's in a different one.
      - ascar 2y ago
        Fair enough. I lost track of the correct comment chain there.
- janaagaard 2y ago
  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.
  - ascar 2y ago
    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."
hkwerf 2y ago
According to RFC 9110: - POST: Perform resource-specific processing on the request content. - PUT: Replace all current representations of the target resource with the request content. I interpret this as the only immediate side-effect of PUT is supposed to be replacing the target resource with the request content. Everything else is POST, but that does not mean that we can't use POST for everything. Thus, JSON via PUT is not inherently odd at all. Calling a random API using PUT with JSON arguments that executes some code other than replacing a resource, would be odd. I do think, though, that PUT may very well implicitly create a resource, if the name of that resource is the argument to the put. That is just something that's rather odd, as, often, the server has authority over the names of new resources. I find PUT particularly helpful, as, given these constraints, I assume that PUT is idempotent; POST is not.
- ffsm8 2y ago
  You should've added the patch specs too, for completions sake (it's to modify an object, not replace it - leaving unset attributes the same as before the operation)
- deleted 2y ago
  [deleted]
thaumasiotes 2y ago
> Just wondering, if the resource ID is known, I thought PUT is the recommended method? Recommended for what purpose? The set of recommendations I'm familiar with is: GET: requests without side effects POST: requests with side effects PUT: never use other: never use POST gets special treatment from browsers for various security risks. Otherwise, methods don't differ. You can use PUT as part of an effort to feel like you and your server have a secret code, but it's fundamentally the same thing as doing `GET /path/to/resource/put`.
- foota 2y ago
  I don't think this is quite accurate, browsers won't treat PUT requests as safe the same way it does a get request.
- eptcyka 2y ago
  PUT's can have request bodies, GETs can not.
  - thaumasiotes 2y ago
    Incorrect; GET requests are free to have bodies. See the note here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GE...
    - The_Colonel 2y ago
      It's still a rather bad idea. An older version of HTTP spec said that GET request body SHOULD be ignored. Proxies implementing that older version of spec could just drop the body ... You might also encounter problems with many tools not supporting it simply because the authors were not aware of it or perhaps considered it useless.
    - eptcyka 2y ago
      Also see the first row in the table on that page.
    - 2y ago
cco 2y ago
Loving the nerd sniping here haha. Join us at Stytch (https://stytch.com/careers https://stytch.com/careers) if you have a strong opinion so you can decide whether this should be a POST or PUT :)

omnibrain 2y ago

I also wondered, did some research and look at some examples and came to the opposite conclusion for my API.

sublinear 2y 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 2y ago
PUT can be used for Create too, if the user ID is generated by the client
- ascar 2y ago
  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.
rvnx 2y ago
The protocol could be: CREATE /xxx READ /zzz UPDATE /yyy DELETE /abcd
- bayindirh 2y ago
  Why not create an RFC and start the process? :)
- dgan 2y ago
  Should have SET, because CREATE implies error if anything already exists, but SET would override it
- maple3142 2y ago
  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
andrewfromx 2y ago
how can you leave out PATCH? POST - Create, GET - Retrieve, PUT - Upsert, DELETE - Delete, PATCH - Update
- ascar 2y ago
  It's not part of RFC 9110, so why should it be included?
  - robertlagrant 2y ago
    Because this comment chain doesn't mention that RFC. That's in a different one.
    - ascar 2y ago
      Fair enough. I lost track of the correct comment chain there.
janaagaard 2y ago
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.
- ascar 2y ago
  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."

hkwerf 2y ago

According to RFC 9110: - POST: Perform resource-specific processing on the request content. - PUT: Replace all current representations of the target resource with the request content. I interpret this as the only immediate side-effect of PUT is supposed to be replacing the target resource with the request content. Everything else is POST, but that does not mean that we can't use POST for everything. Thus, JSON via PUT is not inherently odd at all. Calling a random API using PUT with JSON arguments that executes some code other than replacing a resource, would be odd. I do think, though, that PUT may very well implicitly create a resource, if the name of that resource is the argument to the put. That is just something that's rather odd, as, often, the server has authority over the names of new resources. I find PUT particularly helpful, as, given these constraints, I assume that PUT is idempotent; POST is not.

ffsm8 2y ago
You should've added the patch specs too, for completions sake (it's to modify an object, not replace it - leaving unset attributes the same as before the operation)
deleted 2y ago
[deleted]

thaumasiotes 2y ago

> Just wondering, if the resource ID is known, I thought PUT is the recommended method? Recommended for what purpose? The set of recommendations I'm familiar with is: GET: requests without side effects POST: requests with side effects PUT: never use other: never use POST gets special treatment from browsers for various security risks. Otherwise, methods don't differ. You can use PUT as part of an effort to feel like you and your server have a secret code, but it's fundamentally the same thing as doing `GET /path/to/resource/put`.

foota 2y ago
I don't think this is quite accurate, browsers won't treat PUT requests as safe the same way it does a get request.
eptcyka 2y ago
PUT's can have request bodies, GETs can not.
- thaumasiotes 2y ago
  Incorrect; GET requests are free to have bodies. See the note here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GE...
  - The_Colonel 2y ago
    It's still a rather bad idea. An older version of HTTP spec said that GET request body SHOULD be ignored. Proxies implementing that older version of spec could just drop the body ... You might also encounter problems with many tools not supporting it simply because the authors were not aware of it or perhaps considered it useless.
  - eptcyka 2y ago
    Also see the first row in the table on that page.
  - 2y ago

cco 2y ago

Loving the nerd sniping here haha. Join us at Stytch (https://stytch.com/careers https://stytch.com/careers) if you have a strong opinion so you can decide whether this should be a POST or PUT :)