【发布时间】：2017-01-09 11:39:46
【问题描述】：
我目前正处于构建 RESTful API 的早期阶段，并且一直在寻找处理业务规则验证的正确方法。
我正在使用 Web API 2，目前使用 IValidatableObject 来处理模型验证。例如，如果缺少必填字段，我将返回“400 Bad Request”和ModelState。
我开始在IValidatableObject 的Public IEnumerable<ValidationResult> Validate(ValidationContext validationContext) 方法中添加业务规则验证，并继续返回“400 Bad Request”，并显示一条描述未通过验证的业务规则的消息。然后我退后一步想“业务规则和模型验证不同，请求完全有效，我不应该返回 400。”
现在我计划将业务规则验证从模型验证移到域逻辑中。这让我开始思考我应该如何不仅返回正确的状态代码，而且客户端将如何确定要显示的正确消息。
我在403 Forbidden 和422 Unprocessable Entity 之间纠结，倾向于422。欢迎提出任何建议。
现在让我们假设我发出了一个失败的多个业务规则的请求，并且我返回了 422 和一组错误消息。我希望客户能够理解错误并以他们认为合适的方式呈现消息，而不仅仅是在我的响应中显示消息。
- 哪种 HTTP 状态代码最适合失败的业务？
- 关于返回错误消息的最佳做法是什么？
是否可以返回 422.x 并记录每个 .x，以便客户端知道该怎么做？这似乎给我留下了每个请求只返回一个错误的限制。
我应该定义错误代码并将它们与错误消息一起返回吗？例如：
{
"Errors": [
{ "Error": { "Code": "E0001", "Message": "You failed business rule 1" } },
{ "Error": { "Code": "E0002", "Message": "You failed business rule 2" } }
]
}
任何反馈都会很棒！谢谢！
【问题讨论】：
标签： c# rest api validation asp.net-web-api2