3

I am currently reading up on REST, and one of the specifications of REST is that it should be stateless, and that every request should contain the necessary state in the URL or the body of the request. This contrasts with the practice of using sessions, which is very helpful for maintaining information like whether a user is logged in or not. So, if one wants to design a RESTful API, should sessions be avoided?

Jatinshravan
  • 435
  • 3
  • 16

1 Answers1

2

Well, yes, at least on the server side. That' in fact, is kind of the point of REST: REpresentational State Transfer. By making sure that all needed state information is contained in the state being transfered over HTTP, and eliminating server-side session state, it makes it possible to build easily scaleable, expandable back ends.

Back in the Old Days we had to worry about session state, maintaining sessions, keepalive connections, state-sensitive load-balancing, and on and on. With REST, that's all eliminated.

So now, here's a pop quiz: how do you maintain state for things like login status without server side state? He's a hint: the HTML is not the only state the client manages for you.

Charlie Martin
  • 110,348
  • 25
  • 193
  • 263
  • Okay, so to maintain things like login status without server side state, one possible way would be to include the username and password with every request by the client? But isn't this a little insecure? – Jatinshravan Jun 02 '15 at 21:36
  • 1
    Yes, that would be possible. Now, think about cookies, and encryption. You could make a session ID or authentication ID, cryptographically sign them, and pass those. Here's an example from a Ruby on Rails tutorial: https://www.railstutorial.org/book/log_in_log_out – Charlie Martin Jun 02 '15 at 22:24