REST API是否应该定义不同于成功响应的错误响应？[重复]
API的成功响应具有json格式（基于avro模式）。对于错误，它是否应该为异常定义另一种格式（模式）？或者成功的响应应该包括错误部分？发生错误时，将其他部分留空，只填充错误。
这更像是一个内部应用编程接口，需要定义各种自定义异常消息。它是否应该对所有此类应用程序错误使用相同的HTTP状态代码？
这些决定如何影响OPEN API（SWAGGER）？
共有1个答案
HTTP状态代码属于网络域上的通用传输文档。
换句话说，您的API应该像任何其他网站或启用Web的文档存储一样响应。
特定于域的信息属于响应的主体。
RFC 7807定义了应用程序/问题json，它是用于描述问题的通用模式。当然，您不需要使用它，但是采用标准化的模式确实允许您利用已经完成的工作来支持它。
对于错误，它是否应该为异常定义另一种格式（模式）？或者成功的响应应该包括错误部分？
这两种方法中的任何一种都是合理的，这取决于您试图传达的信息。
考虑一下你如何在网上做这件事。我要求提供我订单状态的HTML表示，但您的供应商延迟了。你需要给我一个完全不同的回复吗？对于这样一个简单的情况，可能不会-这里不太可能有模式冲突，只有依赖于顺序状态的各种可选元素。
另一方面，当你需要一个人时，你可能需要不同的信息表达方式，而不是你期望信息由机器处理的情况。
-
Apache可以让网站管理员自己自定义对一些错误和问题的响应。 自定义的响应可以定义为当服务器检测到错误或问题时才被激活。 如果一个脚本崩溃并产生"500 Server Error"响应，那么这个响应可以被更友好的提示替换或者干脆用重定向语句跳到其他的URL(本地的或外部的)。 行为 老式的行为 Apache1.3 会响应一些对于用户没有任何意义的错误或问题信息，而且不会将产生这些错误的原因写入日
-
授权服务器颁发访问令牌和可选的刷新令牌，通过向HTTP响应实体正文中添加下列参数并使用200（OK）状态码构造响应： access_token 必需的。授权服务器颁发的访问令牌。 token_type 必需的。如7.1节所述的颁发的令牌的类型。值是大小写不敏感的。 expires_in 推荐的。以秒为单位的访问令牌生命周期。例如，值“3600”表示访问令牌将在从生成响应时的1小时后到期。如果省略，
-
我正在使用改装连接到REST服务器，我需要处理成功响应和错误响应。我基于此示例构建我的客户机。 例如，在get token方法上，服务器成功响应具有以下结构： 故障响应是： 我的问题是，应用程序将错误响应视为成功。我的代码是： -rest api方法接口： -模型登录响应： -模型错误响应： -Rest回调： -客户端类别： 错误在哪里？
-
给Rest服务打电话 http://acme.com/app/widget/123 返回： 此客户端代码的工作原理是： 但是,http://acme.com/app/widget/456返回： 但此客户端代码引发了一个异常： 我试过： 第二次调用只是抛出了另一个HttpClientErrorException，而且它觉得调用服务两次是不对的。 是否有一种方法可以调用该服务一次，并在成功时将响应解析