For the past few weeks, I have been working on class activities relating to REST API Design. I wanted to research more about it before continuing to homework assignments utilizing it.
This led me to the website: https://www.mulesoft.com/resources/api/what-is-rest-api-design.
REST API is an application programming interface that uses the constraints of REST, or Representational State Transfer. REST API takes advantafge of HTTP which means that developers do not need to install additional software to utilize it. There are six main constraints of REST API design: client-server, stateless, cache, uniform interface, layered system, and Code on Demand.
Client-server constraint: the client and the server should be separate from each other and be able to change separately. This would allow changes to be made to a mobile application without impacting the server, and also for changes to be made to the database or server without affecting the mobile application.
Stateless constraint: REST APIs are stateless, meaning that each call can be made independently and have enough data to complete itself. REST APIs should only rely on the data that is given in the call itself. Servers do not store identifying information; instead the call has that information, be it an access token or user ID. This helps make the API more reliable because it does not need to rely on multiple calls to the server to create an object.
Cache constraint: REST API should encourage cacheable data to be stored.
Uniform interface constraint: the uniform interface should provide a standard way to communicate between the client and server. The uniform interface should also allow the evolution of the application without the application intertwined too much with the API layer.
Layered system constraint: having a layered system helps shield differently accessed components from one another. It allows for systems to be moved in and out of the architecture which can help as technology evolves. It can also help with security, as it can help with attacks at a proxy layer or other layers before it reaches actual server architecture.
Code on Demand constraint: this constraint is optional, but it allows for code or applet to be sent out through the API, meaning the server can add information to the code.
I chose this source because I wanted to read about how REST APIs are broken down, and how these constraints are helpful. This source helped me understand how the individual evolution of the servers and the clients are important, and I will consider this information for when I need to decide if REST API is the type of API I should utilize for a future project.