Page History
| Table of Contents |
|---|
Quick Answer
REST is a way of producing and consuming web APIs. It tends to be simpler and easier to work with than other API methodologies (such as SOAP). It seeks improved scalability, performance, and client-server independence.
Digging Deeper
REST is an acronym for Representational State Transfer. This Wikipedia article offers a good primer on the subject but for those who want to go right to the source material, read Chapter 5 of Dr. Roy Fielding's dissertation. There are numerous web articles and vlogs and the web that discuss various REST topics. This article will focus on what REST means to the SRP HTTP Framework.
At a high-level, REST is simply a way of producing and consuming web APIs. In this regard, it is no different from other web API methodologies (generally known as RPC or remote procedure call) such as SOAP or XML-RPC. They all communicate with web servers using URLs and HTTP. Contrary to conventional thinking, REST is not a standard . Rather, but it does point to other standards (e.g., HTTP). REST attempts to describe a philosophy of building web APIs using six different constraints:
...
An important aspect of the Uniform Interface constraint is described as Hypermedia As The Engine Of Application State, or HATEOAS. We have a dedicated page to the question, "What is HATEOAS?"discuss the nature and value of HATEOAS in our Why is HATEOAS important? article, but we'll provide a simple explanation of it 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 state change requests are made. Incorporating HATEOAS to the design of web APIs requires a fair amount of extra work and planning. This often drives many developers to opt out of HATEOAS. This is often referred to as practical pragmatic REST whereas purist REST includes and advocates for HATEOAS. Regardless of the ongoing internal debates, Dr. Fielding himself has expressed his feelings rather clearly, "...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).
...
