Заставить PUT создать идемпотентный запрос в REST API

Моя цель - сделать идемпотент/создать REST API, который реализован как глагол PUT.

Идемпотентный RFC гласит:

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

PUT RFC гласит:

Если у целевого ресурса нет текущего представления, а PUT успешно создает его, то сервер-источник ДОЛЖЕН сообщить
агенту пользователя, отправив ответ 201 (Created). Если целевой
ресурс действительно имеет текущее представление и это представление
успешно изменено в соответствии с состоянием вложенного представления, то исходный сервер ДОЛЖЕН отправить либо 200 (ОК), либо 204 (Нет содержимого). ответ, указывающий на успешное выполнение запроса
.

Предполагая, что /create сохраняет созданный ресурс в БД, должен ли он возвращать 201 при первом создании и 200 при повторной попытке /create? Следует ли повторить /создать, чтобы снова и снова сохранять один и тот же ресурс в БД, чтобы соответствовать PUT RFC?


http rest put idempotent
person rok    schedule 17.12.2017    source источник
comment
Используйте POST для сохранения и PUT для обновления.   -  person Ayush Gupta    schedule 17.12.2017
comment
моя цель - сделать PUT/create idempotent. значит можно повторить   -  person rok    schedule 17.12.2017
comment
Как вы узнаете, создавать ли ресурс или обновлять его?   -  person Ayush Gupta    schedule 17.12.2017
comment
я проверю, существует ли он с таким же идентификатором   -  person rok    schedule 17.12.2017
comment
И вы получите удостоверение личности? Просто любопытно, потому что PUT / и PUT /:id это 2 разных ресурса   -  person Ayush Gupta    schedule 17.12.2017
comment
stackoverflow.com/questions/27728163/ объясняет Это   -  person rok    schedule 17.12.2017
comment
Давайте продолжим обсуждение в чате.   -  person rok    schedule 17.12.2017

Ответы (1)


arrow_upward
2
arrow_downward

Так что этот вопрос немного запутан. Посмотрим, сможем ли мы его распутать.

PUT /create

abcde

Грубо говоря: замените состояние /create представлением abcde. Другими словами, семантика сообщения представляет собой что-то вроде

store(key => "/create", value => "abcde")

Обратите внимание, что двукратная обработка этого сообщения дает тот же эффект, что и однократная обработка сообщения.

store(key => "/create", value => "abcde")
store(key => "/create", value => "abcde")

Обратите внимание, что мы очень конкретно используем ключ, который мы здесь используем; PUT относится к состоянию целевого ресурса; PUT /create — это сообщение с просьбой изменить /create, а не запрос на создание какого-либо другого ресурса.

Предполагая, что /create сохраняет созданный ресурс в БД, должен ли он возвращать 201 при первом создании и 200 при повторной попытке /create?

да.

Следует ли повторить /создать, чтобы снова и снова сохранять один и тот же ресурс в БД, чтобы соответствовать PUT RFC?

Если ресурс уже имеет запрошенное представление, вам не нужно сохранять его снова.

person VoiceOfUnreason    schedule 18.12.2017
comment
большое спасибо. Если ресурс уже имеет запрошенное представление, вам не нужно сохранять его снова. Если я правильно понял, единственный способ добиться этого — получить ресурс из БД и сравнить его с представление ресурсов в теле. - person rok; 18.12.2017