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

up vote103down votefavorite 55

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? session rest share|improve this question edited Jul 5 '11 at 22:28 Brad Mace 10.7k33677 asked Feb 13 '09 at 2:07 unforgiven3 8,6481555105

3   +1. "Nice Question" ;-) –  Dead account Apr 23 '09 at 13:32 add comment

5 Answers

activeoldestvotes

up vote43down voteaccepted

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. share|improve this answer answered Feb 13 '09 at 2:43 z8000 1,9091525

add comment

up vote16down vote

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). share|improve this answer answered Feb 13 '09 at 2:33 Greg Hewgill 317k66611809

I love this approach. Will start using it right away. –  Thomas Ahle Aug 16 '10 at 23:58 +1 can you please elaborate on : is of limited use to an attacker who intercepts it (since it is based on the current time) ? arent you talking about a cookie which contains encrypted username and password ? like SO does ? (IMHO) –  Royi Namir Apr 14 at 5:09 @RoyiNamir: I am not talking about a cookie. The signature used by S3 is a parameter to the HTTP request, but is not a cookie, it is recalculated for every request. –  Greg Hewgill Apr 14 at 7:37 So if I need to save some information about a user , where would i save it ? in db ? I dont want to go each request to db.... and still i want to use rest....can you please help ? –  Royi Namir Apr 14 at 7:41 @RoyiNamir: If you have specific questions about how to accomplish some goal, please ask a new question. I can't answer additional questions here in the comments. –  Greg Hewgill Apr 14 at 7:46  add comment