Поддержание потока транзакций с помощью Jersey REST

Question

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

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

Я надеюсь получить некоторые указания о том, как лучше всего выполнить приведенные ниже шаги в наших классах Java.

1) Браузер инициирует запрос на открытие нового сеанса клиента. Служба POST сеанса используется для генерации нового идентификатора сеанса. Идентификатор сеанса отправляется обратно в ответ на браузер.

Вопрос ->Каков наилучший способ поддерживать это значение идентификатора сеанса в моих классах Java?

2) Клиентские операции выполняются в рамках сессии. Для каждой транзакции обработанная транзакция POST-служба используется для сохранения информации о транзакции вместе с информацией о сеансе.

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

3) Клиент может выполнить еще несколько транзакций, и каждая выполненная транзакция будет запросом POST транзакции, который должен был бы ассоциироваться с идентификатором сеанса, созданным ранее. Каждая дополнительная транзакция должна быть связана с идентификатором сеанса на стороне службы, так что когда я делаю GET на идентификаторе сеанса, мне нужно получить сведения о сеансе вместе со всеми транзакциями в этом сеансе.

4) Наконец, когда сеанс завершен, информация из сеанса и полезная нагрузка сеанса на стороне обслуживания (вместе со всеми транзакциями) будут переданы БД.

Я просто ищу некоторые общие рекомендации о том, как лучше всего это сделать, используя классы Java и Джерси REST.

Любые указатели будут оценены по достоинству.

Thanks Ali.

Answer 1

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

Прежде всего помните, что REST является апатридом - это означает, что сеанса нет и клиент должен быть авторизовано с с запросом. Это отдельная тема, но хороший метод авторизации в REST - JSON Web Token.

Во-вторых, REST - это существительные - не глаголы. Таким образом, вам следует избегать URL-адресов, таких как /session/{sessionId}/close/, но попытайтесь смоделировать домен с помощью существительных и HTTP-операций по умолчанию: POST (создать), PUT (обновление), GET (read), DELETE (удалить).

Я думаю, что сессия и транзакции - это просто абстракция. Я покажу вам, как смоделировать ее на примере корзины покупок. Во всех примерах, которые я удвоила URL - with /users/{userId}/ префикс, чтобы показать, вы можете обратиться к ресурсам по-разному

1. Создать корзина (создание сеанса)

   POST /shopping-carts/ 
   POST /users/{userID}/shopping-carts/ 
   

   Запрос: может быть пустым или должен содержать необходимые сведения о телеге

   Ответ: должен содержать вновь созданный shoppingCartID

   { 
       "shoppingCartID": "1qaz2wsx" 
       ... 
   } 
   

2. Добавить товар в корзину (создать транзакцию)

   POST /shopping-carts/{shoppingCartID}/items/ 
   POST /users/{userID}/shopping-carts/{shoppingCartID}/items/ 
   

   Запрос: содержит информацию о качестве добавляемого элемента

   Ответ: возвращает вновь добавленный элемент вместе с его уникальным ID

3. Оплатите корзины (совершать сделки)

   POST /payments/ 
   POST /users/{userID}/payments/ 
   

   запрос: должен содержать shoppingCartID

   { 
       "shoppingCartID": "1qaz2wsx" 
       ... 
   } 
   

   Ответ: Содержит подробную информацию о недавно созданной оплате

   { 
       "paymentId": "3edc4rfv" 
       ... 
   } 
   

Я знаю, что это общий ответ, но это трудно дать точный ответ на такой широкий вопрос.

EDIT (после обсуждения в комментариях)

На мой взгляд БД следует использовать, чтобы сохранить транзакции во временную таблицу, прежде чем они будут утверждены. Даже если вы не хотите использовать БД, рекомендуется любое другое постоянное хранилище - представьте, что может произойти в случае перезапуска сервера, когда транзакции не будут одобрены, вы потеряете все данные.

Варианты Я вижу:

• В памяти. Вы можете написать простую структуру в памяти с синхронизированным доступом. В самом простом случае достаточно простого старого HashMap. Имейте в виду, что хранение данных таким образом является рискованным, его можно стереть очень легко.
• Используйте файловую систему. Если вы не хотите использовать БД, вы можете использовать файловую систему, чтобы хранить данные транзакций, пока они не зарегистрированы. После добавления новой транзакции она записывается в файл. В файле фиксации считывается и все транзакции сохраняются в БД. Здесь также очень важен синхронизированный доступ к файлам.Когда дело доходит до формата данных, вы можете использовать JSON, XML, даже обычную серию Java.
• Последней идеей, которая приходит мне на ум, является использование DB в памяти, например, Redis. Данные будут стерты при перезагрузке системы, поэтому их можно будет с меньшей вероятностью удалить, однако это, на мой взгляд, небезопасно. Такая БД намного проще использовать/поддерживать, чем традиционная БД.

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