What is session state? And what is the importance of having a stateless backend?
I've read somewhere that when defining routes in api.php, you ensure that your server doesn't make use of session state and thus remains stateless. Some time ago I have had trouble differentiating the two (api.php and web.php), on why anyone would still define routes in api.php when they could easily just do so in web.php. But just what is session state? And what is the importance of having a stateless back end? What are good use cases for this? Sample scenarios? Thank you.
@p0t4t0 Session state is just storing data in the browser session. When you log in to a Laravel application, it will store the currently authenticated user’s details in the session and then recall the details from the session on subsequent page visits until you log out or the session is cleared.
RESTful APIs are stateless because they don’t store any in the session (or any other local storage mechanism). You issue a request and you get a response. For each request, you need to authenticate (usually via a token of some sort). This aids in scalability (as the application serving the API doesn’t have to store state of every consumer using it) and easier to cache as you don’t have to worry about state affecting the response, i.e. being “logged in” vs. not being logged in.
Without some sort of session, ie "state", you wouldn't be able to have things like a shopping cart. There would be no way to "remember" things from one page to the next without putting everything in a query string, which you wouldn't want to do with sensitive info and all urls would look something like yoursite.com/some-page?name=cronix&products[]=4&products[]=6&products=1234&method=credit_card&last_visit=20181501 etc.
You also wouldn't be able to have a login system. Sessions are what tell the app you are logged in when going from page to page.
The web is dumb. The server receives a request, and sends a response and closes the connection and that's all it knows. It doesn't remember anything on it's own from request to request. Sessions fix that problem, and is actually why cookies were invented by netscape in the early 90's. It was never part of the http spec to begin with.
5 people are shopping at the same time on a site, that session state is to know who's check out basket is who's. The session cookie (stored in browser) knows which customer you are via the server session generated when you logged in.
