API Development
Stateless web tier
In this stateless architecture, HTTP requests from users can be sent to any web servers, which fetch state data from a shared data store. State data is stored in a shared data store and kept out of web servers. A stateless system is simpler, more robust, and scalable. Now it is time to consider scaling the web tier horizontally. For this, we need to move state (for instance user session data) out of the web tier. A good practice is to store session data in the persistent storage such as relational database or NoSQL. Each web server in the cluster can access state data from databases. This is called stateless web tier.
Stateful architecture
A stateful server remembers client data (state) from one request to the next. A stateless server keeps no state information.
user A’s session data and profile image are stored in Server 1. To authenticate User A, HTTP requests must be routed to Server 1. If a request is sent to other servers like Server 2, authentication would fail because Server 2 does not contain User A’s session data. Similarly, all HTTP requests from User B must be routed to Server 2; all requests from User C must be sent to Server 3.
The issue is that every request from the same client must be routed to the same server. This can be done with sticky sessions in most load balancers [10]; however, this adds the overhead. Adding or removing servers is much more difficult with this approach. It is also challenging to handle server failures.
-
HTTP GET This retrieves a resource from the server. It is idempotent. Multiple identical requests return the same result.
-
HTTP PUT This updates or Creates a resource. It is idempotent. Multiple identical requests will update the same resource.
-
HTTP POST This is used to create new resources. It is not idempotent, making two identical POST will duplicate the resource creation.
-
HTTP DELETE This is used to delete a resource. It is idempotent. Multiple identical requests will delete the same resource.
-
HTTP PATCH The PATCH method applies partial modifications to a resource.
-
HTTP HEAD The HEAD method asks for a response identical to a GET request but without the response body.
-
HTTP CONNECT The CONNECT method establishes a tunnel to the server identified by the target resource.
-
HTTP OPTIONS This describes the communication options for the target resource.
-
HTTP TRACE This performs a message loop-back test along the path to the target resource.
API Gateway is a fully managed service and it provides an entry point to your microservices. It helps you innovate faster by handling common functions such as API throttling, request caching, authorization and access control, monitoring, version management, and security.
Step 1 - The client sends an HTTP request to the API gateway.
Step 2 - The API gateway parses and validates the attributes in the HTTP request.
Step 3 - The API gateway performs allow-list/deny-list checks.
Step 4 - The API gateway talks to an identity provider for authentication and authorization.
Step 5 - The rate limiting rules are applied to the request. If it is over the limit, the request is rejected.
Steps 6 and 7 - Now that the request has passed basic checks, the API gateway finds the relevant service to route to by path matching.
Step 8 - The API gateway transforms the request into the appropriate protocol and sends it to backend microservices.
Steps 9-12: The API gateway can handle errors properly, and deals with faults if the error takes a longer time to recover (circuit break). It can also leverage ELK (Elastic-Logstash-Kibana) stack for logging and monitoring. We sometimes cache data in the API gateway.
