Как обрабатывать последовательные запросы денежных переводов (в пределах сек / мс) от клиента на уровне REST API
Я пытаюсь написать REST API для передачи банковских приложений. Я использовал SpringMVC, JDBCTemplate для разработки того же самого. Я отправляю POST-запрос с полезной нагрузкой (fromAccountID, toAccountID, amount) в формате JSON.
Если пользователь по ошибке нажимает кнопку передачи более одного раза (при условии, что это не обрабатывается в пользовательском интерфейсе) и та же полезная нагрузка отправляется в API как JSON:
1.) Как обеспечить обработку только первого запроса?
2.) Как следует обрабатывать остальные повторяющиеся запросы?
3.) Пользователь действительно мог попытаться снова перевести ту же сумму на ту же учетную запись назначения, поэтому дубликаты должны обрабатываться, скажем, всего пару минут. Как этого добиться?
4.) Как этот сценарий обрабатывается в банковских приложениях в реальном времени?
Я нахожусь на начальном этапе обучения написанию REST API, поэтому любые рекомендации по этому варианту использования будут оценены.
Ответы 2
Насколько я понимаю, вы можете найти ниже комментарии к тому же самому;
В этом сценарии нам нужно применить проверку к самому интерфейсу.
Если запрос исходит от кнопки, его можно легко обработать с помощью события onclick и простого диалогового окна подтверждения.
Если есть требование НЕ запрашивать подтверждение пользователя и отправлять запрос в API для обработки платежа, тогда вы можете где-нибудь сохранить предыдущий запрос (массив или сеанс), и если он совпадает, запросить подтверждение пользователя.
Вот как можно решить эту проблему.
RESTful способ решить эту проблему - убедиться, что вы используете только идемпотентные запросы. Идемпотентный запрос более или менее определяется как:
The state on the server after doing an request once will be identical to doing same the request n times.
Есть несколько HTTP-запросов, которые явно определены как идемпотентные, например:
- ПОЛОЖИЛ
- УДАЛЯТЬ
- ПОЛУЧАТЬ
Итак, если вы можете разработать свое приложение таким образом, чтобы вы использовали PUT для создания новых передач, а PUT реализован правильно, получение одного и того же запроса n раз не должно иметь побочных эффектов.
Это не всегда очень просто, потому что, если вы «создаете» новый ресурс передачи с помощью PUT, подразумевается, что клиент должен определить, каким будет новый URI передачи. Например, клиент может сгенерировать UUID для URL-адреса.
Я считаю, что такой подход наиболее желателен. Если ресурс передачи уже существует, сервер может автоматически выдавать ошибку, включив заголовок If-None-Match: *. Если вы используете этот заголовок, вы можете вернуть 412 Precondition Failed - это уже существующий ресурс.
Я предполагаю, что ваша интуиция должна была использовать POST для создания новых переводов, но идея о том, что POST = create & PUT = update неверна. PUT следует использовать как для создания, так и для обновления ресурсов, если путь может быть известен клиенту.
Найдите "POST-redirect-GET"