Confused about the verbs Http

Question

I am confused when and why you should use certain verbs in REST?

I know such basic things as:

Get -> for retrieval Post -> adding new entity PUT -> updating Delete -> for deleting 

These attributes should be used in accordance with the operation described above, but I do not understand why? What happens if I add a new object inside the Get method in REST, or inside the POST I update the object? or maybe inside DELETE. I am adding an object. I know this may be a question about the noob, but I need to understand this. This sounds very confusing to me.

Answer 1

@archil has an excellent explanation in the traps of verb abuse, but I would point out that the rules are not as stringent as what you described (at least with respect to the protocol).

• GET MUST be safe. This means that a GET request should not change the server state in any significant way. (The server may do some extra work, such as query logging, but will not update any data.)
• PUT and DELETE MUST be idempotent. This means that multiple calls to the same URI will have the same effect as a single call. For example, if you want to change the person’s name from “Jon” to “Jack”, and you do this with a PUT request, this is normal, because you can do it once or 100 times, and the person’s name will still be updated to “Jack” "
• POST makes no guarantees regarding security or idempotency. This means that you can technically do whatever you want with a POST request. However, you will lose any advantage that customers of these assumptions can take. For example, you can use POST to perform a search that is semantically more a GET request. There will be no problems, but browsers (or proxies or other agents) will never cache the results of this search, because they cannot assume that nothing has changed as a result of the request. In addition, web crawlers will never execute a POST request because he could not assume that the operation is safe.

The entire HTML version of the World Wide Web combines well without PUT or DELETE, and does a great job of deleting or updating with POST, but if you can support PUT and DELETE for updates and deletions (and other idempotent operations) this is a little better because agents can assume that the operation is idempotent.

See the official W3C documentation for real security and idempotency work.

Answer 2

Protocol protocol

- protocol. It is intended to define each rule associated with it. Http is a protocol too. All of the above rules (including the rules of http-verbs) are defined by the http protocol, and use is determined by the http protocol. If you do not follow these rules, you will understand what is happening inside your service. It will not follow protocol rules and will be confusing for other users. There was an example, once, about a famous photo site (no matter which one) that deleted photos with a GET request. After the user of this site has installed the search program on the Google desktop, this allows you to archive pages locally. Since this program knew that GET operations were only used to retrieve data and should not affect anything, they made GET requests to every available URL (including these GET-delete URLs). When the user logged in and the cookie was in the browser, there were no problems with authorization. And the result is that all user photos were deleted on the server due to the incorrect use of the HTTP protocol and GET verb. That is why you should always follow the rules of the protocol that you use. Although it is technically possible, it is incorrect to redefine certain rules.

Answer 3

Using GET to delete a resource will be similar to a function with a name and documented to add something to an array that removes something from the array under the hood. REST has only a few well-defined methods (HTTP verbs). Your service users expect your service to adhere to this definition, otherwise it is not a RESTful web service.

Answer 4

If you do this, you cannot claim that your interface is RESTful. The REST principle provides that these verbs perform the actions you mention. If they do not, then it cannot be called a RESTful interface.