Can you help me understand this? "Common REST Mistakes: Sessions are irrelevant"

Disclaimer: I'm new to the REST school of thought, and I'm trying to wrap my mind around it.

So, I'm reading this page, Common REST Mistakes, and I've found I'm completely baffled by the section on sessions being irrelevant. This is what the page says:

> There should be no need for a client > to "login" or "start a connection." > HTTP authentication is done > automatically on every message. Client > applications are consumers of > resources, not services. Therefore > there is nothing to log in to! Let's > say that you are booking a flight on a > REST web service. You don't create a > new "session" connection to the > service. Rather you ask the "itinerary > creator object" to create you a new > itinerary. You can start filling in > the blanks but then get some totally > different component elsewhere on the > web to fill in some other blanks. > There is no session so there is no > problem of migrating session state > between clients. There is also no > issue of "session affinity" in the > server (though there are still load > balancing issues to continue).

Okay, I get that HTTP authentication is done automatically on every message - but how? Is the username/password sent with every request? Doesn't that just increase attack surface area? I feel like I'm missing part of the puzzle.

Would it be bad to have a REST service, say, /session, that accepts a GET request, where you'd pass in a username/password as part of the request, and returns a session token if the authentication was successful, that could be then passed along with subsequent requests? Does that make sense from a REST point of view, or is that missing the point?

To be RESTful, each HTTP request should carry enough information by itself for its recipient to process it to be in complete harmony with the stateless nature of HTTP.

> Okay, I get that HTTP authentication > is done automatically on every message > - but how?

Yes, the username and password is sent with every request. The common methods to do so are basic access authentication and digest access authentication. And yes, an eavesdropper can capture the user's credentials. One would thus encrypt all data sent and received using Transport Layer Security (TLS).

> Would it be bad to have a REST > service, say, /session, that accepts a > GET request, where you'd pass in a > username/password as part of the > request, and returns a session token > if the authentication was successful, > that could be then passed along with > subsequent requests? Does that make > sense from a REST point of view, or is > that missing the point?

This would not be RESTful since it carries state but it is however quite common since it's a convenience for users; a user does not have to login each time.

What you describe in a "session token" is commonly referred to as a login cookie. For instance, if you try to login to your Yahoo! account there's a checkbox that says "keep me logged in for 2 weeks". This is essentially saying (in your words) "keep my session token alive for 2 weeks if I login successfully." Web browsers will send such login cookies (and possibly others) with each HTTP request you ask it to make for you.

It is not uncommon for a REST service to require authentication for every HTTP request. For example, Amazon S3 requires that every request have a signature that is derived from the user credentials, the exact request to perform, and the current time. This signature is easy to calculate on the client side, can be quickly verified by the server, and is of limited use to an attacker who intercepts it (since it is based on the current time).

Many people don't understand REST principales very clearly, using a session token doesn't mean always you're stateful, the reason to send username/password with each request is only for authentication and the same for sending a token (generated by login process) just to decide if the client has permission to request data or not, you only violate REST convetions when you use weither username/password or session tokens to decide what data to show ! instead you have to use them only for athentication (to show data or not to show data)

in your case i say YES this is RESTy, but try avoiding using native php sessions in your REST API and start generating your own hashed tokens that expire in determined periode of time!

No, it doesn't miss the point. Google's http://code.google.com/intl/no/apis/accounts/docs/AuthForInstalledApps.html">ClientLogin</a> works in exactly this way with the notable exception that the client is instructed to go to the "/session" using a HTTP 401 response. But this doesn't create a session, it only creates a way for clients to (temporarily) authenticate themselves without passing the credentials in the clear, and for the server to control the validity of these temporary credentials as it sees fit.

> Okay, I get that HTTP authentication > is done automatically on every message > - but how?

"Authorization:" HTTP header send by client. Either basic (plain text) or digest.

> Would it be bad to have a REST > service, say, /session, that accepts a > GET request, where you'd pass in a > username/password as part of the > request, and returns a session token > if the authentication was successful, > that could be then passed along with > subsequent requests? Does that make > sense from a REST point of view, or is > that missing the point?

The whole idea of session is to make stateful applications using stateless protocol (HTTP) and dumb client (web browser), by maintaining the state on server's side. One of the REST principles is "Every resource is uniquely addressable using a universal syntax for use in hypermedia links". Session variables are something that cannot be accessed via URI. Truly RESTful application would maintain state on client's side, sending all the necessary variables over by HTTP, preferably in the URI.

Example: search with pagination. You'd have URL in form

http://server/search/urlencoded-search-terms/page_num

It's has a lot in common with bookmarkable URLs

I think your suggestion is OK, if you want to control the client session life time. I think that RESTful architecture encourages you to develop stateless applications. As @2pence wrote "each HTTP request should carry enough information by itself for its recipient to process it to be in complete harmony with the stateless nature of HTTP" .

However, not always that is the case, sometimes the application needs to tell when client logs-in or logs-out and to maintain resources such as locks or licenses based on this information. See my follow up question for an example of such case.