Since it's inception in 2000, REST has become the standard architectural style for web services or APIs. REST, or Representational State Transfer is concerned with resources or entities on a system and interacting with them with a limited set of predetermined stateless operations. Resources model (represent) what can be considered types of objects in your application. For example, if you are building an application to track books a user has read you might consider creating a ‘book’ resource. Conversely, you might consider instead to build a ‘collection’ resource that has within it different books, or you might model both. Regardless of the exact models, a REST services (also called RESTful services/APIs) expose a standard way for other computers in your application to interact with its resources.
The interactions with the resources of your application start with another standard: HTTP and its available methods or verb that describes the type of interaction. In general, a
GET request will retrieve or fetch a specific resource,
PUT is used to replace the resource, and
POST is used to update or create a new resource, with
DELETE to remove it. Every resource is identifiable by its URL or Uniform Resource Locator. With these two components, we can concisely describe different interactions with the previous example of our book tracking application. If we need to get a book, we can send a
GET request to https://example.com/books/2 which will retrieve the book with an ID of 2. These interactions are stateless because all the information needed to carry them out is included in the request, meaning the server doesn’t have to store information about previous requests with the client for the intended functionality.
Stateless, uniform interactions provide many benefits to the development of an application:
- The structure of your service is easy to document and predictable. When it comes to using the service, you need only know the resources and what effects different HTTP verbs have on it. One common way to convey this is with a table. Consider our book app from earlier
|GET||/books||Retrieve all books|
|GET||/books/:id||Retrieve book by ID|
|POST||/books||Add new book|
|POST||/books/:id||Update book data|
|DELETE||/books/:id||Delete book by ID|
|PUT||/books/:id||Replace book by ID|
- JSON, a file format, has also become another standard in web services communication. HTTP requests and JSON files can be consumed and created in nearly every modern language, allowing services intended to work with one another to be written in different languages. This might be a great decision because of the set of libraries different languages have.
The next couple of benefits I want to list aren’t immediately available to you if your application implements REST web services, but you will be very close. A REST web server deals in stateless requests, but can be completely stateless itself as well by delegating persistent storage to other computers. Stateless web services are ideal for scalability because of these advantages:
You can use a load balancer to distribute each request from a client to any number of servers. This is possible because like we mentioned before, every request has all the information your server needs to respond, so a request doesn’t need to be in communication with the same server over a period of time. This means that one request can go to a server while the next can go to a completely different one that is more available to respond quickly and maintain good user experience.
Stateless web services can be treated like a collection or pool of resources. At any moment one server can be taken out of the pool and others can be put in. Essentially, all these servers are clones of each other and capable of providing the same functionality by spreading the work of handling requests evenly. Servers can stop working at any point service won’t be disrupted because another server can quickly take its place.
REST is a versatile and battle-tested style to design a web service. With the right application, it will bring a lot of power and convenience to the development process and will go a long way in making sure they can scale as well to serve a large audience.
Cover photo by Min An from Pexels
Oldest comments (0)