Request Driven Architecture (RESTful) - jellyfish-tom/TIL GitHub Wiki
[SOURCES]
Evolution of Request-Driven (RESTful) Architecture
Developers started creating web services in the middle of the 2000s, employing RESTful microservice architecture (representational state transfer), which uses HTTP methods like GET, POST, PUT, and DELETE to communicate with services. This architecture was designed to support basic CRUD (create, read, update, and delete) operations.
RESTful web services soon became a de facto standard for building web APIs, and major companies like Facebook and other cloud-based applications leveraged RESTful architecture in their services.
In recent years, there has been renewed interest in evolving RESTful architecture to make it suitable for some modern-day applications. These efforts include adding support for WebSocket, using JSON-LD for semantic data, and GraphQL for more efficient data retrieval.
What are Request Driven (RESTful) APIs?
Request-driven microservice architectures have a one-way, synchronous communication model with their clients. As a result, they must occur one at a time, in a predetermined sequence, and each interaction halts the process until it is completed, thereby leading clients to always refresh the API backend to retrieve the most up-to-date information.
Request-driven APIs also follow a model where clients communicate with servers via a request-and-response model. This means that a request has to be made by the client for a response to be provided by the server. So, if there is no request, there is no response.
To help you have a better understanding of how request-driven APIs work, let’s imagine we have a music streaming API that provides access to a library of songs, artists, genres, and albums. In this case, the API would include data retrieval endpoints like
- /songs to receive a list of all available songs
- /top-artists to receive a list of all top artists available
- /genre to receive a list of all available song genres
- /albums to receive a list of all available albums
Requests to any of these endpoints could include optional parameters such as filtering by genre or songs. For instance, a request for all jazz songs could appear as follows: GET https://mymusic.com/songs?genre=jazz.
The API would then send back a JSON response with a list of all the songs that are categorized as “jazz.” The song title, artist, album, length, and a preview link could all be attached to this response. However, the user will only receive a carefully curated list specific to the request they made.
Advantages of Request-driven APIs
-
Language agnostic: The request-driven API allows developers to connect modular services written in different languages, regardless of the platform on which they run.
-
Flexibility: REST APIs are versatile in that they can return data in various formats, including JSON, XML, and HTML. This adaptability enables developers to select the format that best meets their requirements.
-
Platform independence: Since they use standard HTTP requests, clients can access them from any platform or device with an internet connection.
-
Cost friendly: Development costs are reduced because upgrades are faster and easier.
Disadvantages of Request-driven APIs
-
Poor user experience: Since most requests are processed on the server side, Request-driven APIs can cause an increase in traffic on backend servers, subsequently slowing response times.
-
High network traffic: Request-driven microservice architecture needs a request-response mechanism, meaning each client request creates network traffic. Hence, this leads to a lot of traffic on the network and problems with latency.
-
Limited scalability and functionality: Since they are stateless, each request is expected to contain all the information the server needs to complete the request. Hence, they may not be suitable for more complex business processes that require multiple interactions and actions.