Home Do sessions really violate RESTfulness?

# Do sessions really violate RESTfulness?

deceze
1#
deceze Published in 2011-05-20 06:13:09Z
 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?
Michał Ciuba
2#
Michał Ciuba Reply to 2015-01-25 13:19:25Z
Val Entin
3#
Val Entin Reply to 2014-11-24 00:22:24Z
deceze
4#
 Sessions are not RESTless Do you mean that REST service for http-use only or I got smth wrong? Cookie-based session must be used only for own(!) http-based services! (It could be a problem to work with cookie, e.g. from Mobile/Console/Desktop/etc.) if you provide RESTful service for 3d party developers, never use cookie-based session, use tokens instead to avoid the problems with security.
starteleport
5#
 Cookies are not for authentication. Why reinvent a wheel? HTTP has well-designed authentication mechanisms. If we use cookies, we fall into using HTTP as a transport protocol only, thus we need to create our own signaling system, for example, to tell users that they supplied wrong authentication (using HTTP 401 would be incorrect as we probably wouldn't supply Www-Authenticate to a client, as HTTP specs require :) ). It should also be noted that Set-Cookie is only a recommendation for client. Its contents may be or may not be saved (for example, if cookies are disabled), while Authorization header is sent automatically on every request. Another point is that, to obtain an authorization cookie, you'll probably want to supply your credentials somewhere first? If so, then wouldn't it be RESTless? Simple example: You try GET /a without cookie You get an authorization request somehow You go and authorize somehow like POST /auth You get Set-Cookie You try GET /a with cookie. But does GET /a behave idempotently in this case? To sum this up, I believe that if we access some resource and we need to authenticate, then we must authenticate on that same resource, not anywhere else.