В каких случаях идемпотент PUT будет полезен в REST?

Question

Хорошо. Я читал в нескольких местах, что использование одного и того же PUT URL несколько раз должно иметь одинаковый эффект. Размещение данных в Api / Student / 1234 должно либо создать, либо обновить одного и того же студента с идентификатором 1234.

Теперь каждый URL будет иметь полезную информацию о фактических данных ученика, которые должны быть добавлены или обновлены в базе данных. Почему бы ID не быть частью полезной нагрузки? Я могу просто ПОСТАВИТЬ данные в Api / Student с данными, содержащими идентификатор.

Вы бы сказали, что Урл не идемпотент. Мой вопрос: как я получу пользу от создания идемпотента PUT url? Я понимаю, что GET должен быть идемпотентом. Но почему PUT должен быть идемпотентом, потому что клиент - это тот, кто помещает данные. Вызов одного и того же URL Api / Student с полезной нагрузкой, содержащей один и тот же Id студента, будет иметь одинаковый эффект каждый раз. Так что цель решена верно?

Пожалуйста, помогите.

Answer 1

У вас должен быть идентификатор в URI, чтобы прокси кэширования работали правильно.Если вы сделаете

PUT /Api/Student/23

Промежуточный кеш знает, что любая хранящаяся в нем копия /Api/student/23 устарела и может быть удалена из кэша.То же самое касается GET, если вы не идентифицируете ресурс уникальным образом с помощью идентификатора, тогда кэш не сможет сохранять это представление ресурса независимо.

Если вы будете следовать своему аргументу до логического предела, то вы можете сказать,что вам не нужен студент в URI, потому что эта информация может храниться в полезной нагрузке.И вы абсолютно правы, и это правильный подход, это просто не REST в этот момент.Ограничение унифицированного интерфейса REST включает в себя «идентификацию ресурсов» в качестве одного из подусловий.

Answer 2

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

Если вы делаете PUT на /Api/Student/1234, вы работаете с этой конкретной записью студента. Если вы делаете PUT на /Api/Student, то вы работаете с всеми записями студентов, массовым обновлением. Да, теоретически вы также можете разрешить выбранное обновление таким образом, оно не имеет хорошего архитектурного запаха. Кодировать наименование ресурса в пути. (И если вы хотите создать новый ресурс, имя которого вы еще не знаете, используйте POST, конечно.)

Answer 3

В соответствии с архитектурой REST вы можете использовать PUT для создания нового ресурса и POST для обновления существующего ресурса.Источник: http://en.wikipedia.org/wiki/Representational_State_Transfer, поиск PUT.

Вызов PUT для Api / Student / 1234 будет означать, что вы хотите создать студента с ID 1234. «URL PUT несколько раз должен иметь одинаковый эффект»;да, но эффект заключается в том, чтобы создать этого ученика снова, а не обновлять его во второй раз, поэтому он идемпотентен, как вы сказали, но таким образом.

Вы действительно пытались сделать запрос PUT?Вы знакомы с тем, как это работает?Я дам вам совет: используйте кодировку json (чтобы вы могли отправлять как текстовые, так и двоичные данные), если вам это когда-нибудь понадобится.