Что такое stateless php
PHP is, historically, stateless.
This is mostly a result of HTTP being stateless as well. Each HTTP request has no knowledge of any request before it.
PHP is much the same. Under «traditional» process models, it rebuilds its entire world on each request! There’s no global state.
Language Comparison
In the video, we compare other popular languages and see how its possible to create a global variable that increases in value with each web request. In other words, there’s global state that that you need to worry about.
PHP is different — even global variables are «reset» to their initial value on each request. (This is not to be confused with super globals such as $_GET , $_POST , $_SERVER , and so on).
Pros and Cons
This makes PHP much easier to use — the mental model of what your code is doing is much simpler when there’s no state that might be accidentally saved between web requests.
However it also means we need to reload a lot of code on each web request. This is alleviated by PHP’s opcache, but it’s still not as efficient as having the framework/code loaded already when accepting a new web request.
Additionally, PHP can’t make use of things like connection pooling — each web request instead needs to make a whole new connection to databases, caches, and other external services.
This, luckily, is mostly just fine — PHP is still fast!
Newer PHP models
There are newer ways to run PHP — using Swoole or RoadRunner, for example, we can run PHP as a long-running process. This behaves more like other programming languages where we need to worry about global state, but we get the benefit of not having to reload your code/framework on each request.
Laravel has made using this simple via Laravel Octane. However it’s still not the mainstream way to run PHP! Given how large PHP is, I’m not sure it ever will be. It’s good, but not a silver bullet — everything is a tradeoff.
Что такое stateless в http api?
Разрабатываю апи сервис(для личных нужд), возник вопрос на который я не могу найти ответ.
Что такое НА САМОМ деле стейтлесс апи. По определению понятно что для формирования ответа в запросе должны быть все данные. Но ХТТП само по себе стейтлес.
На реальном примере:
Клиент передал логин/пароль/фото_кошки на /api/auth и получил в ответ некий токен с которым он может выполнять запросы. Пока все отлично и красиво.
Но вот клиент прислал запрос, в нем есть токен.
Как этот токен проверять? Хранить гдето в кеше token = user_id? Разве это не стейт? А если нет то чем это отличается о тойже сессии? А от куки?
- Вопрос задан более трёх лет назад
- 2320 просмотров
Комментировать
Решения вопроса 0
Ответы на вопрос 3
Senior Junior Roo
HTTP — это протокол передачи данных. API, Stateless, etc — это не его уровень.
Вы, видимо, имеете ввиду REST.
В википедии ровно по вашему вопросу есть описание: https://ru.wikipedia.org/wiki/REST#2._%D0%9E%D1%82.
Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
Для правильного вопроса надо знать половину ответа
Как этот токен проверять? Хранить гдето в кеше token = user_id?
Токен можно сделать самодостаточным. Например JWT содержит заголовок (тип токена, алгоритм подписи), полезную нагрузку (id пользователя, его права, служебную информацию) и подпись.
При выдаче токена сервер рассчитывает подпись для первых двух частей, шифрует её своим ключом и прикрепляет её к токену.
При получении токена сервер снова рассчитывает подпись для первых двух частей и сверяет её с расшифрованной подписью из токена. Если подписи совпадают, то можно доверять данным из полезной нагрузки.
При использовании асимметричного шифрования токен может выдаваться на одном сервере с шифрованием закрытым ключом, а проверяться на другом сервере с использованием парного открытого ключа.
Ответ написан более трёх лет назад
SONce @SONce Автор вопроса
ну про жвт понятно, хотя тоже к нему есть несколько вопросов.
А если у нас не жвт? Если например oauth аццес_токен в нем ведь при каждом запросе проверять придеться
SONce, OAuth нужен для другого. Он позволяет пользователю передать вашему серверу права на выполнение некоторых действий на другом сервере от лица данного пользователя не передавая при этом логин и пароль.
АФАИК, для аутентификация пользователя при работе непосредственно с вашим сервером OAuth не подходит. Хотя некоторые сервисы и позволяют запросить данные о пользователе после получения токена OAuth, к стандарту это не относится и реализация зависит от конкретного сервиса.
Сергей delphinpro @delphinpro
frontend developer
Stateless нужно понимать ровно так, как оно звучит — без состояния.
Т.е. сервер вас не помнит, при каждом новом запросе вы должны ему сообщать кто обращается за данными. В обычном случае — это JWT токен. Он содержит информацию о текущем пользователе. Как уже сказал Rsa97 — токен самодостаточен. Как минимум на википедии, как максимум, в куче статей в интернете есть информация, как создается и как валидируется этот токен. Если вы используете какой-либо фреймворк, то у вас уже есть готовые абстракции для обработки токенов или полностью для аутентификации на основе токенов.
Ответ написан более трёх лет назад
SONce @SONce Автор вопроса
С JWT я понял, однако я очень плотно работаю с 10ком разных апи и нигде ЖВТ не встречал, как правило везде обычные токены. Как они это валидируют?
По поводу запросов — http и так сам по себе стейтлесс, что значит «сервер помнит», что такое именно стейт в данном контексте?
Сергей delphinpro @delphinpro
SONce, Это значит что никакая информация о состоянии клиента на сервере не хранится.
Ваш ответ на вопрос
Войдите, чтобы написать ответ
- Python
- +2 ещё
Обход блокировки API openai?
- 1 подписчик
- 18 нояб.
- 207 просмотров
Что такое stateless?
Здравствуйте, не совсем могу понять одну из концепций REST.
«Отсутствие состояния»
У меня в базе данных хранится информация по каждому запросу: имя запроса, ИП пользователя, дата запроса. Если я в сервисе проверяю — делал ли пользователь больше 3 запросов в последнюю минуту, то значит ли это, что я нарушаю принцип Stateless?
- Вопрос задан более двух лет назад
- 421 просмотр
5 комментариев
Простой 5 комментариев
Зачем это в базе хранить? redis на что?
MaMkO @MaMkO Автор вопроса
Михаил, Redis вроде как тоже СУБД, поправьте меня, пожалуйста, если это не так.
Vitsliputsli @Vitsliputsli
MaMkO, если делаете это одним api запросом, то не нарушаете. Если, к примеру, посылаете запрос, что работаете с пользователем таким-то, а потом шлете запрос про действия этого пользователя, подразумевая, что сервер уже знает о каком идет речь, то нарушаете.
Redis тоже СУБД, но к этому вопросу это отношения не имеет никакого.
Владимир Четвериков @Cheverikov_vv
Stateless подразумевает, что между запросами одного пользователя ты не хранишь состояние на сервере (не учитывая данные в базе). Каждый раз необходимые данные должен присылать клиент или они должны храниться в базе. Если у тебя сервис развернут на нескольких нодах, это позволит обрабатывать запрос на любой ноде без дополнительных сложностей с передачей состояния этого клиента между нодами.
Что такое Stateless и Statefull?
И я запутался. Например, в основном рекомендуется делать приложения Stateless. Но как в этой концепции обработать ту же корзину товаров? Потому что хранить её в куках не очень разумно, а если её не хранить в сессии (потому что сессии в stateless исключаются), то что остаётся — хранение в БД?
Я понимаю, что для REST stateless подходит идеально, потому что там единичные запросы и проще не создавать сессию, чем создавать. Ну а как быть с приложениями с UI? Где мне хранить корзину товаров? Может быть понятия stateless и statefull в принципе применимы только к REST API?
Таким образом вопрос у меня в том, что такое stateless и statefull, очень желательно с примерами, что будет считаться stateless, а что нет.
Отслеживать
задан 11 фев 2021 в 20:15
2,086 2 2 золотых знака 13 13 серебряных знаков 46 46 бронзовых знаков
Для решения вашей задачи можно воспользоваться хранением корзины в localStorage для неавторизованного пользователя и в базе данных для авторизованного пользователя. Если вы хотите обеспечить сохранность корзины клиента, вам конечно же стоит писать в базу данных связь с пользователем и выбранным товаром и выводить/изменять/удалять корзину. Хранить в сессии корзину нет смысла, когда есть такие замечательные два варианта.
11 фев 2021 в 21:34
1 ответ 1
Сортировка: Сброс на вариант по умолчанию
Мне кажется, у Вас в общем правильные представления и о том, что такое стейтлесс, и о том, что такое стейтфул, и том, где и что хранится.
Могу немного расшифровать, почему стейтлесс является модным.
Дело — в горизонтальном масштабировании.
Когад у вас миллион клиентов, и все они бесперывно что то покупают — то один веб — сервер не справляется. Ставят целуб «батарею» веб серверов, а перед ними — так называемый «распределитель нагрузки», который будет «кидать» пользовательский коннект на тот или иной сервер. Или раунд-робином (грубо говоря, по очереди), или на наименее загруженный в данный момент сервер.
Но вот беда. При этом один и тот же пользователь при кадом запросе «чего нибудь» с сервера может попадать на разные сервера. И ему пришлось бы или как «таскать за собой» сессию или. или хранить всё у себя, и каждый раз передавать на сервер.
Вторая причина стетлесса — простота тестирования. Понимаете, состояние — это такая штука, которую сложно воспроизвести во время автоматизированных тестов. А если всё «состояние» — это заранее оперделенная структура (например, json с определенными полями, о значении котрых ВСЕ известно) — то задача становится гораздо проще.
Теперь — у вас есть аргументы в пользу стетлесса.
И нам осталось одно: помирить эти два прекрасных мира.
Сделать это нетрудно.
Во первых, во многих серверных фремворках (и я говорю «фремворки», включая сюда как чистый PHP, так и что то понавороченее), есть возможность storage session to redis — ну, короче, в базе данных, только в очень простой, очень быстрой и, скорее всего, лежащей прямо в памяти.
Тогда можно не «гонять» туда-сюда весь стейт — можно гонять только идентификатор сессии. Тогда та нода, на которую «упал» клиентский запрос, быстренько «поднимет» сессию из редиса, и потом как ни в чем не бывало ответит Вам. А потом пойдет отвечать другому клиенту, сохранив Вашу сессию в базе.
Ну и наконец, хранить «корзину» на клиенте при современном развитии JS и вообще всего-всего — это фигня-вопрос. Фактически, Вам достаточно посылать тот же самый json-чик каждый раз, когда Вы что то делаете на сайте. И в это json-чике описано все-все-все. Добавили товар — изменился json. Удалили — опять изменился. Попросили скидку — этот факт отражен в Json’е. То есть, есть взаимно — однозанчное соответствие «что вижу на экране — то описано в состоянии».
Ну, а отсюда Вам прямая дорога в реакт. Реакт — это штука, которая предназначена для работы с состоянием.
На этом я заканчиваю свой краткий ответ, и надеюсь, что чем то смог Вам помочь