Question

我们的团队讨论当服务器遇到业务异常（可能是验证或其他一些与业务相关的异常）时REST API的行为。

团队的一部分声称服务器每次都应该发送200作为状态，并在响应上添加标志和代码。据我所知，这种方法打破了HTTP状态码原则和Richardson Maturity Model。

团队的其他部分希望将业务异常映射到HTTP状态代码。这种方法是否遵循REST原则或业务异常不在那里？

我很想听听有关这次辩论的其他意见。

Answer 1

我们通过“享受”两个世界来解决我们团队中的问题：

我们将业务例外映射到最近的HTTP代码。例如，如果用户要求找不到的实体，我们会给出404。

在响应中，我们提供了一个错误JSON，其中包含与此类似的所有业务相关信息：

[
    {
        "code": 4004, // This is our application specific code in thousands instead of hundreds
        "message": "entity <bla bla> not found",
        "stack": ... // The stack trace for debugging
        "headers": ... // The request headers also for debugging
    },
    {
        ... // Another error JSON here
    }
]

请注意，它是一个数组，因为有时我们在输入验证逻辑中发现了多个错误。

Answer 2

REST支持使用标准而不是自定义解决方案。因此，如果您使用HTTP作为底层协议，那么我认为您应该将错误类型映射到HTTP状态标头，而不是开发一个不符合HTTP标准的自定义解决方案。这是uniform interface / self descriptive message约束的一部分。文本没有提到HTTP状态标题，但HTTP方法和其他标题是其中的一部分，作为应用标准的统一接口的示例，所以我认为意图非常明确......

OFC。允许发送有关错误的更具体的消息体以及正确的状态标题。

业务异常的REST API设计

2 个答案: