REST APIs – In Layman’s Terms
It is often asked what REST API is or what it means. This will be an attempt to break that barrier between technical aficionado and a walk-in layman.
API – Application Programming Interface
An Application Programming Interface (API) is a set of protocols, methods, tools, and subroutine definitions which allow for application software construction. It allows for communication between a client and software components.
Simply put, APIs are waiters in a restaurant.
A customer sits down at the table and goes over the menu. They then make a selection and want to order this or that from the kitchen. The order is taken by the waiter, communicated to the kitchen, and then returned to the customer in its requested presentation.
In this example, the customer is the client and the kitchen is the server where the information is stored. The API is the communicator that connects the two.
REST – Representational State Transfer
Representational State Transfer (REST) is an architectural style with defined constraints that work with the Hypertext Transfer Protocol (HTTP).
An example of a REST API which is commonly used is airline ticket requests. A user types in their destination, the date and time of departure and return, and submits the request. The API is the communication of requesting that information from the server and then returning it to the user in a requested format.
This user, or client, doesn’t have to be a person. If a user enters the request for an airline ticket into an airline price comparison API, then the price comparison API becomes the client on multiple airlines’ REST APIs, each returning results to the requestor; in this case, the price comparison REST API. The price comparison REST API returns that request to the original requestor and completes its function.
It is in this way that REST APIs make up how the majority of the internet works.
What makes REST APIs unique?
For an API to be a REST API, it must meet the REST constraints.
Remember, REST is an architectural style. Imagine HTTP is a house or a building. REST is the architectural style of that building. It follows these architectural constraints:
-
- Client-server architecture
- Statelessness
- Layered system
- Cacheability
- Uniform interface
Architectural constraints of REST API
A client-server architecture, also known as the client-server model, is a defining characteristic. This is the architecture that says a client’s responsibilities are separate from the server.
To look at this another way, the client is the user. It is the person who was ordering the food in the hypothetical restaurant scenario. The kitchen in that scenario would be the server. The waiter is the REST API that makes this separation of responsibilities work.
The kitchen never has to worry about ordering, and the customer never has to worry about the ingredients not used to make the meal.
Statelessness
Remembered data, or information, is what happens when a program is stateful. In computer science terms, when an environment is stateless, it does not remember certain information.
With the restaurant example, it is the equivalent of the kitchen not remembering the table’s order immediately after it’s left with the REST API. Keeping the kitchen in statelessness allows it to remain clean and ready for the next request.
A layered system means that there may be things in between the client and the server. Proxies, gateways, other REST APIs; any number of intermediaries may exist between the requester and the information or resource.
The waiter might have to take the client’s order to a kitchen manager prior to placing the order directly with the kitchen staff.
Cacheability
Clients and intermediaries from the layered system can cache responses from the server. Being able to cache this information at different steps in the layer saves time and sever loads by allowing the information to reach the client faster.
The patron of the restaurant can get the second order more quickly than the first one since all of the ingredients are already out and accounted for in the prep station.
Uniform Interface
The interaction of all components in a REST API will have the same interface. It will have the same set of protocols, uniform resource identifiers (URI), methods, and representations.
This means that no matter who is making the request, no matter how many layers the request goes through, everything communicates in the same way.
The kitchen is filled with all kinds of resources. Any images, videos, text, any objects – all of the ingredients – are resources. Each resource has its own identifier, and each representation of the resource also has its own identifier. To understand resource representation, think of an image file. The file’s information can be displayed as a JPG or an HTML. Each representation of that resource will have its own identifier. This interface will then also allow the client to navigate through the server, too. The user can, in a sense, take a walk around the kitchen with the waiter.
REST APIs – The Wrap-up
REST APIs allow users to surf the internet from any type of OS, from any type of device. Keeping each component separate with the ability to layer and cache, all while remaining stateless, keeps the information moving quickly and in the format the user desires. From a programming stand-point, it is essential to understand REST APIs. Acting as the architecture of the internet, it might be beneficial to work with it, rather than against it.
