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 "at rest". 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??

Draghound

@S.Lott: I don't think it's intentionally misleading. I think it is a misunderstanding because of confusing terminology. – Milquetoast

@JUST MY correct OPINION: Interesting guess. I could not believe such a thing, myself, since it is obvious from that "stateless" means the REST protocol itself is stateless; which says nothing about the underlying application state and updating it with PUT, POST and DELETE requests. – Publicize

@Publicize : The HTTP protocol itself is stateless. From what we've discussed below, REST is a viewpoint of how to build your app while not having the webserver handle session state (as opposed to other kinds of state in things like the DB). I didn't even think REST was a protocol, but rather a view on how to use the HTTP protocol. I thought you guys cleared it up that it was about how to build your application to scale by having the client side store all client specific session data, and making URI accesses as idempotent as possible, except where they shouldn't be. Maybe not... :( – Draghound

"Maybe not.." What does that mean? Do you have a new question? Feel free to search SO for it. If it doesn't exist here, then ask it. – Publicize

Has anyone read Webber, Parastatidis and Robinson's ReST in Practice (or otherwise seen their restbucks example)? The answers below make sense, but surely the coffee orders in the restbucks example are state about a client? The number of orders scales with the number of clients. Where is the line between client state and a resource? – Guideboard

Answer 1

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:

1. Give every “thing” an ID
2. Link things together
3. Use standard methods
4. Resources with multiple representations
5. 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.

Oday

That seems like a pretty bold statement that it is the only way to scale to millions of users. Why can't server side sessions be just another service? – Draghound

@Zak: Because millions of sessions is millions of sessions. The point is to avoid the overhead of all this session management. – Publicize

it is not boldness it is experience – Oday

It seems like for an application that you only expect to have, say, 10,000 concurrent users it would be more efficient to use sessions though. 10,000 sessions shouldn't be an issue for one server, and that way you avoid the necessity for database access (user validation) with every request. Shouldn't you move to full REST when your application requires it? – Anguilla

Nothing in my answer implies a solution based on database access on every request, if you think it does, it is a failing on your part to understand authentication and authorization at that scale. The authentication can be implicit in the state, do you think that facebook does a "database access" on every request of its REST API? Or Google for that matter? hint: no – Oday

So, if I store the user state in a distributed cache say memcache, and all my web server now does not need to store any state but go and get state from memcache, can I consider this application stateless? – Lagasse

@Jaskey - no you are storing client state how can that be considered stateless. This is really simple, the client must store its own state and pass it around to all the systems that need it. The clients will always be more scalable than anything you can afford to build. – Oday

If session is saved only in the client side as you suggest, how you achieve PERSISTENCY? the typical example is shopping cart, if a user accidantly close the browser during the shopping, will the data be lost? – Deformation

addition to the previous commnet: you can store the session in the server's database (https://mcmap.net/q/65193/-rest-shopping-cart) but this is not always the best architecture due to a lot of I/O that may lead performance issues – Deformation

@Deformation The cart would be stored in a database. It's not really session state; it's data associated with the user that should be saved even when the user exits. If the shopping cart is stored in the server session the user will still lose it anyway when they close their browser (if using the typical server session setup of using a time limited session token saved in a session cookie). You could also store the cart in local storage on the client which would persist for a while. – Mccullough

A webcontainer like tomcat already has session mgmt so that means it would have an in-memory mapping of session-id -> client-id. So does this in-memory mapping make the server side stateful ? Because in this case, both server and client have stored some information about the state. – Donny

This is fundamentally incompatible with any notion of "paged view of search results", right? ALL results need to be transmitted to the clients in one go on the first request, otherwise the server would need to redo the search for each page... – Memorandum

Answer 2

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.

Astereognosis

Does this mean that every time a request is sent the client should send its user/password to authenticate? Because I guess storing a session, even if it is on a shared no-sql db among all servers, is not stateless, or is it? – Montsaintmichel

@CarlosNavarroAstiasarán there are various techniques for handling stateless authentication. Google JWT for example. – Dagan

@geoidesic: "Because JSON web tokens are stateless, there is no way to invalidate them without storing server state, thus defeating the advantage of stateless tokens." WIkipedia – Unguent

@Unguent That’s a gross misrepresentation of what you can do with the tokens. It’s quite simple to store an approved ID along with the token and to only accept tokens that have an approved ID as a claim. Stateless doesn’t mean you can’t something in a database. Essentially you store an ID in the database that must match the same ID in the token. To revoke the token you remove the ID from the database. No state is remembered in the service itself. Or even better you store the sign key with the user in the database and revoke the key. – Verticillate

@AndrewTFinnell: If you have to store the approved ID on the server, then it has to be stored on all potential servers that could process the REST login, which could involve a lot of server state across a massively parallel web-server architecture. – Unguent

Sentences from this answer have been copied word-to-word from the book "RESTful Web Design by Leonard Richardson & Sam Ruby". It would be great if you would have given its reference in your answer. Please read this to understand meta.https://mcmap.net/q/65194/-what-39-s-wrong-with-this-asp-recursive-function what Stackoverflow thinks about plagiarism – Lisette

Answer 3

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.

Publicize

