Не говоря уже о спецификации HTTP, какова основная причина или преимущество добавления идентификатора ресурса в HTTP PUT?

Если я могу сделать следующее при создании записи,

URI: / api / roles /
Метод: POST
Содержание: {Id: 0, Name: 'Admin', Описание: 'Административная роль'}


Могу я просто сделать это, если хочу обновить запись?

URI: / api / roles /
Метод: PUT
Содержимое: {Id: 1001, имя: «Администратор», Описание: «Роль администратора»}

... потому что я могу просто получить идентификатор в поле Id. Вместо этого?


URI: / api / roles / 1001
Метод: PUT
Содержимое: {Id: 1001, имя: «Администратор», Описание: «Роль администратора»}

... указав значение Id дважды. Кстати, я не могу удалить поле Id в контенте.

Если нет, то почему? Какова основная причина или преимущество добавления идентификатора ресурса в HTTP PUT, отказавшись от спецификации HTTP?


http rest asp.net asp.net-web-api http-method
person spitfyr86    schedule 18.08.2015    source источник
comment
Обычно id передается для уникальной идентификации ресурса, а содержимое используется для обновления его текущего состояния. Я считаю, что вам разрешено делать то, что вы хотите.   -  person Amit Kumar Ghosh    schedule 18.08.2015
comment
Я думаю, что если отбросить принципы HTTP, то на самом деле нет никаких преимуществ или причин. Но я думаю, вы теряете ясность или простоту использования вашего API. Без применения принципов HTTP ничто не мешает вам сделать ваши операции обновления доступными с помощью запросов GET или POST.   -  person Frank Fajardo    schedule 18.08.2015

Ответы (2)


arrow_upward
1
arrow_downward

Добавление ресурса ID обозначает один из шагов RESTful API.

Дальнейшее обсуждение можно найти здесь: В чем преимущество использования REST вместо HTTP без REST?

Принципы проектирования RESTful определяют HATEOAS, в котором примерно указано, что взаимодействие с конечной точкой должно определяться в метаданных, которые идут с выходным представлением, а не на основе внеполосной информации.

http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

person Muks    schedule 18.08.2015

arrow_upward
1
arrow_downward

Я согласен, что, похоже, существует странная избыточность в указании идентификатора в URL-адресе, а также в теле запроса.

На мой взгляд, причина не техническая, а «культурная».

Всякий раз, когда URL-адрес / api / roles / вы указываете, что список обрабатывается, тогда как / api / roles / {id} явно указывает на то, что цель является элементом списка.

person morsor    schedule 18.08.2015