4 ms·

> POST - Asks the server to create a new resource > PUT - Asks the server to edit/update an existing resource Maybe I've been doing it wrong all these years b

by sibit 3y ago

> POST - Asks the server to create a new resource > PUT - Asks the server to edit/update an existing resource Maybe I've been doing it wrong all these years but it seems to me that the guides flip-flops the responsibility of POST and PUT. My understanding is that POST should edit/modify while PUT creates/replaces a resource.

hairofadog 3y ago
I’ve always known it as stated in the article, and I’m pretty sure that’s right, though I’ve never noticed any functional difference between the two (aside from what any given API may enforce).
nighthawk454 3y ago
I thought the same, but apparently the article is correct https://www.ietf.org/rfc/rfc2616.txt https://www.ietf.org/rfc/rfc2616.txt
- sibit 3y ago
  Interesting. I guess I've been going off of RFC 7231 > The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload. https://www.ietf.org/rfc/rfc7231.txt https://www.ietf.org/rfc/rfc7231.txt
  - blowski 3y ago
    My rule of thumb: if you know the ID of the resource you’re creating, it’s a PUT. If the system generates the ID, then it’s a POST.
    - treve 3y ago
      More generally the URI instead of the ID.
      - SgtBastard 3y ago
        The I in URI, stands for Identifier...
brosciencecode 3y ago
Are you mistaking POST for PATCH? What I've been working with is: - POST creates - PUT replaces (i.e. edit, but you need to provide the whole resource) - PATCH edits (i.e. you can only provide some fields) APIs rarely implement all these properly in practice but that's my understanding of the theory.
- cryptonector 3y ago
  POST is a kitchen sink. It can do anything. If it creates it must return a 201 with the new resource's location, otherwise if it succeeds but does not create a new resource (just modifies one) then it must return 200.
- puika 3y ago
  This is indeed the standard, AFAIK. Not sure what resources mention otherwise but it seems like a lot, judging by the comments around
- richardwhiuk 3y ago
  PUT can create - depending on whether the resource name is client or server determined.
- wak90 3y ago
  I remember getting an interview question wrong when I said "yeah a get is supposed to just respond with data but you're writing it, you can make it do whatever you want"
  - charrondev 3y ago
    I mean most GET requests have at least one side effect: one or more cache writes. I’ve also implemented some GET endpoints that are a GET but have a side effect of marking something as read. (Normally as a variant to an existing endpoint for sessioned user). I would expect at a minimum though if you are doing writes during a GET it should be idempotent.
    - 3y ago
capableweb 3y ago
> My understanding is that POST should edit/modify while PUT creates/replaces a resource The way I've been segmented them is based on idempotency. If you repeat the same call multiple times, do you get the same result as if you just ran it once? Then PUT is appropriate. But if you have side-effects like creating new resources, that would result in different action each time you make the call, then POST it is. Idempotent methods include GET, HEAD, PUT and DELETE, the resource should always end up in the same state after calling them N times (barring errors/exceptions and such of course). I'm fairly I got this from when I initially read the specification, it's probably mentioned with a bit more grace in the HTTP/1.1 spec.
jstx1 3y ago
And also what if you have a huge nested query which is only reading the database but is difficult to pack into URL parmeters (too long for example and you hit a character limit)? POST with a json body instead of GET even though it's against RESTful principles?
- robertlagrant 3y ago
  This is one acceptable workaround. Generally having caching at this point is unnecessary, and it's probably a good idea or developers to pay special attention if doing this. If you have a longer-running query you could alternatively construct a Query resource of some sort and then GET it until it's ready.
samwillis 3y ago
Somewhat agreed, I see them as: PUT - is effectively an "upsert" at a specific url. Doesn't exist? Create it, does exist? replace it. PATCH - update a resource with a diff, at a specific url. POST - this is a RPC, in the case of a REST API it can be used to create a new resource where the "id" is not provided and set by the server, it then redirects to the new url. POST can be used for any RPC endpoints, even as part of a REST api.

by sibit 3y ago

hairofadog 3y ago

I’ve always known it as stated in the article, and I’m pretty sure that’s right, though I’ve never noticed any functional difference between the two (aside from what any given API may enforce).

nighthawk454 3y ago

I thought the same, but apparently the article is correct https://www.ietf.org/rfc/rfc2616.txt https://www.ietf.org/rfc/rfc2616.txt

sibit 3y ago
Interesting. I guess I've been going off of RFC 7231 > The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload. https://www.ietf.org/rfc/rfc7231.txt https://www.ietf.org/rfc/rfc7231.txt
- blowski 3y ago
  My rule of thumb: if you know the ID of the resource you’re creating, it’s a PUT. If the system generates the ID, then it’s a POST.
  - treve 3y ago
    More generally the URI instead of the ID.
    - SgtBastard 3y ago
      The I in URI, stands for Identifier...

brosciencecode 3y ago

Are you mistaking POST for PATCH? What I've been working with is: - POST creates - PUT replaces (i.e. edit, but you need to provide the whole resource) - PATCH edits (i.e. you can only provide some fields) APIs rarely implement all these properly in practice but that's my understanding of the theory.

cryptonector 3y ago
POST is a kitchen sink. It can do anything. If it creates it must return a 201 with the new resource's location, otherwise if it succeeds but does not create a new resource (just modifies one) then it must return 200.
puika 3y ago
This is indeed the standard, AFAIK. Not sure what resources mention otherwise but it seems like a lot, judging by the comments around
richardwhiuk 3y ago
PUT can create - depending on whether the resource name is client or server determined.
wak90 3y ago
I remember getting an interview question wrong when I said "yeah a get is supposed to just respond with data but you're writing it, you can make it do whatever you want"
- charrondev 3y ago
  I mean most GET requests have at least one side effect: one or more cache writes. I’ve also implemented some GET endpoints that are a GET but have a side effect of marking something as read. (Normally as a variant to an existing endpoint for sessioned user). I would expect at a minimum though if you are doing writes during a GET it should be idempotent.
  - 3y ago

capableweb 3y ago

> My understanding is that POST should edit/modify while PUT creates/replaces a resource The way I've been segmented them is based on idempotency. If you repeat the same call multiple times, do you get the same result as if you just ran it once? Then PUT is appropriate. But if you have side-effects like creating new resources, that would result in different action each time you make the call, then POST it is. Idempotent methods include GET, HEAD, PUT and DELETE, the resource should always end up in the same state after calling them N times (barring errors/exceptions and such of course). I'm fairly I got this from when I initially read the specification, it's probably mentioned with a bit more grace in the HTTP/1.1 spec.

jstx1 3y ago

And also what if you have a huge nested query which is only reading the database but is difficult to pack into URL parmeters (too long for example and you hit a character limit)? POST with a json body instead of GET even though it's against RESTful principles?

robertlagrant 3y ago
This is one acceptable workaround. Generally having caching at this point is unnecessary, and it's probably a good idea or developers to pay special attention if doing this. If you have a longer-running query you could alternatively construct a Query resource of some sort and then GET it until it's ready.

samwillis 3y ago

Somewhat agreed, I see them as: PUT - is effectively an "upsert" at a specific url. Doesn't exist? Create it, does exist? replace it. PATCH - update a resource with a diff, at a specific url. POST - this is a RPC, in the case of a REST API it can be used to create a new resource where the "id" is not provided and set by the server, it then redirects to the new url. POST can be used for any RPC endpoints, even as part of a REST api.