RESTful API：是否要放置自定义应用程序错误？

Question

因此，我们在公司内部就是否将自定义错误代码放在HTTP头或正文中展开了热烈讨论。我们在谷歌上搜索了很多，但还没有找到确切的答案。

情况是这样的:

团队 A 在发生应用程序错误时使用 HTTP 错误代码（如 401、403 和 404），并在正文中显示自定义错误代码和说明。（执行此 Stripe 和 Twitter 的 API 示例）

团队 B 如果发生真正的 HTTP 错误，则让 HTTP 标头为 401、404 或其他。除此之外，一直使用HTTP 200，如果有任何应用程序错误，请仅将其放在正文中。换句话说，不要对应用程序自定义错误使用 HTTP 标头。（API做这个Facebook的例子）

您认为哪一个是最佳实践，为什么？

谢谢。

Answer 1

响应代码:RFC 2616定义了41个HTTP响应代码。其中一些对我们的目的没有用，但是总的来说，它们代表了一组基本的语义，在所有API标准中最基本的定义。没有理由忽视这份礼物。如果你为你的API重新发明404(未找到)或409(冲突)，你只是为每个人创造了更多的工作。使用你的回应代码。如果客户端向您的API发送了一些错误数据，您应该发送响应代码400(错误请求)和一个解释问题所在的实体。不要发送带有错误信息的200 (OK)。你在对客户撒谎。你必须写e

参考：Leonard Richardson、Mike Amundsen和Sam Ruby RESTful Web API 2013(http://www.amazon.com/RESTful-Web-APIs-Leonard-Richardson/dp/1449358063/ref=sr_1_1?ie=UTF8

Answer 2

在REST中，HTTP不应该仅仅被视为嵌入协议（SOAP的方法）的“传输”层。您必须利用HTTP功能，如：

• 资源
• 方法
• 状态代码
• 内容协商
• ...

RESTful服务需要利用HTTP状态代码来告诉客户端请求是否被成功处理。没有真实或不真实的HTTP状态。

例如：

< li >对于状态代码< code>404，这意味着该资源不存在。对于像< code>GET /contacts/1这样的路径，这可能对应于在数据库中找不到id为< code>1的联系人的事实。 < li >对于状态代码< code>400或< code>422，这可能意味着提供的数据不正确。如果您尝试添加联系人< code>POST /contacts/，但在响应有效负载< code>{ "email": "test" }中提供了格式错误的电子邮件。

但除此之外，您可以在响应有效负载中添加更多详细信息。HTTP状态对于您的需求来说可能过于通用，并且超文本标记语言中的默认消息对于服务调用者来说并不真正可用。例如，对于状态代码400或422，您可以拥有：

400 
{
  "messages": [
    {
      "field":"email",
      "message":"The format of the email isn't correct.",
      "type":"error"
    }
  ]
}

或许这个链接可以给出更多的提示:https://templ th . WordPress . com/2014/12/15/designing-a-we b-API/。参见“处理错误”一节。

希望能帮到你蒂埃里

Answer 3

我想说两者都不是真正的最佳实践，这取决于您想要的api设计类型。如果您正在进行REAL REST，而不是某种弱近似，那么团队A是唯一真正的选择。如果Facebook确实在任何地方都使用200 OK以及嵌入的错误代码，那么Facebook部署的不是真正的REST服务。

REST的要点是，如果你对某件事做一个GET请求，你将收到该资源的完整表示。如果您执行 GET 请求，并且收到 200 OK 以及其正文中的错误，则暗示您实际上并没有做错某些操作，但该资源是错误的表示形式...这有点奇怪，但我想这并非不可能。

同样，如果我执行 DELETE 或 PUT 请求，并且收到 200 OK，则客户端必须假定该请求 100% 成功。如果操作不成功，则不得返回 200-299 HTTP 状态代码。

这是REST的最佳实践，但REST并不是唯一的范例。肯定还有其他API风格使用HTTP更像“隧道”来执行类似RPC的操作。Facebook就是这样做的，XML-RPC和SOAP是其他的例子，但还有很多其他的例子。

所以简短的回答是:如果你Rest，那么你必须使用正确的状态代码。