Должен ли REST API возвращать 404 при отправке несуществующего идентификатора?

Question

Насколько я понимаю, в дополнение к возвращению 404 Not Found для неизвестных конечных точек , REST API также должен возвращать 404 в следующих случаях:

• запрос ресурса с идентификатором, который не существует в пути : маршрут /users/{id} существует, но /users/123456 не существует
• запрос ресурса с идентификатором, который не существует в параметрах запроса : маршрут /search существует, но /search?user=123456 возвращает 404, если пользователь не существует (я задал аналогичный вопрос несколько лет назад)

Теперь что касается случая использования, когда конечная точка принимает объект JSON с несколькими полями, одно из которых является идентификатором несуществующего пользователя:

POST /makeReservation HTTP/1.1
...

{
    "userId": 123456,
    ...
}

Должно ли это возвращать 404, а также , или это считается ошибкой другого типа (ошибка проверки?) В этом случае?

Answer 1

Насколько я понимаю,

Я бы сказал, что ваше текущее понимание немного сложнее, чем должно быть.

404 НеНайдено означает:

Код состояния 404 (не найден) указывает на то, что исходный сервер не нашел текущее представление для целевого ресурса или не желает раскрыть, что он существует.

В случае, если «целевой ресурс» неясен, мы можем рассмотреть спецификацию Строка запроса .

request-line = метод SP request-target SP HTTP-версия CRLF

Запрос-цель идентифицирует целевой ресурс, к которому следует применить запрос, как определено в Раздел 5.3 .

ВДругими словами, 404 говорит, что "существует проблема с написанием цели-запроса".

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

Код ошибки, который вам, вероятно, понадобится для этого случая: 422 Unprocessable Entity

Код состояния 422 (Unprocessable Entity) означаетсервер понимает тип содержимого объекта запроса (следовательно, код состояния 415 (неподдерживаемый тип носителя) не подходит), и синтаксис объекта запроса является правильным (таким образом, код состояния 400 (неправильный запрос) не подходит), но wкак неспособный обработать содержащиеся инструкции.Например, это условие ошибки может возникать, если тело запроса XML содержит правильно сформированные (то есть синтаксически правильные), но семантически ошибочные инструкции XML.

IANA Реестр кодов состояния HTTP это хорошее место, чтобы посмотреть, когда вы уверены, что должен быть стандартизированный код для вашего варианта использования, но у вас возникают проблемы с предположением, какая спецификация описывает его.

это часть WebDAV, и я 'я не уверен, насколько правильно использовать его для других приложений

TL; DR: правильно использовать, если для других приложений.

Спецификация HTTP определяет процесс , с помощью которого новые коды могут добавляться в статусреестр кодов, и этот процесс был соблюден для кодов WebDAV.Таким образом, мы можем быть уверены, что значение 422 не будет заменено какой-либо другой семантикой (для совместимости коды состояния удалены - см. Код состояния 306 .)

Определение422 в спецификации WebDAV не является специфичным для WebDAV.

Кроме того, поведение клиентов, которые не знают о спецификации WebDAV, описано в RFC 7231

клиент ДОЛЖЕН понимать класс любого кода состояния, как указано первой цифрой, и обрабатывать нераспознанный код состояния как эквивалентный коду состояния x00 этого класса, за исключением того, что получатель НЕ ДОЛЖЕН кэшировать ответ с нераспознаннымкод состояния.

Вы также можете ознакомиться с приложением B спецификации WebDAV.

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