Блог

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

например

Метод действия REST api: /resources/{id}

Тело:

 {
    "id": "test",
    "name": "my_resource"
}
 

Какой код состояния HTTP должен быть возвращен в следующий запрос curl?

 curl -X PUT 'localhost:8080/resources/test2' 
--header 'Content-Type: application/json' 
--data-raw '{
    "id": "test",
    "name": "my_resource"
}'
 

Вероятно, вы можете привести аргумент для любого из

• 403 Запрещено (я понимаю ваш запрос и отказываюсь его выполнять — подробности см. В теле ответа)
• Конфликт 409 (предлагаемое вами изменение противоречит текущему состоянию ресурса — подробности см. В теле ответа)
• 422 Необработанное содержимое (тело вашего запроса внутренне согласовано, но здесь не имеет смысла — подробности см. В теле ответа).

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

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

Для получения более подробной информации см. Раздел 15.5 семантики HTTP

Считаете ли вы, что внутренняя ошибка сервера 500 с надлежащим объяснением тоже подойдет или это сбивает с толку?

Ошибка сервера 5xx неуместна, когда информация в запросе является источником проблемы, поскольку ответственность за форму запроса несет клиент, а не сервер.

В общих чертах: 4xx охватывает все случаи, когда сервер объявляет «вы не должны были просить об этом». 5xx предназначен для вариантов «то, что вы просили, в порядке, но я не смог этого сделать».

Смотрите спецификацию семантики HTTP, в частности разделы 15.5 и 15.6 (или, если вы предпочитаете более раннюю ссылку, RFC 7231 6.5 и 6.6)