RESTful Web Services - Statelessness

According to the REST architecture, a RESTful web service does not need to store client state on the server. This restriction is called statelessness. The client is responsible for passing its context to the server, and the server can then store that context for further processing of the client's request. For example, a session maintained by a server is identified by a session identifier passed by the client.
RESTful web services must adhere to this restriction. In the RESTful Web Services - Methods chapter , we saw that web service methods do not store any information from the client they are called from.
Consider the following URL −
https://localhost:8080/usermanagement/rest/userservice/users/1
If you click the link above with a browser or with a Java based client or with Postman, the result will always be a custom XML whose id is 1 because the server does not store any information about the client.
1 mahesh 1
Benefits of statelessness
Following are the benefits of statelessness in RESTful web services.
-
Web services can handle each method request independently.
-
Web services should not support previous client interactions. This simplifies the design of the application.
-
Because HTTP itself is a stateless protocol, RESTful web services work seamlessly with HTTP protocols.
Web services can handle each method request independently.
Web services should not support previous client interactions. This simplifies the design of the application.
Because HTTP itself is a stateless protocol, RESTful web services work seamlessly with HTTP protocols.
Disadvantages of statelessness
Following are the disadvantages of statelessness in RESTful web services.
Web services must receive additional information in each request and then interpret to get the state of the client in case it needs to interact with the client.