The term API (Application Programming Interface) refers to a software interface that enables two programs to communicate with one another and exchange data.
But not all APIs are REST APIs, so what’s the difference exactly?
REST APIs adhere to the design principles of REST (Representational State Transfer) software architecture.
There are six principles to REST design. These are known as architectural constraints and are defined below.
1. Uniform interface
There are four interfaces to maintain uniformity and simplify the overall architecture. These are:
- Resource identification
- Resource manipulation through representations
- Self-descriptive messages
- Hypermedia as the engine of the application state
2. Client-Sever decoupling
Decoupling means the separation and independence of two or more entities.
By separating the user interface from data storage, we increase the user interface’s portability and the server components’ scalability.
3. Stateless
REST APIs are stateless, meaning servers should not store any data about a request, and each request contains all the necessary information to process it fully.
Each API call made is independent of one another.
4. Layered System architecture
There are other intermediary components between the client and end server, and neither knows if they are interacting directly with each other.
These layers add better flexibility and security because each layer cannot interact outside of its own.
5. Cacheable
Because of statelessness, data is only storable on the client-side via cache.
Sever responses must indicate whether the data sent is cacheable using HTTP Cache-Control headers.
The aim is to improve client-side performance.
6. Code on demand
This final constraint is not required but permits that executable code can be sent to the client in a server response instead of sending static resources as usual.
The aim here is to improve client functionality and system extensibility.
