Что такое Stateless и Statefull?
1,00
р.
Я не могу найти хорошего определения для этих понятий. Моё собственное понимание:
Stateless - состояние не хранится на сервере. Т.е. в каждом новом запросе мы передаём свой логин/пароль (если в приложении есть авторизация), а также данные для запроса.
Statefull - на сервере открывается сессия. Благодаря этому нам не надо постоянно отправлять на сервер логин/пароль. И не надо отсылать какие-то дополнительные данные (например выбранную локализацию), они хранятся в сессии.
И ещё я выделил три уровня того, где могут храниться временные данные (например, корзина товаров):
Куки Сессия База данных
И я запутался. Например, в основном рекомендуется делать приложения Stateless. Но как в этой концепции обработать ту же корзину товаров? Потому что хранить её в куках не очень разумно, а если её не хранить в сессии (потому что сессии в stateless исключаются), то что остаётся - хранение в БД?
Я понимаю, что для REST stateless подходит идеально, потому что там единичные запросы и проще не создавать сессию, чем создавать. Ну а как быть с приложениями с UI? Где мне хранить корзину товаров? Может быть понятия stateless и statefull в принципе применимы только к REST API?
Таким образом вопрос у меня в том, что такое stateless и statefull, очень желательно с примерами, что будет считаться stateless, а что нет.
Ответ
Мне кажется, у Вас в общем правильные представления и о том, что такое стейтлесс, и о том, что такое стейтфул, и том, где и что хранится.
Могу немного расшифровать, почему стейтлесс является модным.
Дело - в горизонтальном масштабировании.
Когад у вас миллион клиентов, и все они бесперывно что то покупают - то один веб - сервер не справляется. Ставят целуб "батарею" веб серверов, а перед ними - так называемый "распределитель нагрузки", который будет "кидать" пользовательский коннект на тот или иной сервер. Или раунд-робином (грубо говоря, по очереди), или на наименее загруженный в данный момент сервер.
Но вот беда. При этом один и тот же пользователь при кадом запросе "чего нибудь" с сервера может попадать на разные сервера. И ему пришлось бы или как "таскать за собой" сессию или... или хранить всё у себя, и каждый раз передавать на сервер.
Вторая причина стетлесса - простота тестирования. Понимаете, состояние - это такая штука, которую сложно воспроизвести во время автоматизированных тестов. А если всё "состояние" - это заранее оперделенная структура (например, json с определенными полями, о значении котрых ВСЕ известно) - то задача становится гораздо проще.
Теперь - у вас есть аргументы в пользу стетлесса.
И нам осталось одно: помирить эти два прекрасных мира.
Сделать это нетрудно.
Во первых, во многих серверных фремворках (и я говорю "фремворки", включая сюда как чистый PHP, так и что то понавороченее), есть возможность storage session to redis - ну, короче, в базе данных, только в очень простой, очень быстрой и, скорее всего, лежащей прямо в памяти.
Тогда можно не "гонять" туда-сюда весь стейт - можно гонять только идентификатор сессии. Тогда та нода, на которую "упал" клиентский запрос, быстренько "поднимет" сессию из редиса, и потом как ни в чем не бывало ответит Вам. А потом пойдет отвечать другому клиенту, сохранив Вашу сессию в базе.
Ну и наконец, хранить "корзину" на клиенте при современном развитии JS и вообще всего-всего - это фигня-вопрос. Фактически, Вам достаточно посылать тот же самый json-чик каждый раз, когда Вы что то делаете на сайте. И в это json-чике описано все-все-все. Добавили товар - изменился json. Удалили - опять изменился. Попросили скидку - этот факт отражен в Json'е. То есть, есть взаимно - однозанчное соответствие "что вижу на экране - то описано в состоянии".
Ну, а отсюда Вам прямая дорога в реакт. Реакт - это штука, которая предназначена для работы с состоянием.
На этом я заканчиваю свой краткий ответ, и надеюсь, что чем то смог Вам помочь
Stateless - состояние не хранится на сервере. Т.е. в каждом новом запросе мы передаём свой логин/пароль (если в приложении есть авторизация), а также данные для запроса.
Statefull - на сервере открывается сессия. Благодаря этому нам не надо постоянно отправлять на сервер логин/пароль. И не надо отсылать какие-то дополнительные данные (например выбранную локализацию), они хранятся в сессии.
И ещё я выделил три уровня того, где могут храниться временные данные (например, корзина товаров):
Куки Сессия База данных
И я запутался. Например, в основном рекомендуется делать приложения Stateless. Но как в этой концепции обработать ту же корзину товаров? Потому что хранить её в куках не очень разумно, а если её не хранить в сессии (потому что сессии в stateless исключаются), то что остаётся - хранение в БД?
Я понимаю, что для REST stateless подходит идеально, потому что там единичные запросы и проще не создавать сессию, чем создавать. Ну а как быть с приложениями с UI? Где мне хранить корзину товаров? Может быть понятия stateless и statefull в принципе применимы только к REST API?
Таким образом вопрос у меня в том, что такое stateless и statefull, очень желательно с примерами, что будет считаться stateless, а что нет.
Ответ
Мне кажется, у Вас в общем правильные представления и о том, что такое стейтлесс, и о том, что такое стейтфул, и том, где и что хранится.
Могу немного расшифровать, почему стейтлесс является модным.
Дело - в горизонтальном масштабировании.
Когад у вас миллион клиентов, и все они бесперывно что то покупают - то один веб - сервер не справляется. Ставят целуб "батарею" веб серверов, а перед ними - так называемый "распределитель нагрузки", который будет "кидать" пользовательский коннект на тот или иной сервер. Или раунд-робином (грубо говоря, по очереди), или на наименее загруженный в данный момент сервер.
Но вот беда. При этом один и тот же пользователь при кадом запросе "чего нибудь" с сервера может попадать на разные сервера. И ему пришлось бы или как "таскать за собой" сессию или... или хранить всё у себя, и каждый раз передавать на сервер.
Вторая причина стетлесса - простота тестирования. Понимаете, состояние - это такая штука, которую сложно воспроизвести во время автоматизированных тестов. А если всё "состояние" - это заранее оперделенная структура (например, json с определенными полями, о значении котрых ВСЕ известно) - то задача становится гораздо проще.
Теперь - у вас есть аргументы в пользу стетлесса.
И нам осталось одно: помирить эти два прекрасных мира.
Сделать это нетрудно.
Во первых, во многих серверных фремворках (и я говорю "фремворки", включая сюда как чистый PHP, так и что то понавороченее), есть возможность storage session to redis - ну, короче, в базе данных, только в очень простой, очень быстрой и, скорее всего, лежащей прямо в памяти.
Тогда можно не "гонять" туда-сюда весь стейт - можно гонять только идентификатор сессии. Тогда та нода, на которую "упал" клиентский запрос, быстренько "поднимет" сессию из редиса, и потом как ни в чем не бывало ответит Вам. А потом пойдет отвечать другому клиенту, сохранив Вашу сессию в базе.
Ну и наконец, хранить "корзину" на клиенте при современном развитии JS и вообще всего-всего - это фигня-вопрос. Фактически, Вам достаточно посылать тот же самый json-чик каждый раз, когда Вы что то делаете на сайте. И в это json-чике описано все-все-все. Добавили товар - изменился json. Удалили - опять изменился. Попросили скидку - этот факт отражен в Json'е. То есть, есть взаимно - однозанчное соответствие "что вижу на экране - то описано в состоянии".
Ну, а отсюда Вам прямая дорога в реакт. Реакт - это штука, которая предназначена для работы с состоянием.
На этом я заканчиваю свой краткий ответ, и надеюсь, что чем то смог Вам помочь
