I can not find a good definition for these concepts. My own understanding:
stateless – the status is not stored on the server. Those. In each new query, we transfer our username / password (if an application is authorization) , as well as data for the request.
statefull – the server opens the session. Thanks to this, we do not need to constantly send a login / password to the server. And it is not necessary to send some additional data (for example, the selected localization) , they are stored in the session.
And I also identified three levels where temporary data can be stored (for example, a shopping cart) :
- cookies
- session
database
and I’m confused. For example, it is mainly recommended to make stateless applications. But how in this concept to process the same basket of goods? Because it is not very reasonable to store it in cookies, but if you do not store it in the session (because the sessions in Stateless are excluded) , what remains – storage in the database?
I understand that the REST stateless is perfect, because there are single requests and easier to create a session than to create. Well, what about the applications with UI? Where can I keep a shopping cart? can be the concept of stateless and statefull in principle apply only to the REST API?
So the question is what stateless and statefull is, it is very desirable with examples, which will be considered stateless, and what is not.
Answer 1, Authority 100%
It seems to me that you are generally the right ideas and what Steitless is, and what is Stateful, and where and what is stored.
I can decipher a little why Steitles is fashionable.
case – horizontal scaling.
Kogad you have a million clients, and all of them are unable to buy something – then one web server does not cope. They put the “battery” of web servers, and in front of them – the so-called “load distributor”, which will “throw” a user connector to a particular server. Or round Robin (roughly speaking, in turn), or the server currently downloaded at the moment.
But the trouble. At the same time, the same user with a query “of something” from the server can fall on different servers. And he would have to or how to “carry the” session or … or to store everything in himself, and each time to transfer to the server.
The second cause of the stepslees is simplicity of testing. You see, a condition is such a thing that is difficult to reproduce during automated tests. And if all the “state” is a pre-aged structure (for example, JSON with certain fields, everything is known about the value of the cat) – then the task becomes much easier.
Now – you have arguments in favor of the stepleles.
and we left one thing: to reconcile these two beautiful world.
make it easy.
Firstly, in many server flooders (and I say “Fremvorka”, including here as pure PHP, and something inaccier), it is possible to storage session to redis – well, in short, in the database, only in very simple , very fast and most likely lying right in memory.
Then you can not “drive” there and here the whole state – you can drive only the identifier of the session. Then the node, which “fell” the client request, quickly “raise” a session of radishes, and then, as if nothing had happened to you. And then go to another customer, retaining your session in the database.
And finally, keep the “basket” on the client with the modern development of JS and in general, only everything is garbage. In fact, you just send the same JSON chick every time you do something on the site. And in this JSON-Chika described all-all-all. Added goods – changed JSON. Removed – changed again. Asked a discount – this fact is reflected in JSON. That is, there is mutually – the one-ban match “What I see on the screen is described in the state.”
Well, hence you a straight road to the react. The reaction is a thing that is designed to work with the state.
On this I finish my brief answer, and I hope that something could help you