Question

因此，作为一名开发人员，我有一个非常基本的问题，在 REST标准中，出于特定原因，我们有 100个错误代码，如：

4xx如果资源相关
5xx
还有更多。

现在谈到实施时，我们直接返回404 作为响应状态代码 ，并在响应正文中显示错误消息。有了这种方法，我认为有点令人困惑，如果URI本身永远不会被生成，这意味着假设/ a / b未实现并且正在他们回复404的任何服务器，以及作为客户他们检查代码并说如果他们正在使用此API搜索用户，则找不到用户。

而我的感觉（如果我错了，请纠正我）是如果在服务器中成功完成调用（没有任何异常和错误），我们返回200并在响应正文中返回特定格式，如：
```
{
   "status" : boolean, // if the overall call succeeded
   "message" : string, // message from server
   "code" : integer, // code, http code or business level code 
   "data" : object,//actual data
   "type" : string, // type of the data like object, basic, array,  (basically a value from enum)
}
```
任何来电的响应代码始终为200，特定代码在响应格式的代码键中可用。

现在从客户端角度使用这些REST调用，无论是浏览器，IOS，Android还是桌面应用，我们都会调用API并检查200 < / strong>作为响应代码，我们所有进一步的功能将取决于状态＆amp;响应正文本身的代码键。再次如果响应代码本身不是200 那么它实际上是关于服务器的问题。

来到API的SDK实现，我们可以在其内部执行相同的操作，如果响应代码是，则始终检查状态和代码 200，并直接拒绝非200响应代码。

我觉得这种方法在客户端以及SDK方面的实现将更加通用和直接。

如果我错了，请纠正我？请提出一些看法。

提前致谢。

Answer 1

没有“REST标准”。

但是，有一个HTTP standard，而original definition of REST强调了客户端和服务器之间uniform interface的概念。

通过根据HTTP标准使用错误代码，可以使您的界面与其他HTTP接口更加统一。这使得在处理API时可以重用更多现有的HTTP客户端代码。

例如：

大多数客户端在收到意外状态代码时会自动停止处理响应。如果你总是发送200（OK），他们需要额外的逻辑，以免混淆。
有些客户可以在收到503 (Service Unavailable)时自动重试请求。
有些客户端可以cache HTTP响应，具体取决于他们的状态代码。

请注意，没有任何内容可以阻止您在响应有效内容中发送自定义错误代码，例如 标准HTTP状态代码。（事实上，这是一种常见的做法，它在RFC 7807中已经标准化了。）

现在，您完全有可能不需要统一的界面。正如评论所指出的那样，也许你正在构建内部的东西。

但如果您不想要统一的界面，那么您根本不需要“REST”。也许您真正需要的是RPC界面，例如JSON-RPC或gRPC。

将错误或响应代码作为错误代码

1 个答案: