If REST applications are supposed to be stateless how do you manage sessions

Question

I m in need of some clarification  I ve been reading about REST  and building RESTful applications  According to wikipedia  REST itself is defined to be Representational State Transfer  I therefore don t understand all this stateless gobbledeygook that everyone keeps spewing  From wikipedia   At any particular time  a client can either be in transition between application states or  quot at rest quot   A client in a rest state is able to interact with its user  but creates no load and consumes no per-client storage on the set of servers or on the network   Are they just saying don t use session application level data store    I get that one goal of REST is to make URI access consistent and available  for instance  instead of hiding paging requests inside posts  making the page number of a request a part of the GET URI   Makes sense to me  But it seems like it is just going overboard saying that no per client data  session data  should ever be stored server side  What if I had a queue of messages  and my user wanted to read the messages  but as he read them  wanted to block certain senders messages coming through for the duration of his session  Wouldn t it make sense to store this in a place on the server side  and have the server only send messages  or message ID s  that were not blocked by the user  Do I really have to send the entire list of message senders to block each time I request the new message list  The message list pertinent to me wouldn t shouldn t even be a publicly available resource in the first place   Again  just trying to understand this  Someone please clarify   Update  I have found a stack overflow question that has an answer that doesn t quite get me all the way there  How to manage state in REST which says that the client state that is important should all be transferred on every request     Ugg   seems like a lot of overhead    Is this right

User · Answer

Stateless means the state of the service doesn’t persist between subsequent requests and response. Each request carries its own user credentials and is individually authenticated. But in stateful each request is known from any prior request. All stateful requests are session-oriented i.e. each request need to know and retain changes made in previous requests.

Banking application is an example of stateful application. Where user first login then make transaction and logs out. If after logout user will try to make the transaction, he will not be able to do so.

Yes, http protocol is essentially a stateless protocol but to make it stateful we make us of HTTP cookies. So, is SOAP by default. But it can be make stateful likewise, depends upon framework you are using.

HTTP is stateless but still we can maintain session in our java application by using different session tracking mechanism.

Yes, We can also maintain session in webservice whether it is REST or SOAP. It can be implemented by using any third party library or you can implement by our own.

Taken from http://gopaldas.org/webservices/soap/webservice-is-stateful-or-stateless-rest-soap

User · Answer

REST is stateless and doesn   t maintain any states between the requests    Client cookies   headers are set to maintain the user state like authentication  Say Client username password are validated by third part authentication mechanism     2nd level OTP gerneation etc  Once user get authenticated     headers  cookies comes to rest service end point exposed and we can assume user as auth  since user is coming with valid headers cookies  Now certain info of user  like IP is either maintained in the cache and  after that if request is coming from same Ip  mac address  for listed resources User is allowed  And cache is maintained for some particular time which get invalidated once time lapses   So either cache can be used or DB entries can be used to persist info b w the requests

User · Answer

Statelessness means that every HTTP request happens in complete isolation  When the client makes an HTTP request  it includes all the information necessary for the server to fulfill that request  The server never relies on information from previous requests  If that information was important  the client would have to send it again in subsequent request  Statelessness also brings new features  It   s easier to distribute a stateless application across load-balanced servers  A stateless application is also easy to cache   There are actually two kinds of state  Application State that lives on the client and Resource State that lives on the server   A web service only needs to care about your application state when you   re actually making a request  The rest of the time  it doesn   t even know you exist  This means that whenever a client makes a request  it must include all the application states the server will need to process it    Resource state is the same for every client  and its proper place is on the server  When you upload a picture to a server  you create a new resource  the new picture has its own URI and can be the target of future requests  You can fetch  modify  and delete this resource through HTTP    Hope this helps differentiate what statelessness and various states mean

User · Answer

I see that the basic issue here is mixing up Session with State  And while REST specifies that you should NOT store the State on the server  nothing prevents you from storing a user Session   Managing the State on the server means that your server knows exactly what the client is doing  what page they re viewing in which section of the application   And this is what you shouldn t need to do   I agree with the other people saying that you should keep the session storage to a minimum size  and while that s common sense  it s actually also dependent on the application  So  in short  you can still keep a session with cached data to handle the requests with less load on the server  and manage the authentication by providing a temporary authentication access token for the client to use  Whenever the session token is expired  generate a new one and ask the client to use it   Someone might argue that the client should better generate the token  I say it works both ways  and it would depend on the application  and who s going to work with the API   Also keeping some sensitive session data on the server should be the right way to do  You cannot trust the client to keep their shopping cart that  for example  contains a field named  isFreeGift   Such information should be kept on the server   The video link provided by Santanu Dey in his answer is helpful  Watch it if you haven t   Just a side note  It seems all the answers already given seem to disregard the fact that some operations could cause a heavy load on the server  That s relevant in terms of power consumption  hardware consumption  and cost  for servers rented by CPU cycle   A good developer shouldn t be lazy in optimizing their application  even if the operation can be done very quickly on a modern CPU on some rented server for which they don t pay its electricity and maintenance bill   Althoght the question is a few years old  I hope that my answer would still be helpful

User · Answer

There is no spoon  Don t think of statelessness like  quot sending all your stuff to the server again and again quot   No way  There will be state  always - database itself is a kind of state after all  you re a registered user  so any set of client-side info won t be valid without the server side  Technically  you re never truly stateless  The Login Debate  What does it even mean to not keep a session - and log in every time  Some mean  quot send the password each time quot   that s just plain stupid  Some say  quot nah of course not  send a token instead quot  - lo and behold  PHP session is doing almost exactly that  It sends a session id which is a kind of token and it helps you reach your personal stuff without resending u pw every time  It s also quite reliable and well tested  And yes  convenient  which can turn into a drawback  see next paragraph   Reduce footprint  What you should do  instead  and what makes real sense  is thin your webserver footprint to the minimum  Languages like PHP make it very easy to just stuff everything in the session storage - but sessions have a price tag  If you have several webservers  they need to share session info  because they share the load too - any of them may have to serve the next request  A shared storage is a must  Server needs to know at least if someone s logged in or not   And if you bother the database every time you need to decide this  you re practically doomed   Shared storages need to be a lot faster than the database  This brings the temptation  okay  I have a very fast storage  why not do everything there  - and that s where things go nasty in the other way   So you re saying  keep session storage to the minimum   Again  it s your decision  You can store stuff there for performance reasons  database is almost always slower than Redis   you can store information redundantly  implement your own caching  whatever - just keep in mind that web servers will have a bigger load if you store a lot of rubbish on them  Also  if they break under heavy loads  and they will   you lose valuable information  with the REST way of thinking  all that happens in this case is the client sends the same     request again and it gets served this time   How to do it right then   No one-fits-all solution here  I d say choose a level of statelessness and go with that  Sessions may be loved by some and hated by others but they re not going anywhere  With every request  send as much information as makes sense  a bit more perhaps  but don t interpret statelessness as not having a session  nor as logging in every time  Somehow the server must know it s you  PHP session ids are one good way  manually generated tokens are another  Think and decide - don t let design trends think for you

User · Answer

Stateless here means that state or meta data of request is not maintained on server side  By maintaining each request or user s state on server  it would lead to performance bottlenecks  Server is just requested with required attributes to perform any specific operations   Coming to managing sessions  or giving customize experience to users  it requires to maintain some meta data or state of user likely user s preferences  past request history  This can be done by maintaining cookies  hidden attributes or into session object   This can maintain or keep track of user s state in the application   Hope this helps

User · Answer

Historical view of user application state management  Sessions in the traditional sense keep the user s state in the application inside the server   This may be the current page in a flow or what has been previously entered but not persisted to the main database yet   The reason for this need was the lack of standards on the client side to effectively maintain the state without making client specific  i e  browser specific  applications or plug-ins   HTML5 and XML Header Request has over time standardized the notion of storing complex data including application state in standard way on the client  i e  browser  side without resorting to going back and forth between the server   General usage of REST services  REST services are generally called when there is a transaction that needs to be performed or if it needs to retrieve data   REST services are meant to be called by the client-side application and not the end user directly   Authenticating  For any request to the server  part of the request should contain the authorization token   How it is implemented is application specific  but in general is either a BASIC or CERTIFICATE form of authentication   Form based authentication is not used by REST services   However  as noted above REST services are not meant to be called by the user  but by the application   The application needs to manage getting the authentication token   In my case I used cookies with JASPIC with OAuth 2 0 to connect to Google for authentication and simple HTTP Authentication for automated testing   I also used HTTP Header authentication via JASPIC for local testing as well  though the same approach can be performed in SiteMinder   As per those examples  the authentication is managed on the client side  though SiteMinder or Google would store the authentication session on their end   there s nothing that can be done about that state  but it is not part of the REST service application   Retrieval requests  Retrieval requests in REST are GET operations where a specific resource is requested and is cacheable   There is no need for server sessions because the request has everything it would need to retrieve the data  authentication and the URI   Transaction scripts  As noted above  the client-side application itself calls the REST services along with the authentication that it manages on the client side as well   What this means for REST services  if done correctly  is to take a single request to the REST server will contain everything that is needed for a single user operation that does everything that is needed in a single transaction  a Transaction Script is what the pattern is called   This is done through a POST request usually  but others such as PUT can also be used   A lot of contrived examples of REST  I myself did this  tried to follow as much of what has been defined in the HTTP protocol  after going through that I decided to be more pragmatic and left it to GET and POST only   The POST method does not even have to implement the POST-REDIRECT-GET pattern   Regardless though  as I had noted above  the client-side application will be the one calling the service and it will only call the POST request with all the data when it needs to  not every time    This prevents constant requests to the server   Polling  Though REST can be used for polling as well   I won t recommend it unless you have to use it because of browser compatibility   For that I would use WebSockets which I had designed an API contract for as well   Another alternative for older browsers is CometD

