Я пытаюсь понятьtoken-based authentication в эти дни, который претендует наstateless authentication метод. И я встретил концепциюstateless web application.

Ниже приведены некоторые темы, о которых я читал:

Используйте Spring MVC для разработки веб-приложений без сохранения состояния (пока нет ответа)Springless MVC без гражданстваКак сделать Java-приложение полностью без сохранения состоянияКак мне сделать свое веб-приложение не имеющим состояния, но при этом сделать что-то полезное?

Сначала я был в восторге от этой идеи. Но все больше и больше я думаюstateless этоpseudo-proposition.

Например, предположим, что мы используем клиентский токен для аутентификации, как мы можем сделать статистику по онлайн-пользователям (предположим, что нет журнала)? Должны ли мы хранить токен в БД? Разве это не означает, что мы храним информацию о состоянии на сервере? И даже более того, простая информация о пользователе, такая как имя, возраст и т. Д. В БД, также является некоторой информацией о состоянии?

Я думаю, что реальный вопрос здесь не в том, чтобы сделать веб-приложение не имеющим состояния, ночтобы веб-приложение правильно обрабатывало информацию о состоянии, чтобы оно не подвергало опасности масштабируемость.

Это зависит от того, как интерпретировать словоstateless:

Веб-приложение не имеет состояния.Или веб-приложение не хранит состояниесам.

Я предпочитаю 2, потому что всегда могут быть некоторыеinevitable global state (цитата из комментария @ deceze к его ответу). И независимо от того, сохраняем ли мы информацию о состоянии в виде веб-хранилища HTML 5, или заголовка HTTP, или скрытых полей формы, или Cookie, это состояние все еще существует. Только то, что он хранится где-то, кроме как на сервере.

Я что-то упустил? Кто-нибудь может пролить свет на это, чтобы я мог освободиться от этой умственной борьбы?

ДОБАВИТЬ 1

Просто прочитайте о книгеВеб-сервисы RESTful отLeonard Richardson, В главе 4, в конце разделаStatelessnessэто классифицирует государство вApplication State а такжеResource State, Таким образом, обычная информация пользователя и данные, которые я упоминал ранее, такие как изображения и т. Д., Могут быть классифицированы какResource State, И чтоstateless относится кApplication State, Таким образом, он не нарушает код хранения без сохранения состоянияresource state на сервере.

Но в книге также упоминается сценарий, в которомan application key is used to restrict how many times a user can invoke a web service. Он признает, что такая информация не может быть сохранена на стороне клиента. А необходимость хранить его на стороне сервера нарушает код отсутствия состояний и создает проблему соответствия сеансов.Он утверждает, что без сохранения состояния можно избежать проблемы схожести сеанса, но не объясняет как. Я действительно не понимаю, как лица без гражданства могут справиться с этим сценарием. Кто-нибудь может пролить немного света здесь?