"Don't login. Don't logout. Provide credentials with the request." I always see responses like this in questions about how to remain stateless in a REST API without any details on where/how one should store those credentials on the client. Surely we shouldn't store username and password in local storage! – Conium

@Conium can we not store a token in localstorage and use that token in requests which will uniquely identify the user? – Mann

Localstorage has a lot of security concerns from what I understand. But also there's a bunch of other concerns with client side sessions, like invalidating tokens, logging a user out, etc. – Conium

you use JWT which have a signature, signature verification is fast so you can check the validity of that state. – Wesleywesleyan

@ArchimedesTrajano to verify a token we need to search for it in a table that contains every issued token & their corresponding user, right? And this table needs to be stored in the server for security reasons. So it can't be used in a REST application. – Anandrous

you can do it two ways, one is to have it stored on the server and lookup the other is to have a mathematical proof (like the signature) to distribute the load better because it's all math. – Wesleywesleyan

Answer 4

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.

Sunbow

Answer 5

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.

Wesleywesleyan

Answer 6

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.

Asexual

Great answer! Your anvil example really hit home. It was exactly what I was thinking but you put it to words! Thanks! – Elwina

This presents much more clarity on what RESTful architecture does and effects than the other answers. – Willettewilley

Answer 7

There is no spoon.

Don't think of statelessness like "sending all your stuff to the server again and again". 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 "send the password each time", that's just plain stupid. Some say "nah of course not, send a token instead" - lo and behold, PHP session is doing just 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.

Tautologize

"Think and decide, don't let design trends think for you." unfortunately it become very common nowadays to just stupidly follow trends. Sometimes reading SO you will get all the same answers just because of trend. – Ldopa

Yes, I've seen this around many topics and when I realize what's happening, sometimes I stop arguing. Back then everyone was crazy about how content-box is better than border-box; it was one way to show hatred against IE. Then came bootstrap and suddenly everyone was a border-box believer. Trends come but then they go. Use goto, use tables, use iframes, just know what you're doing and why. Trendists will try to bring you down, then they register and pay on your site. World saved again. – Tautologize

@Tautologize I didn't understand that part: "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.) ". Say you store session data in the database with PHP. Why is querying the DB for login bad (doomed is a strong word) as anyway there will be many subsequent DB request to get the complete user data and other stuff, based on the PHP session ID? In other words, DB queries are inevitable in any case. Also, if you don't receive a PHP session ID, you know the user is unauthenticated, no need to query. – Stylobate

When you have thousands or even millions of users, you can't afford the luxury of connecting to db every time you want to do a keepalive, location update, message poll, or anything that needs a brief check-in. You have to implement these calls without (or with minimal) database access, that's why I'm saying it can be lethal if you build your whole concept around db. Again, there can be cases where a well-designed db solution will work, but the typical programmer will solve anything by saying "okay, first we connect and fetch some user info". Baaaad practice. – Tautologize

Correct. Also: I tried implementing things such as Login Server myself - just so I know why I don't want to ever do this again. Use standardized patterns, procedures and frameworks. The authentication and authorization processes are pretty technical. But what about "sessions", that do not yet have to be persisted? Well - technically you still can persist them, but mark them as transient for as long as e.g. a contract has not been actually "saved" or printed or something. Also: I'd like to keep communication via services instead of via a common database (seen this, too). – Voelker

Why is noone here mentioning JWT tokens and the like? Those tokens contain one's identity, their claims (ie permissions), expiration time and more. With tokens you actually don't need to make a DB lookup and don't need shared state to authenticate a caller. – Renal

@Renal Good point! I never knew they're a serious solution but now I see they're being used quite often. While it still sounds a bit risky to give a standalone key to a client and accept it without checking against a centralized db, it could be a good solution for relatively short-term situations like repeated calls within one hour or day, thus check against the server less frequently. By all means it is something to consider! – Tautologize

@Tautologize Typically you wouldn't give your client this "key". Instead their client authenticates against an identity provider that issues this token, and those tokens typically expire after a certain amount of time. The one important thing that the server needs to do is validate the token, which includes checking the signature against the issuer's certificate. – Renal

@Renal Sure, it's likely that I don't know enough of this technology because I never used it on battlefield. – Tautologize

Answer 8

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.

Luthern

I generally agree with this sentiment, but there's been a recent trend to claim that even a session identifier shouldn't be stored on the server. I've yet to find out what the alternative solution is, JWT is well touted, but comes with a handful of gotchas: cryto.net/~joepie91/blog/2016/06/19/… – Conium

Answer 9

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

Broody

Answer 10

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.

Aretina

Answer 11

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.

Lucerne

this makes sense – Renitarenitent

Answer 12

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.

Zermatt

If you send auth data with each request, where/how do you store the credentials on the client so the user doesn't have to re-enter it on every request? – Violaviolable

Answer 13

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.

Actuality

Answer 14

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!

Parenthesize

Answer 15

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.

Wardwarde

What is a client side (in memory) and how it is safe to save base64(login:password) in client side? – Sharynshashlik

Nothing is defined as "completely safe". However, you can consider to use OAuth2 providing better security than saving base64 string for API request (Basic Auth), if you stick on Basic auth, you can use HTTPS for better security. – Medication

RN Kushwaha, this is the question no one seems to want to answer when they tell you to stop storing session on server and store it in the client. – Conium