5 ms·

Can anyone explain why using different verbs (PUT, PATCH, ...) is preferable to using just POST with an additional parameter (e.g. POST action="add")? It seems

by tomp 11y ago

Can anyone explain why using different verbs (PUT, PATCH, ...) is preferable to using just POST with an additional parameter (e.g. POST action="add")? It seems like the author's distinction between POST, PUT and PATCH seems rather arbitrary...

creshal 11y ago
You can use the same end point for all possible actions on an object, instead of having to define different ones, and it standardizes which actions are available where. (Otherwise, is it /wombat/1/edit or /wombat/edit/1/ or /wombat/1/?action=edit or …) There's no disadvantages to using HTTP verbs over anything else. > It seems like the author's distinction between POST, PUT and PATCH seems rather arbitrary... PATCH is… awkward, and probably should be ignored. POST always creates a new resource, under an URL picked by the server. PUT creates or updates a resource under an URL picked by the client.
snarfy 11y ago
POST action="add" is not RESTful. It's procedural. It doesn't take advantage of all the http caching mechanisms that come into play with the web that you get for free with a resource based design. You should PUT the resource.
- tomp 11y ago
  > POST action="add" is not RESTful. It's procedural. Can you expand on what you mean by this? In particular, how could HTTP catching mechanism work with POST requests, if the purpose of POST is to change something on the server (so the request should always reach the server)? And in what way is PUT handled differently (by browsers, by proxies, by servers)?
  - mnutt 11y ago
    It's just conventional. If a PUT fails, you (and others) know you can safely retry it multiple times without having to worry about it having any other effects, like duplicate rows. The concept is called idempotence.
    - tomp 11y ago
      Oh, so basically `PUT` is just like a `POST action="add" id="XYZ"`? In any case, that only works if the ID can be known in advance (which e.g. isn't possible if you want sequential IDs).
      - keithb- 11y ago
        No, POST is create and PUT is update[1]. In the RESTful world, PUT uses a specific URL for that entity, e.g. PUT /contacts/rich-hickey: there is only one Rich Hickey and I'm going to update his contact info with the body of the request. Check out the Decision Flow Diagram, it is really awesome[2]. There is probably no single reason why you should never use POST when you need PUT or DELETE. This is mostly an implementation choice, but if you are using a Repository or DAO pattern on the server side, it might be easier to understand if all of the semantics align nicely, e.g. HTTP<POST> -> OOP<Add> -> SQL<CREATE>, HTTP<PUT> -> OOP<Update> -> SQL<UPDATE>. IMHO using a parameter for method name is a call-by-name strategy that, in this case, is a level of abstraction that just isn't necessary. In other words, there is really nothing dynamic about the behavior. When the application state hits the client side, the flow of control is dictated by earlier events or actions. Your application isn't likely to make decisions on the fly about whether the current flow is concerned with creating an entity versus deleting an entity. For example, the user and the application state "know" already what is valid for an entity and it is likely that your application is reflecting that in a hard-coded "action=[add|update|delete]" parameter. Why funnel this state through a single method with a switch-statement on the server side? Incidentally, there are some references to caching the results of a POST request[3] but I can't think of an production example that I've run across. It might be cacheable if the response is a redirect to the same "list of entities" URL rather than a direct URL to the newly created entity which is arguably more RESTful but not cacheable. [1] http://restcookbook.com/HTTP%20Methods/put-vs-post/ http://restcookbook.com/HTTP%20Methods/put-vs-post/ [2] https://webmachine.github.io/images/http-headers-status-v3.png https://webmachine.github.io/images/http-headers-status-v3.p... [3] http://programmers.stackexchange.com/questions/114156/why-are-there-are-no-put-and-delete-methods-on-html-forms http://programmers.stackexchange.com/questions/114156/why-ar...
lhorie 11y ago
It's not that they are preferable, it's just that these verbs were invented for a reason, and people often ignore that because they didn't RTFM. POST can be thought of as pasting a file into a folder from your clipboard, without necessarily knowing what its filename is. It oughta tell you the filename after you paste so you can retrieve it later. Typically, in a REST setting, you'd POST a thing to a collection (e.g. POST /api/v1/things) PUT can be thought of as piping stuff to a file, when you know the filename ahead of time. It completely overwrites any existing data in that file. You'd PUT to the path where the resource should exist (e.g. PUT /api/v1/things/1) PATCH can be thought of a version control diff. It's actually really powerful, but unfortunately, there's no widespread format to express diffs of deep structural data often seen in REST APIs, so most people avoid it. A PATCH request should contain instructions on how to add and remove sub-fields from a resource. It can be used on collections to batch-add/remove items, and it can be used in single resources to modify them without overwriting other existing fields (or even do all of those with a single request)

by tomp 11y ago

creshal 11y ago

You can use the same end point for all possible actions on an object, instead of having to define different ones, and it standardizes which actions are available where. (Otherwise, is it /wombat/1/edit or /wombat/edit/1/ or /wombat/1/?action=edit or …) There's no disadvantages to using HTTP verbs over anything else. > It seems like the author's distinction between POST, PUT and PATCH seems rather arbitrary... PATCH is… awkward, and probably should be ignored. POST always creates a new resource, under an URL picked by the server. PUT creates or updates a resource under an URL picked by the client.

snarfy 11y ago

POST action="add" is not RESTful. It's procedural. It doesn't take advantage of all the http caching mechanisms that come into play with the web that you get for free with a resource based design. You should PUT the resource.

tomp 11y ago
> POST action="add" is not RESTful. It's procedural. Can you expand on what you mean by this? In particular, how could HTTP catching mechanism work with POST requests, if the purpose of POST is to change something on the server (so the request should always reach the server)? And in what way is PUT handled differently (by browsers, by proxies, by servers)?
- mnutt 11y ago
  It's just conventional. If a PUT fails, you (and others) know you can safely retry it multiple times without having to worry about it having any other effects, like duplicate rows. The concept is called idempotence.
  - tomp 11y ago
    Oh, so basically `PUT` is just like a `POST action="add" id="XYZ"`? In any case, that only works if the ID can be known in advance (which e.g. isn't possible if you want sequential IDs).
    - keithb- 11y ago
      No, POST is create and PUT is update[1]. In the RESTful world, PUT uses a specific URL for that entity, e.g. PUT /contacts/rich-hickey: there is only one Rich Hickey and I'm going to update his contact info with the body of the request. Check out the Decision Flow Diagram, it is really awesome[2]. There is probably no single reason why you should never use POST when you need PUT or DELETE. This is mostly an implementation choice, but if you are using a Repository or DAO pattern on the server side, it might be easier to understand if all of the semantics align nicely, e.g. HTTP<POST> -> OOP<Add> -> SQL<CREATE>, HTTP<PUT> -> OOP<Update> -> SQL<UPDATE>. IMHO using a parameter for method name is a call-by-name strategy that, in this case, is a level of abstraction that just isn't necessary. In other words, there is really nothing dynamic about the behavior. When the application state hits the client side, the flow of control is dictated by earlier events or actions. Your application isn't likely to make decisions on the fly about whether the current flow is concerned with creating an entity versus deleting an entity. For example, the user and the application state "know" already what is valid for an entity and it is likely that your application is reflecting that in a hard-coded "action=[add|update|delete]" parameter. Why funnel this state through a single method with a switch-statement on the server side? Incidentally, there are some references to caching the results of a POST request[3] but I can't think of an production example that I've run across. It might be cacheable if the response is a redirect to the same "list of entities" URL rather than a direct URL to the newly created entity which is arguably more RESTful but not cacheable. [1] http://restcookbook.com/HTTP%20Methods/put-vs-post/ http://restcookbook.com/HTTP%20Methods/put-vs-post/ [2] https://webmachine.github.io/images/http-headers-status-v3.png https://webmachine.github.io/images/http-headers-status-v3.p... [3] http://programmers.stackexchange.com/questions/114156/why-are-there-are-no-put-and-delete-methods-on-html-forms http://programmers.stackexchange.com/questions/114156/why-ar...

lhorie 11y ago

It's not that they are preferable, it's just that these verbs were invented for a reason, and people often ignore that because they didn't RTFM. POST can be thought of as pasting a file into a folder from your clipboard, without necessarily knowing what its filename is. It oughta tell you the filename after you paste so you can retrieve it later. Typically, in a REST setting, you'd POST a thing to a collection (e.g. POST /api/v1/things) PUT can be thought of as piping stuff to a file, when you know the filename ahead of time. It completely overwrites any existing data in that file. You'd PUT to the path where the resource should exist (e.g. PUT /api/v1/things/1) PATCH can be thought of a version control diff. It's actually really powerful, but unfortunately, there's no widespread format to express diffs of deep structural data often seen in REST APIs, so most people avoid it. A PATCH request should contain instructions on how to add and remove sub-fields from a resource. It can be used on collections to batch-add/remove items, and it can be used in single resources to modify them without overwriting other existing fields (or even do all of those with a single request)