Какой HTTP статус код ожидается при запросе несуществующего ресурса

Что проверяют

Знаете ли вы семантику кодов 4xx и можете ли отличить «ресурса нет» от «вам сюда нельзя» и «такого запроса быть не может». Следом обычно спрашивают, чем 404 отличается от 410, и что вы заведёте в баг-трекер, если API на несуществующий id отвечает 200.

Как отвечать

Базовый ответ: 404 Not Found, сервер не нашёл ресурс по этому URI (RFC 9110). Дальше покажите, что видите соседние случаи:

• GET /users/999999: пользователя нет, ожидаем 404 и тело ошибки в формате из контракта, например application/problem+json по RFC 9457;
• 410 Gone: ресурс был и удалён навсегда, и сервер это знает. Встречается реже, но полезен для удалённых сущностей и поисковиков;
• 405 Method Not Allowed: путь существует, но метод не поддерживается. В ответе должен быть заголовок Allow;
• 400 или 422: id невалиден по формату, например строка вместо числа. Это ошибка запроса, а не отсутствие ресурса;
• 403 против 404: чужой ресурс некоторые API намеренно отдают как 404, чтобы не раскрывать сам факт его существования. Это нормально, если так записано в требованиях.

Для тестировщика это готовый набор проверок: несуществующий id, удалённый объект, id на границе типа, опечатка в пути, повторный DELETE (второй вызов обычно даёт 404). В Postman или в автотестах на pytest с requests проверяйте не только код, но и тело, заголовок Content-Type и отсутствие стектрейса в ответе.

Где спотыкаются

Проверяют только статус-код. Сервер может вернуть 404 с HTML-страницей nginx вместо JSON, клиент упадёт на парсинге, а тест останется зелёным.

Путают 404 с 400 и 500. Если на GET /orders/abc приходит 500, это баг: сервер не обработал невалидный ввод, и исключение улетело наружу.

Считают 200 с пустым телом или с {"error": "not found"} допустимым вариантом. Это нарушение семантики HTTP, которое ломает кэширование, мониторинг и ретраи, и на него стоит заводить дефект.