我已阅读以下内容： What is the appropriate HTTP status code response for a general unsuccessful request (not an error)?
我理解这些原理，但是使用HTTP响应代码指示业务逻辑事物的RESTful API服务状态似乎是模棱两可的，重复性的并使我感到困惑。
仅考虑HTTP响应代码，403可能表明用户没有足够的特权来使用RESTful服务，或者只是没有访问HTTP服务器的权限（例如，HTTP授权失败）。
因此，在这种情况下，客户端应查看响应主体，以查看它是业务逻辑错误还是仅仅是服务器错误。
对于404，客户端不知道服务器上的资源是否不存在，或者业务对象不存在。它也必须调查响应主体。
那么为什么人们会继续使用HTTP响应代码并遇到业务逻辑错误？对我来说，简单地查看响应主体中的业务逻辑错误并进行处理就更简单了。是否有必要将HTTP响应与业务逻辑错误一起使用？
非常感谢。
答案 0 :(得分：1)
那为什么人们会继续使用带有业务逻辑错误的HTTP响应代码？
创建通过HTTP协议遵循REST architetural style的应用程序时，您可以将应用程序域调整为资源，这是REST体系结构的核心部分。
服务器提供一组URL来定位资源，并且它们的状态可以通过HTTP动词和表示形式（例如JSON和/或XML）进行操纵。 HTTP status codes用于通知客户有关操作状态的信息。误导性的状态代码将传达有关请求状态的错误信息。
RFC 7231定义了状态代码的类：
1xx（信息性）：收到请求，正在继续处理2xx（成功）：请求已成功接收，理解并接受3xx（重定向）：需要采取进一步的操作才能完成请求4xx（客户端错误）：请求包含错误的语法或无法实现5xx（服务器错误）：服务器未能满足看似有效的请求例如，如果由于 client错误而导致请求失败（例如，有效载荷中提供了格式错误的请求或无效数据），则返回2xx或{{ 1}}状态代码在这里令人误解。状态代码5xx可以用来表达引起错误的原因。
是否有必要将HTTP响应与业务逻辑错误一起使用？
对我来说，简单地查看响应主体中的业务逻辑错误并进行处理会更简单。
确实，HTTP状态代码有时不足以传达有关错误的足够信息以提供帮助。但是RFC 7807是为了填补这一空白而创建的：它定义了简单的JSON和XML文档来指示问题。