So what makes an API RESTful? I’m sure the term REST API or RESTful API has come across your screen countless times in your coding journey. This article gives an introduction to RESTful API design principles.
Before diving into the six constraints, I’ll briefly describe what an API is and how REST APIs work. API stands for Application Programming Interface. REST stands for REpresentational State Transfer. It is an API architecture with design principles for client-server communication and features.
RESTful APIs communicate through HTTP requests to perform CRUD (create, read, update, and delete) operations in a resource. These operations correspond with method requests (GET, POST, PUT, DELETE). A POST request adds information, a GET request retrieves information, a PUT request updates information, and a DELETE request deletes information. An API that follows the six constraints outlined below is considered RESTful.
The dissertation by Roy Thomas Fielding coining the term REST API can be found here.
In RESTful design, the client and server must be distinct from one another. The client requests information with a Uniform Resource Identifier (URI), and the server responds to the request through HTTP/HTTPS. Both the client and server should evolve independently. This independence allows for scalability on both sides.
The Stateless constraint means that the client state is not stored between requests. The request from the client provides the server with enough information to understand the request without needing to remember any client state. Not storing data about the client request improves scalability.
A Uniform Interface ensures standard client-server communication across platforms. With REST API architecture, a request for the same resource should have the same data. As well as response status codes from the server such as 200 ok, 401 unauthorized, etc.
The client does not always communicate directly with the server. There may be layers of communication. For architecture with several layers, each layer only knows about its immediate communication layer. The layered system allows for intricate tasks to be completed without needing to understand the complexity of what is being done to receive a response.
Cacheable data is information in the response that can be stored and used later.
Server responses should declare if the data is cacheable. For network efficiency, the data in a response from the server is either implicitly or explicitly labeled cacheable or non-cacheable. For cacheable data, the client can reuse the response for future requests.
This constraint improves performance for clients while reducing the payload and improving scalability on the server.
There you have it, the six REST API architecture constraints. Hopefully, this helped fill in some knowledge gaps or gave you a good refresher on RESTful APIs.