Всякий раз, когда мы вызываем API A() с полезной нагрузкой P, мы выполняем некоторые первоначальные проверки {v1, v2, v3 ...} для P и возвращаем исключение типа E для первой проверки, которая не удалась.Код ответа для этих сбоев проверки: 400.
Мы хотим выделить {v1, v2, v3 ...} проверок в отдельный API V(), чтобы мы могли получить исчерпывающий список ошибок, которые произойдут, когда P не удается выполнить одну или несколько проверок в наборе a priori
С введением этого нового API V() можно отправлять неверный запрос самому API (независимо от P быть плохим или нет), который будет отбрасывать 400 тоже.
Очевидно, что мы хотим устранить неоднозначность, когда V() терпит неудачу из-за неверного запроса на V(), а когда он возвращает правильный список ошибок проверки, которые P не удастся.
Для этого у меня есть несколько вариантов:
Подход № 1
Собрать все ошибки проверки {e1, e2, e3 ...}.Создайте новую ошибку типа E с errorMessage, объединяющей все errorMessage s для {e1, e2, e3, ...} (с правильным разделителем), и отправьте ответ обратно с кодом состояния 200.
* 1037.*
Недостаток : мы возвращаем
200 с ответом, тип которого является типом исключения
E Подход № 2
Делаем # 1, но вместо этого используемновый тип ответа в качестве обёртки вокруг E, который не является Exception
недостатком : это более специфично для моего варианта использования - я хочу быть очень консервативным в добавленииновые типы, потому что их трудно выкинуть, если мы решим от них избавиться.Более того, добавление нового типа только для того, чтобы обойти # 1, выглядит излишним.
Подход # 3
Вместо сворачивания списка ошибок {e1, e2, e3, ...} в одно исключение типа E, мы должны вернуть сам список вместе с 200 кодом состояния.
Недостаток : Проверка, по-видимому, служит пробным прогоном для фактического API A().Используя эту логику, мы хотели бы, чтобы выходы для A() и V() были как можно более похожими, если не одинаковыми (я знаю, это звучит слабо для «недостатка».)
Я не смог найти исчерпывающего обсуждения лучших практик по этому вопросу, поэтому хотел бы обсудить это со стороны сообщества.Конечно, лучший способ действий для меня - это конкретный вариант использования.Я просто хотел узнать об альтернативах и проблемах вокруг этого.