Как обрабатывать последовательные запросы на перевод денег (в секундах / мс) от клиента на уровне REST API

Question

Я пытаюсь написать REST API для банковского приложения.Я использовал SpringMVC, JDBCTemplate для разработки того же. Я отправляю запрос POST с полезной нагрузкой (fromAccountID, toAccountID, amount) в формате JSON.

Если пользователь по ошибке нажимает на кнопку передачи более одного раза (при условии, что это не обрабатывается в пользовательском интерфейсе) и такая же полезная нагрузка отправляется в API как JSON:

1.) Какчтобы убедиться, что обрабатывается только первый запрос?

2.) Как следует обрабатывать остальные повторяющиеся запросы?

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

4.) Как этот сценарий обрабатывается в банковских приложениях в реальном времени?

Я на начальной стадии обучения написанию API-интерфейсов REST, поэтому любые рекомендации по этому поводубудет полезен случай использования.

Answer 1

RESTful способ решить эту проблему - убедиться, что вы используете только идемпотентные запросы.Идемпотентный запрос более или менее определяется следующим образом:

Состояние на сервере после выполнения запроса один раз будет идентично выполнению того же запроса n раз.

ТамВот несколько HTTP-запросов, которые явно определены как идемпотентные, например:

• PUT
• DELETE
• GET

Так что еслиВы можете спроектировать свое приложение таким образом, чтобы использовать PUT для создания новых переводов, а PUT реализован правильно, получение одного и того же запроса n раз не должно иметь побочных эффектов.

Это не такЭто всегда особенно просто, потому что, если вы «создаете» новый ресурс передачи с PUT, это означает, что клиент должен определить, каким будет новый URI передачи.Например, клиент может сгенерировать UUID для URL.

Я думаю, что этот подход является наиболее желательным.Вы можете автоматически заставить сервер выдавать ошибку, если ресурс передачи уже существует, включая заголовок If-None-Match: *.Если вы используете этот заголовок, вы можете вернуть 412 Precondition Failed, если ресурс уже существует.

Я предполагаю, что ваша интуиция заключалась в том, чтобы использовать POST для создания новых переводов, но идея в том, что POST = create & PUT = updateневерен.PUT следует использовать как для создания, так и для обновления ресурсов, , если путь может быть известен клиенту.

Answer 2

Насколько я понимаю, пожалуйста, найдите ниже комментарии для того же самого;

В этом сценарии нам нужно применить проверку на самом интерфейсе.

Если запрос приходит от кнопки, то онможет быть легко обработано с помощью события onclick и простого диалогового окна подтверждения

Если существует требование НЕ запрашивать подтверждение пользователя и отправлять запрос в API для обработки платежа, тогда вы можете где-то сохранить предыдущий запрос (массив или сеанс) иесли совпадения, то спросите у пользователя подтверждение.

Вот как вы можете решить эту проблему.