Page History

...

Application and database developers will recognize the above as the basic functions of CRUD. REST is far more than just an alternative way to implement CRUD, but it is a healthy start to understand how REST differs from RPC. One major takeaway is that REST uses four of the well defined HTTP methods to specify action (or intent) and only uses one URL to specify the resource. The {ID} used by some of the APIs technically means there are two URLs, but the resource itself, i.e., customers, is still represented by a singule single URL.

RPC methodologies tend to focus on just two HTTP methods, GET and POST, and rely upon the URL or a payload body to specify the action. Here is a very simple RPC example:

...

We will observe that each CRUD action uses a different URL. SOAP will differ differs from standard RPC in that the URL will tend to be singular but the entire action will be described in the payload.

HTTP provides a way of managing metadata through the use of request headers and response headers. Effective use of headers avoids the need to build proprietary messaging within the payload or with URL through query params. A good example of this is the Accept request header. Clients should use the Accept header to indicate their preferred data format (aka media type). Servers should look for the value specified in the Accept header and return the resource in this format if it is able.

HTTP also provides a set of response status codes that inform the client of how the request was handled. For example: 200 means OK, 201 means the new resource was created, 404 means the URL indicates a non-existing resource, 405 means the HTTP method is not supported, etc. Servers should send back the most appropriate status code and clients should attempt to handle any valid status code appropriately.

The most significant, albeit the most misunderstood and underutilized, aspect of the Uniform Interface, is Hypermedia As The Engine Of Application State (HATEOAS). We have a dedicated page to the question, "What is HATEOAS?", but we'll provide a simple explanation here. HATEOAS is a design feature where information about the state of a resource should be provided to the client through hyperlinks (aka hypermedia). This avoids the need for maintaining state and it avoids the need for the client to assume or hardcode how to request a state change to the server. Applying HATEOAS to API responses adds a fair amount of extra work and careful design. This often leads to what many developers refer to as practical REST which is contrasted with purist REST. Regardless of the internal debating that continues to go on with this subject, Dr. Fielding himself has written, "...if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API" (emphasis added).

We believe HATEOAS is a very important part of a well designed RESTful API. Therefore, the SRP HTTP Framework is designed to make this easy to implement.REST asserts that the advantage of usin