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.
The API developer is encouraged to study REST principles and practical examples beyond this rather brief introduction. There are many good online resources. Among these, there is a split between advocates for a more practical approach to REST and there are those who are advocates for advocate a more principled approach to REST (these are often referred to as REST purists, or RESTafarians). For those who desire to achieve fully RESTful APIs, The Richardson Maturity Model article provides a nice stepping-stone approach. Thus, it begins with some practical examples that will be easy to adopt, while providing a pathway toward full REST implementation.
It should be noted that while the SRP HTTP Framework is designed around the REST API model, it does not enforce it. Indeed, it can nicely work with any API methodology and replace the standard RUN_OECGI_REQUEST (i.e., INET) utility, although some additional work would need to be done to replace pre-built INET routines. Note, while the SRP HTTP Framework can support INET style applications, RUN_OECGI_REQUEST cannot support REST APIs. The primary reason is that RUN_OECGI_REQUEST intentionally obscures the URL in favor of the INET routine that is named in the end point. Hence, there is no easy way to glean semantics out of the rest of the URL, which makes RESTful approaches useless.Whether or not implementing a comprehensive REST API is intended, developers are strongly encouraged to consider some type of REST design in their web applications for two reasons: 1.) REST is arguably a formalized explanation of the way the internet (via HTTP) is meant to be used. It lays out the principles by which the internet has become so robust, scalable, and accessible. 2.) While REST has been documented for quite some time, there seems to be a significant resurgence of interest in this architecture from small and large online service providers. This is hugely beneficial to the OpenInsight developer because it taps into a reputable and credible methodology that obscures the underlying technology (i.e., Basic+, Linear Hash) that is often a barrier to mainstream acceptancethus rendering RESTful approaches useless.
