Do sessions really violate RESTfulness?

Is using sessions in a RESTful API really violating RESTfulness? I have seen many opinions going either direction, but I’m not convinced that sessions are RESTless. From my point of view:

• authentication is not prohibited for RESTfulness (otherwise there’d be little use in RESTful services)
• authentication is done by sending an authentication token in the request, usually the header
• this authentication token needs to be obtained somehow and may be revoked, in which case it needs to be renewed
• the authentication token needs to be validated by the server (otherwise it wouldn’t be authentication)

So how do sessions violate this?

• client-side, sessions are realized using cookies
• cookies are simply an extra HTTP header
• a session cookie can be obtained and revoked at any time
• session cookies can have an infinite life time if need be
• the session id (authentication token) is validated server-side

As such, to the client, a session cookie is exactly the same as any other HTTP header based authentication mechanism, except that it uses the Cookie header instead of the Authorization or some other proprietary header. If there was no session attached to the cookie value server-side, why would that make a difference? The server side implementation does not need to concern the client as long as the server behaves RESTful. As such, cookies by themselves should not make an API RESTless, and sessions are simply cookies to the client.

Are my assumptions wrong? What makes session cookies RESTless?

First, let’s define some terms:

• RESTful:

  One can characterise applications conforming to the REST constraints
  described in this section as “RESTful”.[15] If a service violates any
  of the required constraints, it cannot be considered RESTful.

  according to wikipedia.

• stateless constraint:

  We next add a constraint to the client-server interaction:
  communication must be stateless in nature, as in the
  client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3),
  such that each request from client to server must contain all of the
  information necessary to understand the request, and cannot take
  advantage of any stored context on the server. Session state is
  therefore kept entirely on the client.

  according to the Fielding dissertation.

So server side sessions violate the stateless constraint of REST, and so RESTfulness either.

As such, to the client, a session cookie is exactly the same as any
other HTTP header based authentication mechanism, except that it uses
the Cookie header instead of the Authorization or some other
proprietary header.

By session cookies you store the client state on the server and so your request has a context. Let’s try to add a load balancer and another service instance to your system. In this case you have to share the sessions between the service instances. It is hard to maintain and extend such a system, so it scales badly…

In my opinion there is nothing wrong with cookies. The cookie technology is a client side storing mechanism in where the stored data is attached automatically to cookie headers by every request. I don’t know of a REST constraint which has problem with that kind of technology. So there is no problem with the technology itself, the problem is with its usage. Fielding wrote a sub-section about why he thinks HTTP cookies are bad.

From my point of view:

• authentication is not prohibited for RESTfulness (otherwise there’d be little use in RESTful services)
• authentication is done by sending an authentication token in the request, usually the header
• this authentication token needs to be obtained somehow and may be revoked, in which case it needs to be renewed
• the authentication token needs to be validated by the server (otherwise it wouldn’t be authentication)

Your point of view was pretty solid. The only problem was with the concept of creating authentication token on the server. You don’t need that part. What you need is storing username and password on the client and send it with every request. You don’t need more to do this than HTTP basic auth and an encrypted connection:

• Figure 1. – Stateless authentication by trusted clients

You probably need an in-memory auth cache on server side to make things faster, since you have to authenticate every request.

Now this works pretty well by trusted clients written by you, but what about 3rd party clients? They cannot have the username and password and all the permissions of the users. So you have to store separately what permissions a 3rd party client can have by a specific user. So the client developers can register they 3rd party clients, and get an unique API key and the users can allow 3rd party clients to access some part of their permissions. Like reading the name and email address, or listing their friends, etc… After allowing a 3rd party client the server will generate an access token. These access token can be used by the 3rd party client to access the permissions granted by the user, like so:

• Figure 2. – Stateless authentication by 3rd party clients

So the 3rd party client can get the access token from a trusted client (or directly from the user). After that it can send a valid request with the API key and access token. This is the most basic 3rd party auth mechanism. You can read more about the implementation details in the documentation of every 3rd party auth system, e.g. OAuth. Of course this can be more complex and more secure, for example you can sign the details of every single request on server side and send the signature along with the request, and so on… The actual solution depends on your application’s need.