Level 42
Jan 12, 2017
7
Level 1
Statelessness in REST - Not keeping sessions on the server
Hi,
I was just reading about how Roy Fielding says that the server must not store the client's state on the server. This means that the user sessions we store are not to be stored on the server.
In Laravel, since all its requests are RESTful, should it or should it not store and access user sessions from the server? Currently Laravel creates a session for every logged in user. But does it follow the statelessness constraint of REST?
I am also aware of the HTPP Basic Authentication, which is used for stateless authentication. But then isn't every request in Laravel RESTful? All the routes we create is by keeping RESTfullness in mind.
I'm a bit confused here as to how Laravel functions in terms of RESTfullness.
You can also link me to any resources that'll answer my question.
Thanks in advance.
Level 1
Thanks for the link Saurabh. I already read it. I understood from there that we can't store user sessions on the server side. But Laravel is storing user sessions on the server. So, either my understanding of Laravel's RESTfulness is wrong, or Laravel is not following the constraint that is stated in the above post.
Level 7
Laravel has the option to use sessions for user authentication however if you intend to write an Restful API you may wish to use tokens instead. Commonly referred to as JWTs (JOT). A JWT is sent in the header of an API request. You can then decode the JWT and act on it accordingly. They can contain information such as "expiry time".
That is an extremely simplistic answer but hopefully you get the point.
FYI: I don't think Lumen supports sessions.
Level 1
Thanks for that.
I guess I've understood the concept fairly well now.
Level 80
@ashishsanjayrao Yeah, you shouldn’t use sessions for a RESTful API. The idea is to use an alternative authentication mechanism such as tokens. The tokens can be stored in a database or something, and then included on every HTTP request. The RESTful service then determines from the token whether to execute or refuse the request.
Level 1
@MARTINBEAN - I've tried this using Laravel basic implementation of auth API and api_token field in users table. My question are; 1. is storing a token in database making it statefull and not stateless? and 2. By storing the api_token in users table, it makes a limitation for user, that he / she could only be logged-in from one client at a time?
Level 80
@frumentius I don’t know your application, but when talking about “state” in terms of an API and it being “statement”, it means that one API request should have no knowledge of any API request that came before it.
So every time you make an API request, you need to tell that server who you are. Each and every time. The usual way to do this is with some form of token (be it a simple token stored against the user in the server’s database; an OAuth token; a JWT; and so on). You pass the authentication will your requests, and each time the server will look up the user that corresponds with that token and will go either, “Yes, that’s a valid user” or, “No, that token’s invalid. You’re unauthorised to perform this request.”
So…
-
No, storing a token in a database is not making your API “stateful” if the user has to pass their token with every HTTP request they make to the API for authentication purposes.
-
I don’t think so. A user would be able to pass the same token from multiple clients, would they not?
Please or to participate in this conversation.