Отслеживание после кнопки назад

Question

Я хочу написать систему заказов веб-приложений с использованием методологии REST впервые. Я понимаю концепцию «идентификатора сообщения», когда вещи публикуются на странице, но этот сценарий подходит. Когда пользователь отправляет сообщение в веб-приложение, вы можете отслеживать его состояние с помощью идентификатора, прикрепленного к URI, но что произойдет, если он нажмет кнопку «Назад» браузера в точке входа приложения, когда у него не будет идентификатора ? Затем они теряют свое состояние в транзакции.

Я знаю, что вы всегда можете дать им печенье, но вы не сможете этого сделать, если у них отключены файлы cookie и, в худшем случае, здесь также отключен JavaScript.

Теперь я понимаю, что ответом может быть «Да, вот что будет», это конец истории, и я могу с этим смириться, но, будучи новичком в этом, я что-то упускаю?

Answer 1

REST на самом деле не имеет состояний на стороне сервера; Вы просто указываете на ресурсы. Пользовательские сессии не отслеживаются; вместо этого куки используются для отслеживания состояния приложения. Однако, если вы обнаружите, что вам действительно нужно состояние сеанса, вам придется прервать REST и отследить его на сервере.

Несколько вещей для рассмотрения:

• У скольких из ваших пользователей куки-файлы отключены? Кто из вас знает, как это сделать?
• Неужели у ваших пользователей JS выключен? Если так, как вы будете выполнять PUT (редактировать) и DELETE (удалять) без AJAX?

РЕДАКТИРОВАТЬ: Поскольку вы не хотите принудительно использовать куки и JavaScript, у вас не может быть действительно RESTful системы. Но вы можете несколько подделать это. Вам нужно будет отслеживать пользовательский сервер. Вы можете сделать это с помощью объекта сеанса, который находится в выбранном вами языке / структуре или добавив поле в базу данных для всего, что вы хотите знать. Конечно, когда пользователь нажимает кнопку «Назад», он, вероятно, будет переходить на кэшированную страницу. Если это не так, вам нужно изменить заголовки, чтобы запретить кэширование. В основном, это становится более сложным, если вы не используете куки, но не является неуправляемым.

Как насчет отсутствующих методов HTTP PUT и DELETE? Вы можете подделать те с POST и скрытым параметром, указывающим, делаете ли вы что-то новое, редактируете или удаляете запись. GET не должен действительно меняться.

Answer 2

Ответ заключается в том, что ваше приложение (в сценарии REST) ​​просто не отслеживает происходящее. Все состояния управляются клиентом, а переходы между состояниями осуществляются посредством навигации по URI. Часть «Передача состояний» REST относится к переходу клиента к новым URI, которые являются новыми состояниями.

URI, доступ к которому осуществляется с помощью GET, фактически является операцией только для чтения согласно спецификации HTTP и методологии REST. Это означает, что если клиент «резервирует» какой-либо предыдущий URI, «худшее», что происходит, - это когда выполняется еще один GET и загружается больше данных.

Допустим, клиент делает это (используя очень упрощенный псевдо-HTTP) ...

GET //site.com/product/123

При этом извлекается информация (или, возможно, страница) об идентификаторе продукта 123, которая предположительно включает ссылку на URI, который можно использовать для размещения этого товара в корзине покупок пользователя. Таким образом, пользователь решает купить товар. Опять же, это упрощенно, но:

POST //site.com/shoppingcart/ {productid = 123}

Возвращение из этого может быть представлением корзины покупок или ссылкой на добавленный товар (который можно использовать в URI корзины покупок с DELETE для повторного удаления товара), или множеством других вещей (таких как более глубокий XML, описывающий содержимое корзины с другими URI, указывающими на элементы корзины и обратно на исходные продукты). Это все зависит от вас.

Но «состояние» определяется тем, что делает клиент. Он вообще не отслеживается на сервере, хотя вы непременно сохраните копию содержимого его корзины покупок в своей базе данных в течение некоторого периода времени. (Однажды я вернулся на веб-сайт два года спустя, и моя корзина покупок все еще была там ...) Но он должен следить за удостоверением личности. Для вашего серверного приложения это просто еще одна запись, предположительно с истечением срока действия.

Таким образом, вам не нужны файлы cookie, и JavaScript полностью зависит от реализации клиента. Трудно создать достойный REST-клиент без сценария - вы, вероятно, могли бы создать что-то с помощью XSLT и возвращать только XML с сервера, но это, вероятно, более трудная задача, чем кому-либо нужно.

Отправной точкой является по-настоящему понять REST, затем спроектировать систему и построить ее. Это определенно не позволяет строить его на лету, как это делают большинство других систем (правильно или неправильно).

Это отличная статья, которая дает вам довольно «чистый» взгляд на REST, не слишком абстрактно и не увязая в коде:

http://www.infoq.com/articles/subbu-allamaraju-rest

Answer 3

Это правда, что «S» в REST означает «состояние», а «T» - «передача». Но состояние сохраняется на клиенте, а не на сервере. У клиента всегда есть вся необходимая информация, чтобы решить для себя, в каком направлении он хочет изменить состояние.

Как вы описываете, ваша система не спокойна.