Как написано в статье, это "правило" является полной ерундой . Автор чертовски $_SESSION, но все в порядке с cookie-файлами, хранящими аутентификационную информацию. Он продолжает говорить:
В случае, если вам нужно больше, чем просто файл cookie, запаситесь данными для хранения их в центральной базе данных с аутентификацией, которая все еще находится в файле cookie.
В чем разница между хранением данных в сеансе с токеном в cookie и хранением данных в базе данных с аутентификацией в cookie? Нет никакой разницы, кроме того, что при использовании токена вы не передаете данные аутентификации, возможно, в открытом виде, при каждом запросе.
Нет разницы между передачей дополнительной информации с каждым запросом и передачей токена, который представляет дополнительные данные, но должен быть разрешен через сеанс на сервере. Это просто вопрос безопасности и практичности.
Часто аргументом является то, что сервер должен быть "не сохраняющим состояние". Так как RESTfulness относится к протоколу HTTP, «отсутствие состояния» не означает «сервер не хранит любое состояние». Отсутствие состояния с точки зрения протокола означает, что я могу делать любое количество запросов в произвольном порядке, и я получаю один и тот же ресурс для того же запроса.
GET /index.html
POST /someaction
GET /index.html -> should return the same *resource* as before
Сравните это с реальным протоколом сохранения состояния, таким как FTP:
LS -> gets list of files in current directory
CD /dir -> changes directory, i.e. changes state
LS -> same command gets list of files for a different directory
Это реальная разница между протоколом RESTful и протоколом сохранения состояния. Хранит ли сервер какие-либо данные, относящиеся к пользователю, или нет, это полностью деталь реализации сервера и не имеет ничего общего с RESTfulness. Если сервер возвращает тот же ресурс, что и ответ на точно такой же запрос, независимо от того, какие другие типы запросов были сделаны между ними, он остается без состояния и, следовательно, RESTful.
Это не имеет ничего общего с аутентификацией или хранением дополнительных данных, а также не исключает возможности истечения срока действия запросов или URL-адресов.
Если срок действия URL / запросов do истекает, есть специальный способ справиться с этим с помощью HTTP: отвечать соответствующими кодами состояния. Если пользователь отправляет запрос с просроченным токеном / логином, сервер не должен ответить с экраном входа по запрошенному URL . Это нарушило бы RESTfulness.
не RESTful:
GET /restricted/page
200 OK
Please log in here:
Name: _____
Password: _____
----------------------
POST /restricted/page
[name, password]
200 OK
Content of restricted page.
----------------------
GET /restricted/page
200 OK
Content of restricted page.
RESTful:
GET /restricted/page
401 Unauthorized
* * Или тысяча сорок-девять
GET /restricted/page
307 Temporary Redirect
Location: /login
----------------------
GET /login
200 OK
----------------------
POST /login
[name, password]
307 Temporary Redirect
Location: /restricted/page
----------------------
GET /restricted/page
200 OK
Это не «заменяет» ресурс /restricted/page, как это сделал бы плохой пример, сохраняя сервер RESTful. надлежащим образом сигнализирует клиенту, что запрос действителен, только не прямо сейчас . Обратите внимание, что всегда используется термин resource , а не response . Сервер может нормально отвечать по-другому, но нельзя предлагать другой ресурс (content *) по тому же URL. Если бы это было так, клиент также должен был бы отслеживать текущее состояние сеанса (например, FTP), чтобы иметь возможность сказать, что происходит. Безгражданство - это гораздо больше о клиенте, не имеющем состояния, чем о сервере. Это не мешает серверу отслеживать, что делает клиент.
*) Обратите внимание, что content не эквивалентно resource . Можно изменить и обновить содержимое ресурса.
Также обратите внимание, что являются вескими причинами против использования $_SESSION, в особенности масштабируемость на нескольких серверах Сохранение сервера RESTful - это , а не действительная причина. Если вам нужно какое-либо состояние, например, срок действия логинов или корзина покупок, вам нужно где-то отслеживать эту информацию. Сеанс сервера является таким же допустимым местом, как и файл cookie, и во многих случаях является лучшим выбором. Будет ли этот сеанс реализован с использованием $_SESSION или базы данных, или пера, и бумаги - это детали реализации.