API возвращает несколько ошибок

Question

У меня есть этот REST API, который выполняет операции CRUD над клиентами.

Когда я получаю запросы, содержащие недопустимые поля, например, поле «имя», содержащее более 100 символов, возвращается код ошибки http вместе с подробной информацией: «Имя поля должно содержать менее 100 символов!»

Проблема : я должен возвращать несколько ошибок одновременно, например, если «имя» и «день рождения» недопустимы в одном запросе, должны отображаться обе детали ошибки.

Вопрос 1 : Является ли хорошим вариантом для API возвращать более одной ошибки? Или я должен полагаться на View, чтобы проверить эти ошибки ввода и сохранить мой API как есть?

В случае, если я в итоге реализую множественные возвраты, я столкнусь с другой проблемой: В моем проекте реализовано управление на основе домена . Это означает, что существует домен (класс) и проверка выполняется на конструкторе. Если что-то идет не так, возникает исключение!

Вопрос 2 : Как мне проверить все мои поля, если мой поток нарушен при первом исключении?

Надеюсь было понятно и спасибо заранее!

Answer 1

Это хороший дизайн для API, чтобы возвращать более одной ошибки?

В этом нет ничего плохого. RFC 7807 использует в качестве одного из примеров ответ, описывающий несколько недопустимых параметров.

я должен положиться на View для проверки этих ошибок ввода и сохранить мой API как есть?

Я не совсем уверен, как вы это имеете в виду, но вы, безусловно, должны проверять входные данные на принимающей стороне. См. Безопасность, управляемую доменом , от Johnsson and Deogun.

Как мне проверить все мои поля, если мой поток нарушен при первом исключении?

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

Если мы рассматриваем валидацию как концепцию первого класса, то мы можем думать о валидации как о взятии от RawMessage до ValidatedMessage. Первый - это нечто независимое от домена - документ JSON, полезная нагрузка application / x-www-form-urlencoded, коллекция пар ключ-значение. Последний является объектом значения, созданным из значений, которые будет распознавать модель домена.

Ваш метод проверки возвращает тип Or: либо вы получаете проверенное сообщение, либо вы получаете список ошибок проверки

Either<ValidatedMessage, Errors> validate(RawMessage m)

Функциональное моделирование доменов Скотта Влашина, сделанное функциональным - действительно хороший пример этой идеи.

Answer 2

Вы можете создать модель предметной области для ОО-утверждений для достижения цели или «проще» применить функциональный подход, используя монаду, например, для составления бизнес-ошибок. Второй, если он уже предоставлен, если вы используете подходящий инструмент, такой как Scala или любой другой язык, поддерживающий эти монады.

Answer 3

Вопрос 1: Это хороший дизайн для API, чтобы возвращать более одного ошибка? Или я должен полагаться на View для проверки этих ошибок ввода и сохранить мой API как есть?

Коды состояния HTTP делятся на классы. Пока все ошибки относятся к одному и тому же классу (например, 400 Bad Request), вы можете включить описание всех из них в тело ответа.

Вопрос 2: Как мне проверить все мои поля, если мой поток нарушен на первое исключение?

Эта проблема неоднократно поднималась на SO. См., Например, этот Q .

Нет жесткого и быстрого правила. Я советую, чтобы исключения были для непредвиденных случаев, и чтобы предложения try / catch могли загромождать ваш код, если их слишком много. Поэтому я обычно не проверяю материал, граничащий с техническими требованиями, например максимальную длину поля, на стороне домена.

Answer 4

Проверка ввода является ключевым моментом в разработке REST API. Это важно для вас, так как вы можете уберечь себя от нежелательных, возможно, опасных данных, и вы можете помочь пользователям ваших API с четкими сообщениями, когда они их неправильно используют.

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

Чтобы ответить на второй вопрос, вы можете просто приложить в try-catch условие каждый шаг проверки и добавить к ошибкам, если вы встретили какое-то исключение.