Идемпотентность REST API

Question

У меня есть приложение с интеграцией sping-data-jpa.В моем классе репозитория у меня есть метод:

@Transactional
@Modifying
@Query(value = "some insert query", nativeQuery = true)
void create(.....);

Этот метод вставляет данные в базу данных.

Этот метод вызывается из POST REST API.В настоящее время, если данные уже присутствуют в БД, API возвращает ответ об ошибке.Теперь клиент этого API хочет выполнять одну и ту же операцию с одними и теми же данными несколько раз и хочет, чтобы ответ был успешным, поэтому мне нужно сделать этот API идеопотентным.Как я могу сделать этот API как Idempotent?Будет ли работать изменение метода с POST на PUT или нужно добавить больше изменений вместе с изменением метода?Что за изменения?

Answer 1

По определению, POST не является идемпотентным методом, поэтому нет смысла возвращать Успех, когда ресурс уже создан.

Что вы можете сделать, это переместить вашу POST логику в PUT метод и реализовать что-то похожее на общеизвестный как «Создать или обновить».Так как PUT идемпотент, здесь кажется логичным выбор как для создания, так и для обновления.

Вот некоторая дополнительная информация для идемпотентных методов:

• https://tools.ietf.org/html/rfc7231#section-4.2.2
• http://restcookbook.com/HTTP%20Methods/idempotency/

Answer 2

Будет ли работать изменение метода с POST на PUT или нужно будет добавить больше изменений вместе с изменением метода?

Нет, важно то, что "idempotent" делает обработчик запросаправильная вещь.Ничего волшебного не происходит, если вы меняете метод, который вы используете.

Хорошая новость заключается в том, что технически ваша реализация уже идемпотентна (по крайней мере, из описания).В RFC 7231 есть определение, которое вы должны рассмотреть.Важным элементом является то, что получение двух копий запроса оставляет ресурс в том же состоянии, что и получение одной копии запроса.

Таким образом, «все», что вам нужно сделать, это выяснить, какзнать, что ошибка связана с тем, что запись уже находится в базе данных (а не по какой-то другой причине), а затем замените отправляемую в данный момент ошибку ответом, похожим на сообщение об успешном выполнении.

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

(Сравните это с GET - ваш браузер знает, что запросы GET являются идемпотентными; браузер нене нужно спрашивать человека, можно ли повторить запрос, потому что сервер уже пообещал обработать запрос безопасно.идемпотентный обмен сообщениями (хотя некоторые другие методы могут быть лучшим выбором, если другая семантика совпадает).

Answer 3

POST не имеет понятия идемпотентности .

Методы также могут иметь свойство "идемпотентности" в том смысле, что (кроме
из-за ошибок или проблем с истечением срока действия)побочные эффекты от N> 0 идентичных
запросов такие же, как и для одного запроса.Методы GET, HEAD,
PUT и DELETE разделяют это свойство.Кроме того, методы OPTIONS и
TRACE НЕ ДОЛЖНЫ иметь побочных эффектов и поэтому являются идемпотентными по своей природе.

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