REST最佳实践返回错误

Question

在RESTful中返回错误的最佳做法是什么？在HTTP状态代码4xx或响应正文？如果首先，我怎样才能改进它？

Answer 1

您的API或REST方法需要直观

首先，开发人员学会通过错误编写代码。极端编程模型的“测试优先”概念和最近的“测试驱动开发”模型代表了一系列已经发展的最佳实践，因为这是开发人员工作的一种重要且自然的方式。

从使用Web API的开发人员的角度来看，该界面另一端的所有内容都是黑盒子。因此，错误成为提供如何使用API​​的上下文和可见性的关键工具。

其次，除了他们开发应用程序之外，开发人员在他们使用您的API构建的应用程序在他们的应用程序之后进行故障排除和解决问题的关键时刻依赖于设计良好的错误。用户。

如何使用REST以实用的方式思考错误？

让我们来看看三个顶级API如何接近它。

的实

无论Facebook请求发生什么，您都会获得200状态代码 - 一切正常。许多错误消息也会下推到HTTP响应中。在这里他们也会抛出＃803错误，但没有关于＃​​803是什么或如何对它作出反应的信息。

<强> Twilio

Twilio在将错误与HTTP状态代码对齐方面做得非常出色。与Facebook一样，它们提供了更细粒度的错误消息，但有一个链接可以将您带到文档中。社区对文档的评论和讨论有助于构建一组信息，并为遇到这些错误的开发人员添加上下文。

<强> SimpleGeo

提供错误代码，但有效负载中没有其他值。 一些最佳实践

使用HTTP状态代码 使用HTTP状态代码并尝试将它们干净地映射到相关的基于标准的代码。

有超过70个HTTP状态代码。但是，大多数开发人员并没有全部记住70。因此，如果您选择不常见的状态代码，您将迫使应用程序开发人员构建他们的应用程序，而不是维基百科，以弄清楚您要告诉他们的内容。

因此，大多数API提供商使用一个小子集。例如，Google GData API仅使用10个状态代码，Netflix使用9个，而Digg仅使用8个。

您应该为API使用多少状态代码？

当你把它煮沸时，应用和API之间的互动实际上只有3个结果：

Everything worked
The application did something wrong
The API did something wrong

首先使用以下3个代码。如果您需要更多，请添加它们。但你不应该超越8。

200 - OK
404 - Not Found
500 - Internal Server Error

如果您不愿意将所有错误条件减少到这3个，请尝试在这些额外的5中进行选择：

201 - Created
304 - Not Modified
400 - Bad Request
401 - Unauthorized
403 - Forbidden

（查看所有HTTP Status codes.）

的好维基百科条目

重要的是返回的代码可以被应用程序的业务逻辑使用和操作 - 例如，在if-then-else或case语句中。

使有效负载中返回的消息尽可能详细

请详细说明。

使用简明语言描述。

添加尽可能多的提示，因为您的API团队可以考虑导致错误的原因。

我强烈建议您在说明中添加一个链接以获取更多信息，例如Twilio

取自 - https://blog.apigee.com/detail/restful_api_design_what_about_errors

其他有用的链接 http://www.restapitutorial.com/httpstatuscodes.html

REST API error return good practices