The purposes of introducing the statelessness constraint in REST include improvements to visibility, reliability, and scalability. This means that proxies and other intermediaries are better able to participate in communication patterns that involve self-descriptive stateless messages, server death and failover does not result in session state synchronisation problems, and it is easy to add new servers to handle client load again without needing to synchronise session state.
REST achieves statelessness through a number of mechanisms:
- By designing methods and communication patterns that they do not require state to be retained server-side after the request.
- By designing services that expose capabilities to directly sample and transition server-side state without left-over application state
- By "deferring" or passing back state to the client as a message at the end of each request whenever session state or application state is required
The downside of statelessness is exposed in that last point: Applications that demand some kind of session state persist beyond the duration of a single request need to have that state sent back to the client as part of the response message. Next time the client wants to issue a request, the state is again transferred to the service and then back to the client.
you can get more info from herehttp://soundadvice.id.au/blog/2009/06/