Page History

...

Note that the emphasis is on the URL rather than the HTTP method. The only reason POST must be used in two of the APIs is because GET normally cannot send payload content. The main point is that there are four different APIs (/GetUser, /CreateUser, /UpdateUser, and /DeleteUser) that have to be documented and supported by the client. REST APIs treat the server as a destination where resources are accessed. While the server may indeed be executing procedures, this is obscured from the URL itself, allowing the user to think about the resource as an item rather than an action. REST APIs rely upon the HTTP method (GET, POST, PUT, DELETE, etc.) to determine what should happen to that resource. Hence, through the use of these HTTP methods, a single URL can take on several meanings. This simplifies API design and the need for extensive documentation, as seen below:

...

With the RESTful approach, there is only one API, /Users, which is much easier to remember and document than four APIs. The HTTP methods are what define the behavior of the API. Since these methods are formally established in the HTTP protocol, they are not subject to redefinition, change, or republication with each set of RESTful APIs.

...

There is no established method for handling HATEOAS (or Hypermedia) responses. There are several formats which have been proposed, but a few have risen to notable prominence. One of them, known has HAL (Hypertext Access Language), is what is represented in the above response. This is why the Content-Type response header has a value of application/hal+json. To help API developers generate hypermedia responses (and thus make their APIs more REST compliant), the SRP HTTP Framework provides several application services (located in the HTTP_JSON_SERVICESServices function) to make it easier to build HAL+JSON formatted responses.

...