Created 02/27/2018 at 2018:10AM
In the beginning, APIs were a little difficult to transition to the web. This was due to the fact that APIs were developed around a remote procedure call (RPC). The API looked and felt like a locally executed function because HTTP is, inherently, connection-less and required developers to think a little differently.
The genesis of REST, or REpresentational State Transfer lies in a 2000 doctoral thesis by Roy Fielding, a computer scientist and one of the principal authors of the HTTP specification. It's real geek reading and I'll try to distill it a bit.
In a nutshell, REST-compliant web services allow requesting systems to access and manipulate textual representations of web resources by using a uniform and predefined set of stateless operators. Other services such as WSDL and SOAP, expose their own arbitrary set of operations.
Requests are composed of a verb, headers that describe the message and a body. The request describes what you want the server to accomplish. The response consists of three constituents, a status code (200 is what you want), headers describing the response and the body.
HTTP verbs consists primarily of ...
GET - Retrieve a resource
POST - Create a resource
PUT - Update a resource
DELETE - Delete a resource
PATCH - Partially update a resource
You will also hear this referred to as CRUD - Create, Read, Update and Delete.
Without question the most popular operation is "GET". The main point of a web page is to request and aggregate different resources that compose a web page. In RESTful interfaces, we use these verbs to describe what we need.
REST works and is desirable for a few reasons.... The wide range of devices that now connect to the internet e.g. browsers, mobile phones, an iOS app or an IoT device, all require access to a common standard to operate. You can also create an infrastructure where you aren't so concerned about the client-side stack. The server outlives the client.
Caching is another key issue and it is stateless thankfully. If multiple requests are made of the same resource you don't want to have to re-create the same resource over and over again. This enables scalability, especially if your commonly requested REST resources are only of a few types.
Speaking of scalability, stateless also means "connectionless". REST calls are not tied to a particular server and if scalability is an issue, then REST is for you.
Stateless is awesome, but the first issue that should be jumping out at you as an experienced developer is one of message size. Being stateless means that you end up paying with a larger payload. Generally this trade-off is worth it, especially by enabling compression on the REST. That's another post in "REST Best Practices" ( coming soon )