User · Answer

The major difference between stateless vs Stateful is the data being passed back to the server every time  In case of stateless  the client has to provide all the info so lot of parameters may need to be passed in each request  In Stateful  the cliet passes those parameters once and they are maintained by the server until modified by the client again    IMO  API should be stateless which gives allows to scale up really quickly

User · Answer

Are they just saying don t use session application level data store      No   They aren t saying that in a trivial way   They re saying do not define a  session    Don t login   Don t logout   Provide credentials with the request   Each request stands alone   You still have data stores   You still have authentication and authorization   You just don t waste time establishing sessions and maintaining session state     The point is that each request  a  stands completely alone and  b  can be trivially farmed out to a giant parallel server farm without any actual work   Apache or Squid can pass RESTful requests around blindly and successfully      What if I had a queue of messages  and my user wanted to read the messages  but as he read them  wanted to block certain senders messages coming through for the duration of his session    If the user wants a filter  then simply provide the filter on each request      Wouldn t it make sense to     have the server only send messages  or message ID s  that were not blocked by the user    Yes   Provide the filter in the RESTful URI request      Do I really have to send the entire list of message senders to block each time I request the new message list     Yes   How big can this  list of message senders to block  be   A short list of PK s     A GET request can be very large   If necessary  you can try a POST request even though it sounds like a kind of query

User · Answer

You are absolutely right  supporting completely stateless interactions with the server does put an additional burden on the client   However  if you consider scaling an application  the computation power of the clients is directly proportional to the number of clients  Therefore scaling to high numbers of clients is much more feasible     As soon as you put a tiny bit of responsibility on the server to manage some information related to a specific client s interactions  that burden can quickly grow to consume the server   It s a trade off

User · Answer

REST is very abstract  It helps to have some good  simple  real-world examples    Take for example all major social media apps -- Tumblr  Instagram  Facebook  and Twitter  They all have a forever-scrolling view where the farther you scroll down  the more content you see  further and further back in time  However  we ve all experienced that moment where you lose where you were scrolled to  and the app resets you back to the top  Like if you quit the app  then when you reopen it  you re back at the top again   The reason why  is because the server did not store your session state  Sadly  your scroll position was just stored in RAM on the client    Fortunately you don t have to log back in when you reconnect  but that s only because your client-side also stored login certificate has not expired  Delete and reinstall the app  and you re going to have to log back in  because the server did not associate your IP address with your session    You don t have a login session on the server  because they abide by REST     Now the above examples don t involve a web browser at all  but on the back end  the apps are communicating via HTTPS with their host servers  My point is that REST does not have to involve cookies and browsers etc  There are various means of storing client-side session state    But lets talk about web browsers for a second  because that brings up another major advantage of REST that nobody here is talking about   If the server tried to store session state  how is it supposed to identify each individual client    It could not use their IP address  because many people could be using that same address on a shared router  So how  then    It can t use MAC address for many reasons  not the least of which because you can be logged into multiple different Facebook accounts simultaneously on different browsers plus the app  One browser can easily pretend to be another one  and MAC addresses are just as easy to spoof   If the server has to store some client-side state to identify you  it has to store it in RAM longer than just the time it takes to process your requests  or else it has to cache that data  Servers have limited amounts of RAM and cache  not to mention processor speed  Server-side state adds to all three  exponentially  Plus if the server is going to store any state about your sessions then it has to store it separately for each browser and app you re currently logged in with  and also for each different device you use     So    I hope that you see now why REST is so important for scalability   I hope you can start to see why server-side session state is to server scalability what welded-on anvils are to car acceleration      Where people get confused is by thinking that  state  refers to  like  information stored in a database  No  it refers to any information that needs to be in the RAM of the server when you re using it

User · Answer

