Является ли HTTP 404 подходящим ответом для операции PUT, когда какой-либо связанный ресурс не найден?

Представьте веб-службу REST, где вы добавляете элементы в какой-либо тип контейнера. Например, скажем, мы могли бы добавить участника # 789 к событию # 456 следующим образом:

PUT http://..../api/v1/events/456/attendees/789

Если какое-либо событие # 456 или участник # 789 не существует, правильно ли возвращать HTTP 404 (вместе с подробной информацией о полезной ошибке, объясняющей, в чем проблема, например { "error" : { "message" : "Event 456 does not exist" , "code" : "404" } }?

Аналогично, что, если я создаю что-то новое, которое ссылается на другой объект, но другой объект не существует? Например, представьте, что я создаю событие в Location # 123

PUT http://..../api/v1/event
{ "location": 123, "name": "Party", "date": "2012-05-23", ...etc... }

Если Location № 123 не существует, также верно ли возвращать 404 (вместе с деталями в ответ)? Если нет, то что было бы уместно - всего 400?

В соответствии с спецификацией HTTP 1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

9.6 PUT... Если ресурс не может быть создан или изменен с помощью Request-URI, следует дать соответствующий ответ об ошибке, который отражает характер проблемы.

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

Не слишком беспокоитесь о моих точных примерах здесь - они составлены, чтобы проиллюстрировать суть. Главный вопрос: 404 - соответствующий ответ на операцию PUT, которая терпит неудачу, потому что связанный ресурс не найден?

Было бы замечательно, если бы вы могли указать на ссылки - мне трудно найти какие-либо данные, которые попадают на этот уровень детализации, а также достаточно правдоподобны. Особенно в отношении отношения ресурсов к ресурсам в проекте REST API.

Обновленное мышление Я думаю, что, возможно, первый пример должен вернуть 404, второй - не должен. Причиной является то, что в первом случае добавляемый ресурс использует событие 456 и участника 789 в качестве составного первичного ключа; второй случай - это только внешний ключ. Во втором случае ошибка должна быть возвращена, но не 404 - возможно, условие 412 Precondition Failed или может быть просто 400 Bad Request. Мысли?

Ответ 1

Существует несколько кодов статуса 4xx HTTP. Скорее всего, это 404 или 409:

404 Не найдено

Сервер не нашел ничего подходящего для URI эффективного запроса.    Не указывается, является ли это условие временным или    постоянны. Код состояния 410 (Gone) СЛЕДУЕТ использовать, если сервер    знает через какой-то внутренне настраиваемый механизм, что старый    ресурс постоянно недоступен и не имеет адреса пересылки.    Этот код состояния обычно используется, когда сервер не желает    точно указать, почему запрос был отклонен или когда нет другого    ответ.

409 Конфликт

Запрос не может быть выполнен из-за конфликта с текущим    состояние ресурса. Этот код разрешен только в ситуациях, когда    ожидается, что пользователь сможет решить конфликт    и повторно отправьте запрос. Тело ответа ДОЛЖНО включать достаточно    информацию для пользователя, чтобы узнать источник конфликта.    В идеале представление ответа включало бы достаточную информацию    для пользователя или агента пользователя для устранения проблемы; однако это может    не может быть и не требуется.

Конфликты чаще всего возникают в ответ на запрос PUT. Для    Например, если использовалось управление версиями, а представление    PUT включал изменения в ресурс, который противоречит    более ранний (сторонний) запрос, сервер может использовать 409    чтобы указать, что он не может выполнить запрос. В этом    случай, представление ответа, скорее всего, содержит список    различия между двумя версиями.

Любой из них был бы подходящим, но я думаю, что я поеду на 409. 404 используется для URI не найден, но 409 указывает, что текущее состояние ресурса не позволяет запрошенной операции. В вашем случае запрос не может быть удовлетворен, потому что что-то не так, что его не позволяет.