Блог

В своей работе я обнаружил, что люди разрабатывают API REST, в котором есть конечные точки, возвращающие один объект Json (не коллекцию) на основе параметров запроса (не параметров пути). Например:

 /users?name=Johnamp;surname=Sparrow
 

с ответным органом

 {id:10, name="John", surname="Sparrow", gender="male"}
 

Но какой код ответа соответствует в REST API отсутствию поиска ресурса из-за параметров запроса?
Например:

 /users?name=Johnamp;surname=Smith 
 

(когда Джона Смита не существует).

Я не думаю, что это ошибка 404, потому что конечная точка /users существует, но я не знаю, должен ли я возвращать ошибку 400 или 200 без тела (или нулевое значение) или другой вид ответа

Вы не могли бы мне помочь?

Спасибо

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

Мой общий подход заключается в том, что функции поиска, такие как findStuffBySearchTerms, всегда возвращают успешный HTTP-код, например 200, и либо результаты, либо пустой список. С другой стороны, fetchStuffById, где я ожидаю, что объект будет найден, вернет HTTP 404, если он не найден.

Какой код ответа соответствует в REST API отсутствию поиска ресурса из-за параметров запроса?

404 Не Найдено.

Я не думаю, что это ошибка 404, потому что существует конечная точка /users,

Идентификатор ресурса включает параметры запроса. Иными словами, параметры запроса являются частью идентификатора точно в том же смысле, в каком сегменты пути являются частью идентификатора.

В теле вашего запроса вы можете описать обстоятельства вашей реализации так точно, как вам нравится.

Но аудитория кодов состояния HTTP включает компоненты общего назначения (браузеры, прокси-серверы, веб-сканеры), для которых код ответа является основным механизмом описания семантики ответа:

Элемент кода состояния представляет собой 3-значный целочисленный код, описывающий результат попытки сервера понять и удовлетворить соответствующий запрос клиента. Остальная часть ответного сообщения должна интерпретироваться в свете семантики, определенной для этого кода состояния. — RFC 7230

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

 GET /users?name=Dave HTTP/1.1
 

 200 OK
Content-Type: text/plain

Dave's not here, man.
 

Из фрейминга HTTP/REST это вполне разумный обмен; кто-то запросил последнее представление /users?name=Dave , и последнее представление-это обычный текстовый документ. Абсолютно нормально.

Ключевая идея здесь заключается в том, что этот код состояния HTTP является метаданными передачи документов по сетевому домену.

HTTP безразличен к семантическому значению представлений ресурсов.

Тем не менее, вы должны учитывать при разработке такие проблемы, как «как это выглядит в наших журналах доступа?» Если вы хотите, чтобы ваши операторы могли отличить этот случай от аналогичного случая, когда параметры запроса соответствуют информации в вашей базе данных, 200 против 404-это естественный способ сделать это.

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