What does REST's principle of statelessness actually means?

Question

After reading the introductory articles on REST (Fielding's thesis and other) my perception of statelessness is that there should be no session objects on the server side. Yet, i see Flask (and maybe other REST frameworks in different technologies that i do not know about) gives us a session object to store information on the server in this example:

@app.route('/login', methods=['GET', 'POST'])
def login():
  if request.method == 'POST':
    session['username'] = request.form['username']
    return redirect(url_for('index'))
...

Surely, i am misunderstanding REST's statelessness. So, what is it really?

Answer 1

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:

1. By designing methods and communication patterns that they do not require state to be retained server-side after the request.
2. By designing services that expose capabilities to directly sample and transition server-side state without left-over application state
3. 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/