0

In REST full API has some method name like (GET, PUT, POST etc.) for some specific operation (CRUD) But I can perform any operation using any of the methods

Example for DB operations:

  1. I can create or insert a new document or delete or update using GET method.

  2. I can post or update or delete using POST method.

  3. I can delete or update or delete using PUT method.

    the same way I can use any of this method to perform DB (CRUD) operation

So, Why need this method to specify when we call any rest full API?

Anupam
  • 201
  • 2
  • 4
  • 11
  • It's unclear what you're asking. – Oliver Charlesworth Jun 04 '17 at 16:21
  • If you can do that, it clearly means that the server is done very poorly. In REST every method, even sent to the same URL, should trigger different action on the server – Nhor Jun 04 '17 at 16:22
  • Read here https://stackoverflow.com/questions/107390/whats-the-difference-between-a-post-and-a-put-http-request , its wery deep question, based on understanding whats going on when you make a request – Nikita Goncharov Jun 04 '17 at 16:23
  • @Nhor can you explain to me why and how? It will be very helpful for me – Anupam Jun 04 '17 at 16:38
  • A bit confused why this is being downvoted. It sounds like an honest question to me, and it has a great answer. – Evert Jun 04 '17 at 21:20

2 Answers2

5

It's a convention based on HTTP standard. REST is built on top of convention over configuration paradigm. That is, a set of conventions avoid a lot of boilerplate and configuration.

For example, HTTP 1.1 standard says:

  • GET: The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process

  • POST: The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line [...].

...and so on.

Matías Fidemraizer
  • 63,804
  • 18
  • 124
  • 206
0

To expand on Matías's answer, you have to think about the consequences of allowing consumers to call your API using any verb they wanted.

Firstly, your implementation is going to be more complex if you never know what operation is going to be expected. For example, if someone can update a resource using GET, how do you tell the difference between a query and an update? The answer: extra (needless) complexity of the implementation.

Secondly, there are consequences from the point-of-view of performance and scalability. GET allows easy caching of resource representations because of its idempotent nature - which is the expected convention. By not making it clear which verbs do what, you're making it harder to utilise strategies such as caching, which makes your API harder to scale.

Thirdly, it makes things more complicated for consumers. HTTP's convention-based approach is widely understood. Working with an API that doesn't follow that convention - especially one that labels itself as using HTTP/REST - is going to increase integration costs.

John H
  • 14,422
  • 4
  • 41
  • 74