What does REST's principle of statelessness actually means?

 

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?

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/

    No, you understand well. There shouldn't be any "session" in a RESTful service. Always check that you can send any URI by mail, keep it in bookmarks, and reference it in links. This is indeed why REST is so important to the Web: no RESTful resources = no more links. Authentication should only be done when accessing the resource representation.

    What you can have instead of sessions is a user object (for example a shopping cart) that can be modified by REST methods. This is different from a session, since, for example, there could be services where you could authorize other people to see your shopping cart.

    In REST architecture, Session state is kept entirely on the client. This means data cannot be left on the server in a shared context and we still have to send the repetitive data (per-interaction overhead) in a series of requests. As we keep the application state on the client-side, this reduces the server's control over consistent application behavior, since the application becomes dependent on the correct implementation of semantics across multiple client versions. However this constraint induces the properties of visibility, reliability, and scalability.

  • Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request.
  • Reliability is improved because it eases the task of recovering from partial failures.
  • Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn't have to manage resource usage across requests.

    • see http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

    链接地址: http://www.djcxy.com/p/41142.html

    上一篇: .NET Web API +会话超时

    下一篇: REST的无国籍原则实际上意味着什么？