How Does Web Service API Design Work?
Please Subscribe to our YouTube Channel
Many APIs claim that they are RESTful, though in reality if you examine how they work, these APIs fall short of the constraints and requirements which have been laid out by Dr. Fielding. Dr. Fielding was the first person to talk about RESTful APIs in his year 2000 doctoral thesis. While Dr. Fielding mentions that web service API design has six constraints, three are very well known while three others are not discussed as much. Below we will discuss those three often considered complex constraints:
A Uniform Interface
The best way to decouple the server from the client is to use a uniform interface which enables the independent evolution of an application without the need for having its services, actions or models coupled along the API layer. The uniform interface will allow the client to communicate with the server in just one language which is independent of the backend architecture. The interface ends up providing a solid, and standardized means of communicating between the server and the client by using URI and HTTP resources.
As you might have already figured out the layered system is comprised of multiple layers. Each layer has its own specific responsibility and function. Think of the Model View Controller, where each layer has a responsibility, and the model dictates how each data needs to be formed, with the controller focusing on all the incoming actions with the view focusing on the output. Every layer is independent but communicates with the next. The same principle applies to REST API’s design with each layer of the architecture held together helping to create a hierarchy and consequently a modular and scalable application.
Using a layered system also allows for API developers to encompass legacy systems which means that they have the option of moving less frequently used functions into a separate library while at the same time shielding the more common and modern aspects of its design. The other benefit of a layered system is the ability to move systems both in and out of the architecture as the technology evolves which improves longevity and flexibility so as long as the various modules are coupled loosely.
A layered system also benefits security since it will allow you to stop attacks at the proxy layer and prevent attackers from reaching the server architecture. It is also possible to keep more critical aspects of the architecture behind a firewall, which prevents the client from directly interacting with the server another excellent security measure.
Code on Demand
It is the least known of the constraints and one that is optional. What Code on Demand does is allow for code or perhaps applets to be transmitted using the API within the application. That means it helps to create a smart application which isn’t dependent on a ridged coded structure. Though since this constraint is seen as being ahead of its time, it has struggled for wider adoption amongst API developers across just about every language. However, with the growing focus on artificial intelligence in apps Code on Demand’s adoption will grow significantly.
All six constraints (three from the above) make up the Representational State Transfer also known as REST. If you look at all six of these constraints, it is not hard to see how one builds on top of the other to create a complex, flexible and powerful programming interface. More importantly, the constraints help to make up the design which tends to operate similarly to how users access pages on the World Wide Web.