Как принудительно применять «сеансы» в веб-службах RESTful с помощью RESTlet?

#java #web-services #web-applications #rest #restlet

#java #веб-службы #веб-приложения #rest #restlet

Вопрос:

Я новичок в веб-службах RESTful и RESTlet. У нас есть только опыт создания веб-приложений на основе сервлетов (Servlet / JSP на JBoss / Apache). Теперь мы создаем приложение на основе RESTlet, в котором API на стороне сервера будет использоваться двумя типами клиентов — веб-браузером и swing на основе desktop.

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

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

Шаг 1) Клиент отправляет запрос на аутентификацию, сервер проходит аутентификацию, и сервер отвечает OK.

Шаг 2) Клиент отправляет запрос на добавление товара в корзину. Сервер отвечает нормально.

Шаг 3) Клиент отправляет еще один запрос на добавление 2-го товара в карточку покупок. Сервер отвечает нормально.

Обычно в обычном веб-приложении сеанс создается на шаге 1 на сервере, и с этого момента все запросы, относящиеся к этому клиенту, автоматически связываются с одним и тем же сеансом, и мы сохраняем состояние сеанса (в данном случае корзину покупок) в объекте сеанса и извлекаем / обновляем его последующими запросамиот клиента.

Теперь, в приведенном выше сценарии:

1) как нам аутентифицировать и авторизовать клиента на этапах 2 и 3, если на сервере не поддерживается сеанс?

2) нужно ли клиенту отправлять дополнительную информацию с каждым запросом?

3) Как нам получить корзину покупок для конкретного клиента на шаге 3?

4) Нужно ли клиенту отправлять корзину покупок, которая была создана / возвращена сервером на шаге 2, снова на шаге 3?

Очевидно, что это самый простой вариант использования, и поэтому каждый, кто разрабатывает веб-службы RESTful, должен разрабатывать свое приложение, чтобы справиться с этим. Каков наилучший и наиболее распространенный способ управления сеансами, аутентификации, авторизации в веб-службах RESTful с использованием RESTLet? Если нам нужно поддерживать кэш на стороне сервера с данными клиента, то чем это отличается от сервера, поддерживающего сеансы от нашего имени?

Заранее спасибо, глубоко

Ответ №1:

1) как нам аутентифицировать и авторизовать клиента на этапах 2 и 3, если на сервере не поддерживается сеанс?

2) нужно ли клиенту отправлять дополнительную информацию с каждым запросом?

ДА. Вы должны отправлять данные аутентификации / авторизации с каждым запросом. Это то, что помешает серверу «запомнить», кто вы (т. Е. Сервер без состояния, без сеансов)

3) Как нам получить корзину покупок для конкретного клиента на шаге 3?

Давайте зададим другой вопрос: что произойдет, если сервер перезапустится? Вы хотите, чтобы все данные корзины были потеряны? Вероятно, нет. Подразумевается, что вы должны хранить его где-нибудь, чтобы он мог пережить перезапуск. Подразумевается постоянное хранилище. Может быть на сервере или клиенте…

… теперь, что, если ваш клиент перезапустится? Вы можете создать «ресурс» корзины покупок для этого пользователя с помощью запроса POST (когда пользователь добавляет первый элемент) или создать его в момент входа клиента в систему (расточительно). Затем вы продолжаете обновлять корзину покупок с помощью PUT / DELETE и извлекаете ее с помощью GET.

Должно ли это быть в БД? Может быть, зависит от того, хотите ли вы, чтобы это было так. Если он должен быть постоянным, его лучше сохранить, чтобы он мог пережить перезапуск.

Итак, как получить клиентскую корзину покупок? Ну, вы просто отправляете запрос GET для ресурса!!! Вот и все! Первое сообщение создаст ресурс по соответствующему URL, и вы сможете его использовать.

Веб-службы Restful также имеют URL-адреса restful, так что это ключевая часть дизайна.

4) Нужно ли клиенту отправлять корзину покупок, которая была создана / возвращена сервером на шаге 2, снова на шаге 3?

Нет. Как упоминалось выше. Но если вы используете файлы cookie или localStorage или какую-либо другую информацию на стороне клиента, то, возможно, вы это делаете.

Очевидно, что это самый простой вариант использования, и поэтому каждый, кто разрабатывает веб-службы RESTful, должен разрабатывать свое приложение, чтобы справиться с этим. Каков наилучший и наиболее распространенный способ управления сеансами, аутентификации, авторизации в веб-службах RESTful с использованием RESTLet?

ДА. Это просто, но требуется некоторое время, чтобы думать в терминах «ресурсов», а не «сервисов». В restful design все является (или может быть) ресурсом, включая транзакции, корзины покупок и т. Д.,

Однако авторизация / аутентификация являются частью пакета http-запроса и отправляются с каждым запросом. Я предлагаю вам ознакомиться с ними.

Если нам нужно поддерживать кеш на стороне сервера с данными клиента, то чем это отличается от сервера, поддерживающего сеансы от нашего имени?

БОЛЬШАЯ разница! Вы кэшируете для повышения производительности или поддерживаете сеанс? Если система перезагрузится, будет ли ваша система работать без проблем с пустым кэшем? Если да, вы кэшируете для повышения производительности, иначе вы поддерживаете состояние.

Я настоятельно рекомендую вам прочитать RESTful Web Services Ричардсона и Руби, чтобы уточнить вышеупомянутые концепции и получить больше информации о том, как работают restful services designed…it нужно немного привыкнуть.

Комментарии:

1. но почему это плохо, если сервер помнит, кто вы (и только это). если вы не придерживаетесь догматически спецификации REST, вы можете пойти на компромисс и избавить себя от отправки аутентификации при каждом отдельном запросе.

2. Может ли ваш дизайн выдержать перезапуск? Кроме того, всегда есть какая-то проверка, чтобы убедиться, что это один и тот же человек, а не украденный сеанс.