Я застрял в теоретической проблеме с REST.Способ HTTP POST обязательно идемпотент?
Представьте себе простой продукт API. База данных содержит один набор движений, ссылающийся на product, a quantity и status.
У меня есть одно предварительное условие: я не хочу, чтобы пользователи API манипулировали статусом. Значение состояния может быть reserved или confirmed.
Во-первых, я хочу создать бронирование продукта. Вот соответствующий URL путь и метод HTTP, чтобы представить, что:
[POST] /products/{product-id}/reservations
Это создает движение со статусом reserved и возвращает идентификатор созданного движения.
Теперь я хочу, чтобы подтвердить эту оговорку:
[POST] /reservations/{movement-id}/confirmations
В семантическом образом, мне кажется, что я создаю подтвержденное бронирование. Фактически, я просто меняю статус движения.
Итак, 2 вопроса:
- Мой второй POST идемпотентна. Я не смог найти информацию в RFC, но может ли POST быть идемпотентным?
- Вы видите лучший способ представить подтверждение?
Лично я не часто вижу идемпотентные POST-реализации, потому что этот метод не должен использоваться так. Идемпотентный HTTP-метод - это метод HTTP, который можно назвать много раз без разных результатов. Если вы хотите использовать POST-запросы, просто убедитесь, что вызов его несколько раз не изменяет результат или просто использует другой метод, например PUT, чтобы изменять статусы, поскольку он используется для модификаций довольно часто. – Valdas
Вы сказали «не следует». В RFC-терминах это значимое слово. Можете ли вы дать мне ресурс, подтверждающий это? В качестве альтернативы, я не думаю, что идемпотентность касается результатов, но больше о состоянии сервера (новый объект был создан в базе данных, ...). – Gnucki
Говоря о запросе 'POST', в спецификации говорится, что это не идемпотент. Это означает, что идемпотентность не гарантируется. Однако это не означает, что вы _required_, чтобы гарантировать, что несколько запросов «POST» не дают того же результата, что и выдача только одного. Поэтому 'POST' _may_ будет идемпотентным, но в отличие от' PUT', спецификация не гарантирует его. «PUT» действительно является более подходящим выбором здесь. – Evert