Udemy REST Assured free

Stateful vs. Stateless Architecture

Below are the difference between Stateless and Stateful Architecture:

Point of Distinction Stateless Stateful
Meaning Statelessness means that every HTTP request happens in complete isolation. When the client makes an HTTP request, it includes all information necessary for the server to fulfill that request. The server never relies on information from previous requests. If that information was important, the client would have sent it again in this request. Stateful means that the server stores information about the client and uses that information over a series of request.
Status and Session Information Don't Store Data. Does not require the server to retain the server information or session details. Application Require Backing Storage. Require server to save the status and session information.
Example Protocol HTTP, UDP, DNS FTP, Telnet
How Server Process Request The server processes requests based only on information relayed with each request and doesn't rely on information from earlier requests – this means that the server doesn't need to hold onto state information between requests; The server processes requests based on the information relayed with each request and information stored from earlier requests – this means that the server must access and hold onto state information generated during the processing of the earlier request;
No. of Server Used to Process Request Different requests can be processed by different servers The same server must be used to process all requests linked to the same state information, or the state information needs to be shared with all servers that need it.
Scaling of Application and Complexity Statelessness helps in scaling the APIs to millions of concurrent users by deploying it to multiple servers. Any server can handle any request because there is no session related dependency. Let's say there is a load balancer and there are two servers behind, running the same Stateful application. The now first request to log in go to server 1 and second request might go to server 2, now since only server one has enabled login to true, the user won’t be able to login when LB sends him to 2nd server. So it’s not possible to horizontally scale Stateful applications.
Caching A stateless API is also easy to cache as well. A specific software can decide whether or not to cache the result of an HTTP request just by looking at that one request. There’s no nagging uncertainty that state from a previous request might affect the cacheability of this one. It improves the performance of applications. -
Track Client The server never loses track of “where” each client is in the application because the client sends all necessary information with each request. Needed
Server Restriction In Stateless, server is not needed to keep the server information or session details to itself. In stateful, a server is required to maintain the current state and session information.

Client/Server Dependency

In stateless, server and client are loosely coupled and can act independently. In stateful, server and client are tightly bound.
Server Design Implementation Server design is easy to implement Complex and difficult to implement
Crash Management A Failed server can be easily restarted after  A server has to keep the information of session and other details. Crash management is difficult.
Transaction Processing Server handles transactions in a very quicker way. Server is slow comparatively.
Implement in Internet Stateless Protocols are easy to implement in Internet. Stateful protocols are logically heavy to implement in Internet.

Video Tutorial: Stateful vs. Stateless Architecture