You have to manage client session on the client side  This means that you have to send authentication data with every request  and you probably  but not necessary have an in-memory cache on the server  which pairs auth data to user information like identity  permissions  etc     This REST statelessness constraint is very important  Without applying this constraint  your server side application won t scale well  because maintaining every single client session will be its Achilles  heel

User · Answer

The whole concept is different    You don t need to manage sessions if you are trying to implement RESTFul protocol  In that case it is better to do authentication procedure on every request  whereas there is an extra cost to it in terms of performance - hashing password would be a good example  not a big deal      If you use sessions - how can you distribute load across multiple servers  I bet RESTFul protocol is meant to eliminate sessions whatsoever - you don t really need them    That s why it is called  stateless   Sessions are only required when you cannot store anything other than Cookie on a client side after a reqest has been made  take old  non Javascript HTML5-supporting browser as an example   In case of  full-featured  RESTFul client it is usually safe to store base64 login password  on a client side  in memory  until the applictation is still loaded - the application is used to access to the only host and the cookie cannot be compromised by the third party scripts     I would stronly recommend to disable cookie authentication for RESTFul sevices    check out Basic Digest Auth - that should be enough for RESTFul based services

User · Answer

Have a look at this presentation    http   youtu be MRxTP-rQ-S8  According to this pattern - create transient restful resources to manage state if and when  really needed  Avoid explicit sessions

User · Answer

The fundamental explanation is   No client session state on the server   By stateless it means that the server does not store any state about the client session on the server side  The client session is stored on the client  The server is stateless means that every server can service any client at any time  there is no session affinity or sticky sessions  The relevant session information is stored on the client and passed to the server as needed  That does not preclude other services that the web server talks to from maintaining state about business objects such as shopping carts  just not about the client s current application session state  The client s application state should never be stored on the server  but passed around from the client to every place that needs it  That is where the ST in REST comes from  State Transfer  You transfer the state around instead of having the server store it  This is the only way to scale to millions of concurrent users  If for no other reason than because millions of sessions is millions of sessions  The load of session management is amortized across all the clients  the clients store their session state and the servers can service many orders of magnitude or more clients in a stateless fashion  Even for a service that you think will only need in the 10 s of thousands of concurrent users  you still should make your service stateless  Tens of thousands is still tens of thousands and there will be time and space cost associated with it  Stateless is how the HTTP protocol and the web in general was designed to operate and is an overall simpler implementation and you have a single code path instead of a bunch of server side logic to maintain a bunch of session state  There are some very basic implementation principles  These are principles not implementations  how you meet these principles may vary  In summary  the five key principles are   Give every    thing    an ID Link things together Use standard methods Resources with multiple representations Communicate statelessly  There is nothing about authentication or authorization in the REST dissertation  Because there is nothing different from authenticating a request that is RESTful from one that is not  Authentication is irrelevant to the RESTful discussion  Explaining how to create a stateless application for your particular requirements  is too-broad for StackOverflow  Implementing Authentication and Authorization as it pertains to REST is even more so too-broad and various approaches to implementations are explained in great detail on the internet in general   Comments asking for help info on this will should just be flagged as No Longer Needed

User · Answer

When you develop a RESTful service  in order to be logged in you will need your user to be authenticated  A possible option would be to send the username and password each time you intend to do a user action  In this case the server will not store session-data at all   Another option is to generate a session-id on the server and send it to the client  so the client will be able to send session-id to the server and authenticate with that  This is much much safer than sending username and password each time  since if somebody gets their hand on that data  then he she can impersonate the user until the username and password is changed  You may say that even the session id can be stolen and the user will be impersonated in that case and you are right  However  in this case impersonating the user will only be possible while the session id is valid   If the RESTful API expects username and password in order to change username and password  then even if somebody impersonated the user using the session id  the hacker will not be able to lock out the real user   A session-id could be generated by one-way-locking  encryption  of something which identifies the user and adding the time to the session id  this way the session s expiry time could be defined   The server may or may not store session ids  Of course  if the server stores the session id  then it would violate the criteria defined in the question  However  it is only important to make sure that the session id can be validated for the given user  which does not necessitate storing the session id  Imagine a way that you have a one-way-encryption of  email  user id and some user-specific private data  like favorite color  this would be the first level and somehow adding the username date to the encrypted string and apply a two-way encryption  As a result when a session id is received  the second level could be decrypted to be able to determine which username the user claims to be and whether the session time is right  If this is valid  then the first level of encryption could be validated by doing that encryption again and checking whether it matches the string  You do not need to store session data in order to achieve that

[rest] If REST applications are supposed to be stateless, how do you manage sessions?

Examples related to rest

Examples related to session-state