每当我们调用带有有效负载A()的API P时，我们都会对{v1, v2, v3 ...}进行一些初始验证P并返回类型为E的异常。第一次验证失败。这些验证失败的响应代码为400。
我们想将验证{v1, v2, v3 ...}分解到一个单独的API V()中，以便我们获得当P在集合中一次或多次验证失败时将发生的错误的详尽列表。 先验
通过引入新的API V()，有可能向API本身发送错误的请求（无论P是否良好），这都会抛出400太。
很明显，我们希望消除由于V()的错误请求而导致V()失败与返回P失败的正确验证错误列表时的歧义。
为此，我有一些选择：
收集所有验证错误{e1, e2, e3 ...}。使用E将errorMessage的所有errorMessage串联在一起（使用适当的分隔符），创建类型为{e1, e2, e3, ...}的新错误，并将状态码为{ {1}}。
缺点：我们将返回200，其响应的类型为异常200
执行＃1，而是使用新的响应类型作为E的包装，而不是E
缺点：这更适合于我的用例-我想在添加新类型时非常保守，因为如果我们决定摆脱它们，它们很难被淘汰。此外，添加一种新的类型只是为了绕过＃1似乎是过大了。
我们不应将错误列表Exception折叠成类型为{e1, e2, e3, ...}的单个异常，而应返回列表本身以及状态代码E。
缺点：该验证似乎是对实际API 200的一次尝试。按照这种逻辑，我们希望将A()和A()的输出保持尽可能的相似，如果不相同的话（我知道这对于“缺点”来说听起来很弱）。
我无法就此方面的最佳实践进行详尽的讨论，因此想由社区来收集想法。当然，对我而言，最佳的操作方法是针对我的用例。我只是想了解有关此方面的替代方法和陷阱。