As per the REST architecture, a RESTful Web Service should not keep a client state on the server. This restriction is called Statelessness. It is the responsibility of the client to pass its context to the server and then the server can store this context to process the client's further request. For example, session maintained by server is identified by session identifier passed by the client.
RESTful Web Services should adhere to this restriction. We have seen this in the RESTful Web Services - Methods chapter, that the web service methods are not storing any information from the client they are invoked from.
Consider the following URL −
https://localhost:8080/UserManagement/rest/UserService/users/1
If you hit the above url using your browser or using a java based client or using Postman, result will always be the User XML whose Id is 1 because the server does not store any information about the client.
<user> <id>1</id> <name>mahesh</name> <profession>1</profession> </user>
Following are the benefits of statelessness in RESTful Web Services −
Web services can treat each method request independently.
Web services need not maintain the client's previous interactions. It simplifies the application design.
As HTTP is itself a statelessness protocol, RESTful Web Services work seamlessly with the HTTP protocols.
Following are the disadvantages of statelessness in RESTful Web Services −
Web services need to get extra information in each request and then interpret to get the client's state in case the client interactions are to be taken care of.