REST API Framework. Рекомендуемое поведение для неверного параметра строки запроса

Question

Я реализую REST API Framework, и мне интересно, каково рекомендуемое поведение, когда клиент отправляет недопустимый параметр строки запроса.

Я проиллюстрирую то, что имею в виду, на конкретном примере: скажем, у меня естьОбработчик API на / api / contacts / endpoint, а также обработчик обеспечивает фильтр строки запросов с именем id, который позволяет клиентам выбирать определенные контакты с предоставленными идентификаторами.

Таким образом, запрос GET или DELETE может быть/api/contacts/?id=2&id=4&id=lalalala.

Понятно, что такого понятия как Контакт с id=lalalala не существует.В таком случае как должен вести себя сервер?

• Игнорировать недействительный контакт с помощью id=lalalala и фильтровать контакты только по действительным идентификаторам, 2 и 4.

• Ответ с кодом ошибки, который указывает на эту ошибку.Если да, какой код ошибки следует указать?

Заранее спасибо.

Редактировать: Уточнить;Основное внимание в фреймворке, которое я разрабатываю, - это предсказуемое поведение и, следовательно, коды ответов.По этой причине я хочу, чтобы клиенты, использующие API, построенный на этой платформе, ожидали как можно меньше сюрпризов.Итак, вопрос в основном таков: должен ли API возвращать ошибку в этом случае (и если да, то какая)?Или игнорировать недопустимые записи фильтра и фильтровать только правильные параметры строки запроса?

Answer 1

Поскольку это вызов REST, мы говорим о ресурсах.И всякий раз, когда у нас неправильный фильтр, мы должны возвращать правильный код ошибки.

В этом случае я бы выбрал 400 - bad request, поскольку ресурс был найден и правильно отображен (/api/contacts), но возникла проблема с частью query string.Следовательно, 400, а не 404.

Возвращает 404, если кто-то запросит /api/contacts-all или какой-либо несуществующий ресурс.

РЕДАКТИРОВАТЬ на основе комментариев ниже

Согласитесь с вашим комментарием.В идеале 400 - это проблема с запросом.Исходя из этого, вы можете использовать 422 Unprocessable Entity.Пожалуйста, посмотрите на ссылку stackoverflow ниже, и она говорит о том же.

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

Ссылки: Http коды состояния и 400 для логической ошибки против искаженного запроса

Answer 2

Следуя букве закона, ответом должно быть 404 Не найдено. Однако никто не будет слишком расстраиваться из-за вас, если вы предпочтете вернуть 400 - неправильный запрос.

Я бы точно вернул код состояния 4XX. Вы хотите, чтобы клиент знал, что он допустил ошибку.