时间戳

首页 > 解决方案 > 为什么在 RESTful 服务中使用 HTTP 响应代码来指示业务相关逻辑？

rest - 为什么在 RESTful 服务中使用 HTTP 响应代码来指示业务相关逻辑？

问题描述

我已阅读此内容： 对于一般不成功的请求（不是错误），适当的 HTTP 状态代码响应是什么？

我理解这些原则，但使用 HTTP 响应代码来指示业务逻辑事物的 RESTful API 服务状态似乎模棱两可、重复且让我感到困惑。

仅考虑 HTTP 响应代码，403 可能表示用户没有足够的权限使用 RESTful 服务，或者只是无权访问 HTTP 服务器（例如 HTTP 授权失败）。

所以在这种情况下，客户端应该查看响应正文，看看它是业务逻辑错误还是仅仅是服务器错误。

对于 404，客户端不知道服务器上的资源是否不存在，或者业务对象是否不存在。它还必须查看响应正文。

那么为什么人们会继续使用带有业务逻辑错误的 HTTP 响应代码呢？对我来说，简单地查看响应正文中的业务逻辑错误并进行处理更简单。是否有必要使用带有业务逻辑错误的 HTTP 响应？

非常感谢。

标签： restrestful-architecture

解决方案

那么为什么人们会继续使用带有业务逻辑错误的 HTTP 响应代码呢？

在通过 HTTP 协议创建遵循REST 架构风格的应用程序时，您需要使应用程序域适应资源，这是 REST 架构的核心部分。

服务器提供一组 URL 来定位资源，并且可以通过 HTTP 动词和 JSON 和/或 XML 等表示来操纵它们的状态。HTTP 状态码用于通知客户端有关操作的状态。误导性的状态代码将传达有关请求状态的错误信息。

RFC 7231定义了状态码的类别：

  • 1xx（信息性）：请求已收到，继续处理
  • 2xx(Successful)：请求被成功接收、理解并接受
  • 3xx（重定向）：需要采取进一步的行动才能完成请求
  • 4xx（客户端错误）：请求包含错误的语法或无法完成
  • 5xx（服务器错误）：服务器未能满足明显有效的请求

例如，如果请求由于客户端错误而失败（例如，有效负载中提供了格式错误的请求或无效数据），则返回 a2xx或5xx状态代码在这里会产生误导。状态码将4xx适合表达导致错误的原因。

是否有必要使用带有业务逻辑错误的 HTTP 响应？

诸如409和之类的一些状态422可以用来表示业务逻辑错误。

对我来说，简单地查看响应正文中的业务逻辑错误并进行处理更简单。

确实，HTTP 状态代码有时不足以传达有关错误的足够信息以提供帮助。但是创建RFC 7807是为了填补这一空白：它定义了简单的 JSON 和 XML 文档来指示问题。

推荐阅读