Разработка API: когда возвращать BAD REQUEST HTTP-код состояния (REST)

Question

Мы создаем службы REST и обсуждаем, что делать, когда кто-то запрашивает ресурс с родительским идентификатором, который не существует.

Пример. Вы запрашиваете список людей, связанных с компанией, поэтому вы GET обладаете идентификатором 1, но этот идентификатор компании не существует.

Я бы сказал, что определение REST говорит о том, что мы просто возвратим пустой список (в результате HTTP 204 (No Content)), поскольку неверный HTTP-запрос только для неправильно сформированного синтаксиса, согласно спецификации:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Запрос не может быть понят сервером из-за неправильного синтаксиса. Клиент НЕ ДОЛЖЕН повторять запрос без изменений.

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

Мысли о лучшей практике?

Здесь обсуждается SO: HTTP 400 (неправильный запрос) для логической ошибки, а не синтаксиса неправильного запроса , хотя это немного более абстрактно, я разрываюсь, если я должен опубликовать это или просто использовать этот вопрос

Answer 1

Если вы делаете

GET /company/1

и не существует компании с идентификатором 1, то я думаю, что соответствующий код статуса HTTP - 404. Не найдено.

Однако, если вы былисделать,

GET /companies?id=1

Тогда я бы вернул 200 и пустой список компаний.

Answer 2

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

404 Not Found - более распространенная ошибка для описываемого вами случая. Вы правы, что это не синтаксическая ошибка, поэтому 400 не подходит, но на самом деле ресурса там нет. 404 Not Found - точный ответ.

Но при выборе между 200, 204 и 404 правильный ответ таков: это зависит. Вопрос в том, является ли это ошибкой или нет. 404 более выразителен (клиент может сказать, что такой компании нет), но вы можете обменять выразительность на безопасность, а это может быть хорошо, если клиент не может сказать, существует компания с таким идентификатором или нет.

Answer 3

А как насчет кеширования? только 200 будут кэшированы, а 204 и 404 не будут кэшированы. Если это важно, 200 с пустым списком, кажется, хорошо. Не уверен, что насчет пустых отдельных элементов?