Обновление ресурса блога по идентификатору - PullRequest
0 голосов
/ 10 июня 2019

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

Для запроса PUT должна быть id обновляемого блога в URI или в теле, например:

В URI:

/api/blog/23

В теле:

{
  "id": "23",
  "title": "new blog title"
}

Есть ли правильное и неправильное? Если нет, то какое правило обычно используется для RESTful API?

Ответы [ 2 ]

1 голос
/ 10 июня 2019

Технически нет правильного или неправильного способа разработки API.Однако, хорошо разработанный API будет намного легче понять.

Предполагая, что это REST API , я предпочитаю оставаться последовательным.Если для вашего API требуется идентификатор в URI для ресурсов GET, я бы рекомендовал поддерживать соответствие с идентификатором в URI до PUT.

Microsoft имеет хороший APIстатья по разработке , в которой также рекомендуется поддерживать согласованность URI.

0 голосов
/ 10 июня 2019

PUT в HTTP означает нечто очень специфическое

Метод PUT запрашивает, чтобы состояние целевого ресурса было создано или заменено на состояние, определенное приложенным представлениемв полезной нагрузке сообщения запроса.

Это запрос, который просит сервер изменить копию сервера в соответствии с представлением, предоставленным клиентом.Подумайте «Сохранить» или «Перезаписать» - действие по управлению контентом.

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

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

URI - это идентификатор - ключ для поиска в хеш-таблице / словаре.Нет особой причины, по которой данные, закодированные в идентификаторе, должны соответствовать данным в представлении.Это, безусловно, может - мы будем часто кодировать в URI информацию, которую сервер будет использовать в своей собственной внутренней реализации - но /4ca7fce6-efce-42d1-8fc6-666c3cae4f90 является совершенно допустимым идентификатором ресурса.

...