4 ms·

> PUT, PATCH and DELETE Is this really that much better than POST http://www.mysite.com/thing/100/delete http://www.mysite.com/thing/100/delete ? GET and POST

> PUT, PATCH and DELETE Is this really that much better than POST http://www.mysite.com/thing/100/delete http://www.mysite.com/thing/100/delete ? GET and POST have actual client-side implementation differences. The rest is simply semantics. I love REST but these extra verbs seem redundant.

recursivedoubts 4y ago
If you are treating URLs as references to resources, you want the ability to CRUD those resources. PUT and DELETE correspond with U and D, so they make sense to include. PATCH is a little less obviously useful (partial update vs. a full update w/ a PUT.) Regardless of our feelings about them, they are there in HTTP, the HyperText Transfer Protocol. So maybe we should make them accessible through the HyperText we are transferring.
- pdntspa 4y ago
  I really doubt the world is going to standardize over that specific style of implementation and, frankly, the semantic web is dead. Long live the bazaar...
  - dmitriid 4y ago
    Those are literally standards. With very specific semantics and expectations https://github.com/for-GET/know-your-http-well/blob/master/methods.md https://github.com/for-GET/know-your-http-well/blob/master/m...
    - pdntspa 4y ago
      And the number of projects that I have seen follow them is fewer than the number of projects that just seem to wing it. Which is my point... perhaps this standard is superficial and unnecessary, and maybe we should discard it. IETF/whoever can write whatever they want, I only care about what I actually encounter. That's "standardization" edit- All those nice looking checkboxes depend on the individual implementation. It's a nice concept but how many projects have actually implemented it to the conventions about idempotency/etc shown? edit2- who is for-GET anyway? A random github link doesn't have much more worth than a random Medium link
- rmedaer 4y ago
  I promised myself to never-ever answer the "CRUD vs HTTP verbs" topic. I could not resist. It is a huge shortcut to map CRUD operations to HTTP verbs POST, GET, PUT, DELETE. By the way, the definition of HTTP verbs defined in the HTTP RFCs (from RFC 1945 to RFC 7231) and the original thesis from Roy Fielding about REST (which is defining REST principles as an architectural style) never talk about one-to-one relationship between CRUD and PUT-GET-POST-DELETE. While I understand that it might be confusing without deep-diving in long-long-lectures, the last RFC explains clearly what is the purpose of each HTTP verb including the difference between PUT and POST: 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. Therefore it would be perfectly valid to "create" a resource with both PUT and POST methods as well as "update" another one with, also, PUT and POST. It is actually even clearly stated with a few examples in the RFC. For instance in POST definition: Appending data to a resource's existing representation(s). I used to defined PUT and POST requests according their characteristics: the first one is idempotent, the second is not ... but could be. Therefore, in my understanding, it is perfectly valid to perform an "upsert" (insert or update) to a resource which doesn't exist yet but for which you already know the URL, it is indeed idempotent. For instance: PUT /resources/xyz A last piece of evidence is the first line of PUT section in 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. I hope it helps to clarify a little bit the topic.
  - turtleyacht 4y ago
    Do you have any references to documented, truly REST APIs? In your experience, what (pragmatic) shortcuts were needed to veer from (some definition of) "pure" REST?
    - rmedaer 4y ago
schappim 4y ago
>> I love REST but these extra verbs seem redundant. The extra verbs make your URLs less redundant!

recursivedoubts 4y ago

If you are treating URLs as references to resources, you want the ability to CRUD those resources. PUT and DELETE correspond with U and D, so they make sense to include. PATCH is a little less obviously useful (partial update vs. a full update w/ a PUT.) Regardless of our feelings about them, they are there in HTTP, the HyperText Transfer Protocol. So maybe we should make them accessible through the HyperText we are transferring.

pdntspa 4y ago
I really doubt the world is going to standardize over that specific style of implementation and, frankly, the semantic web is dead. Long live the bazaar...
- dmitriid 4y ago
  Those are literally standards. With very specific semantics and expectations https://github.com/for-GET/know-your-http-well/blob/master/methods.md https://github.com/for-GET/know-your-http-well/blob/master/m...
  - pdntspa 4y ago
    And the number of projects that I have seen follow them is fewer than the number of projects that just seem to wing it. Which is my point... perhaps this standard is superficial and unnecessary, and maybe we should discard it. IETF/whoever can write whatever they want, I only care about what I actually encounter. That's "standardization" edit- All those nice looking checkboxes depend on the individual implementation. It's a nice concept but how many projects have actually implemented it to the conventions about idempotency/etc shown? edit2- who is for-GET anyway? A random github link doesn't have much more worth than a random Medium link
rmedaer 4y ago
I promised myself to never-ever answer the "CRUD vs HTTP verbs" topic. I could not resist. It is a huge shortcut to map CRUD operations to HTTP verbs POST, GET, PUT, DELETE. By the way, the definition of HTTP verbs defined in the HTTP RFCs (from RFC 1945 to RFC 7231) and the original thesis from Roy Fielding about REST (which is defining REST principles as an architectural style) never talk about one-to-one relationship between CRUD and PUT-GET-POST-DELETE. While I understand that it might be confusing without deep-diving in long-long-lectures, the last RFC explains clearly what is the purpose of each HTTP verb including the difference between PUT and POST: 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. Therefore it would be perfectly valid to "create" a resource with both PUT and POST methods as well as "update" another one with, also, PUT and POST. It is actually even clearly stated with a few examples in the RFC. For instance in POST definition: Appending data to a resource's existing representation(s). I used to defined PUT and POST requests according their characteristics: the first one is idempotent, the second is not ... but could be. Therefore, in my understanding, it is perfectly valid to perform an "upsert" (insert or update) to a resource which doesn't exist yet but for which you already know the URL, it is indeed idempotent. For instance: PUT /resources/xyz A last piece of evidence is the first line of PUT section in 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. I hope it helps to clarify a little bit the topic.
- turtleyacht 4y ago
  Do you have any references to documented, truly REST APIs? In your experience, what (pragmatic) shortcuts were needed to veer from (some definition of) "pure" REST?
  - rmedaer 4y ago

schappim 4y ago

>> I love REST but these extra verbs seem redundant. The extra verbs make your URLs less redundant!