Если при создании RESTful API пользователь предоставляет id несуществующего ресурса, следует вернуть 404 Not Found или 400 Bad Request.
Например:
https://api.domain.com/v1/resource/foobar
Где foobar не существует.
Должен ли RESTful API возвращать 400 или 404 при передаче недопустимого идентификатора
comment
При разработке API важно больше самодокументироваться, поэтому, когда есть ошибка, важно, чтобы API предоставил потребителю руководство по исправлению курса. Выдача 404 — это, прежде всего, неправильная документация, но также и вводящая в заблуждение. Также важно отметить, что URL, HEADERS, BODY являются частью запроса, и если какой-либо из них имеет неверный формат, я предпочту, чтобы поставщик API возвращал однозначный ответ, чтобы я мог, конечно, исправить. Кроме того, я бы предпочел хорошо отформатированный запрос, входящий в мое внутреннее приложение, если на то пошло, даже в хранилище данных, чтобы избежать ненужных сюрпризов.
- person Navap schedule 15.09.2018
comment
Используйте код 404 и следуйте инструкциям datatracker.ietf.org/doc/html/rfc7231#. section-6.5.1 : поля заголовка ответа позволяют серверу передавать дополнительную информацию об ответе помимо того, что помещено в строку состояния. Эти поля заголовка предоставляют информацию о сервере, о дальнейшем доступе к целевому ресурсу или о связанных ресурсах.
- person MickH schedule 12.07.2021
Ответы (6)
Я бы вернул 404 в случае, если ресурс не существует (означает, что URL-адрес неверен), и я верну 400, только если оставшийся вызов сделан с некоторыми неверными данными (@PathParam), например,
https://api.domain.com/v1/profile/test@email: здесь я пытаюсь получить профиль идентификатора электронной почты , но адрес электронной почты неверный, поэтому я верну 400.
https://api.domain.com/v1/profile1111/[email protected] вернет 404, потому что URL-адрес недействителен.
person
Manoj
schedule
19.08.2014
Зачем вам проверять почту в этом случае?
- person Jimmy T.; 25.12.2016
Этот ответ неверен. Согласно tools.ietf.org/html/rfc2616#section-10.4.5: 10.4.1 400 Bad Request Запрос не может быть понят сервером из-за искаженного синтаксиса. Клиент НЕ ДОЛЖЕН повторять запрос без изменений. 10.4.5 404 Not Found Сервер не нашел ничего, соответствующего Request-URI. Никаких указаний на то, является ли состояние временным или постоянным, не дается. Итак, первый пример должен вернуть 404, а второй 400.
- person Przemo; 15.08.2018
Чтобы добавить в @Przemo: IMO, в случае, если вы проверяете адрес электронной почты, первый пример также должен возвращать 400, но если формат электронной почты был в порядке, а запись с этим адресом электронной почты не существует, верните 404.
- person user2340939; 13.11.2018
Объяснение моего отрицательного ответа: либо ресурс существует для данного идентификатора, тогда запрос GET должен быть возвращен без проверки синтаксиса идентификатора (обычно HTTP 200 OK). Или его нет, то возвращается 404. Вы можете ввести такую проверку идентификатора при обработке HTTP PUT. Включение его в GET — неправильный подход.
- person observer; 14.05.2020
Это может быть неправильно, если вы хотите полностью следовать REST-идее (что понятно). Но тогда у вас возникает проблема, заключающаяся в том, что клиент вашего API теперь может различать эти два случая (неверный ли сам URL-адрес или он просто отправил неверный параметр пути?). Поэтому, даже когда вы технически правы @Przemo, я думаю, вы может привести веские доводы, чтобы отклониться от правильного пути для ясности - поэтому отправьте 400, чтобы было ясно, что с предоставленными параметрами что-то не так, а сам URL был правильным
- person Mario B; 28.06.2021
Должно быть 404 (не найдено). 400 используется, если вы не можете выполнить запрос из-за плохого синтаксиса, однако для вашего случая синтаксис правильный, однако ресурса foobar нет.
Вы можете использовать 400, если пользователь использует несуществующий API, как показано ниже:
https://api.domain.com/v1/nonexistAPI/xyz/xyz
Вы также можете обратиться к этому блогу REST API Design, в котором рассказывается, как создавать коды ошибок REST.
person
Rudy
schedule
19.08.2014
Тогда я не могу сказать, неправильный ли маршрут или элемент не найден. Оба они дадут мне 404 ??
- person Wahid Bitar; 10.10.2018
@Wahid Bitar: Обычно вы получаете спецификацию OpenAPI, в которой указаны доступные маршруты. Используя это, вы можете утверждать, что ваши маршруты верны в соответствии со спецификацией, и вы можете написать тесты для этого.
- person observer; 14.05.2020
@Rudy: Ваш пример с nonexistAPI также должен возвращать HTTP 404 по той же причине, которую вы объяснили во втором предложении своего ответа :-), то есть это синтаксически допустимый HTTP-запрос.
- person observer; 14.05.2020
Я думаю, что 404 Not Found - правильный ответ, 400 больше касается тела запросов, а не идентификатора ресурса, поэтому, например, вы можете отправить это по ошибкам проверки.
person
inf3rno
schedule
19.08.2014
Это действительный запрос? Может ли существовать идентификатор ресурса? Он отформатирован как правильный идентификатор? Это синтаксически правильно? и т.д.. Если да, то вы можете использовать 404 Not Found. В противном случае больше подходит 400 Bad Request.
person
qbit
schedule
19.08.2014
Согласно RFC (https://tools.ietf.org/html/rfc2616#section-10.4) API должен возвращать 404, когда
"Сервер не нашел ничего, соответствующего Request-URI",
что является вашим примером.
400 будет, когда ресурс найден, но сам запрос искажен.
Например: я. https://api.domain.com/v1/resource/foobar
где foobar НЕ существует, должен возвращать 404
II. https://api.domain.com/v1/resource/foobar, где foobar ДЕЙСТВУЕТ существует, но запрос неверен (например, {age:"NOTANINTEGER"}, string вместо int), он должен вернуть 400.
Надеюсь, я смог помочь.
person
Tiaraju
schedule
21.08.2018
404 будет более распространенной практикой. Это для Resource Not Found. В вашем случае конкретный URL-адрес не найден.
400 обычно используется вместо Bad Request. Вы можете использовать это для любого плохого запроса. Например. MissingRequiredQueryParameter, InvalidInput.
person
user636856
schedule
20.08.2014
