В случае сбоя вызова веб-службы REST следует ли использовать очередь сообщений или событий для повторной попытки позже? - PullRequest
Новая
       11

В случае сбоя вызова веб-службы REST следует ли использовать очередь сообщений или событий для повторной попытки позже?

3 голосов
/ 07 декабря 2010

Я создаю веб-сервис с интерфейсом RESTful (назовем его MY_API ). Эта служба использует другой веб-сервис RESTful для обработки определенных аспектов (называя его OTHER_API ). Я хотел бы определить, какие типы рекомендаций следует использовать для обработки сбоев OTHER_API.

Сценарий

Мой пользовательский интерфейс - это одностраничное приложение javascript. Есть несколько довольно сложных действий, которые пользователь может предпринять, которые могут легко занять пользователя одну или две минуты. По завершении они нажимают кнопку SAVE и вызывается MY_API для сохранения данных.

MY_API имеет все необходимое для сохранения информации, предоставленной пользователем. Однако должно быть выполнено действие, которое обрабатывается OTHER_API. Например, OTHER_API может обрабатывать отправку электронных писем. Или, возможно, он обрабатывает добавление позиций в платежную ведомость моего пользователя. В обоих случаях это критические вещи, которые должны быть выполнены, но они не должны происходить прямо сейчас , они просто должны произойти в конечном итоге .

Если произойдет сбой OTHER_API, я не хочу просто сообщать пользователю, что его действие провалилось, поскольку они потратили на это много времени, и это сделает процесс менее оптимальным.

Вопросы

  • Так я должен создать какую-то Очередь сообщений или событий, которая может сохранить эти неудавшиеся REST-запросы в OTHER_API и обработать их позже?
  • Есть ли какие-либо советы или предложения по методам сохранения запросов REST для отложенной обработки?
  • Существует ли рекомендуемое решение для очереди сообщений с открытым исходным кодом, которое будет работать для этого типа сценария с веб-службами REST на основе JSON? Java предпочтительнее, так как мой бэкэнд написан на нем.
  • Есть ли другие методы, которые я должен рассмотреть?

1 Ответ

2 голосов
/ 23 декабря 2010

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

Если вы хотите, чтобы ваш API указывал, что есть аспекты запроса, которые не были выполнены, вы можете использовать HTTP-код ответа HTTP 202 (Accepted).

...