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

Я внедряю 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 возвратить ошибку в этом случае (и если да, то какой)? Или игнорировать недопустимые записи фильтра и фильтровать только правильные параметры запроса?

Ответы

Ответ 1

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

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

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

EDIT, основанный на комментариях ниже

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

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

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

Ответ 2

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

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