4 ms·

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,

by 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...

by mnutt 11y ago

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...