当涉及到REST API的返回错误时,我正在寻找关于良好实践的指导。我正在开发一个新的API,所以我现在可以把它带到任何方向。目前我的内容类型是XML,但我计划将来支持JSON。

I am now adding some error cases, like for instance a client attempts to add a new resource but has exceeded his storage quota. I am already handling certain error cases with HTTP status codes (401 for authentication, 403 for authorization and 404 for plain bad request URIs). I looked over the blessed HTTP error codes but none of the 400-417 range seems right to report application specific errors. So at first I was tempted to return my application error with 200 OK and a specific XML payload (ie. Pay us more and you'll get the storage you need!) but I stopped to think about it and it seems to soapy (/shrug in horror). Besides it feels like I'm splitting the error responses into distinct cases, as some are http status code driven and other are content driven.

那么行业建议是什么呢?好的实践(请解释为什么!),并且,从客户端角度来看,REST API中什么样的错误处理可以使客户端代码更容易?


当前回答

有两种错误。应用程序错误和HTTP错误。HTTP错误只是为了让AJAX处理程序知道一切正常,不应该用于其他任何事情。

5xx服务器错误

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates (RFC 2295 )
507 Insufficient Storage (WebDAV) (RFC 4918 )
509 Bandwidth Limit Exceeded (Apache bw/limited extension)
510 Not Extended (RFC 2774 )

2 xx成功

200 OK
201 Created
202 Accepted
203 Non-Authoritative Information (since HTTP/1.1)
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status (WebDAV)

然而,如何设计应用程序错误实际上取决于您自己。例如,Stack Overflow发送一个具有响应、数据和消息属性的对象。我认为响应包含true或false,以指示操作是否成功(通常用于写操作)。数据包含有效负载(通常用于读取操作),消息包含任何额外的元数据或有用消息(例如响应为false时的错误消息)。

其他回答

如果超出客户端配额,则是服务器错误,在本例中请避免5xx。

我知道这已经是姗姗来迟了,但是现在,在2013年,我们有了一些媒体类型来以通用的分布式(RESTful)方式处理错误。看到盾”。错误”,应用程序/盾。error+json (https://github.com/blongden/vnd.error)和“HTTP api的问题细节”,application/ Problem +json (https://datatracker.ietf.org/doc/html/draft-nottingham-http-problem-05)。

记住,有比HTTP/1.1 rfc中定义的状态码更多的状态码,IANA注册表在http://www.iana.org/assignments/http-status-codes。就你提到的情况来说状态码507听起来不错。

同意了。REST的基本理念是使用web基础设施。HTTP状态代码是消息传递框架,允许各方在不增加HTTP有效负载的情况下相互通信。它们已经是传递响应状态的通用代码,因此,要真正实现RESTful,应用程序必须使用这个框架来通信响应状态。

在HTTP 200信封中发送错误响应具有误导性,并迫使客户端(api使用者)解析消息,很可能以非标准或专有的方式。这也是低效的——您将迫使您的客户端每次都解析HTTP有效负载以了解“真实的”响应状态。这增加了处理,增加了延迟,并为客户端创建了一个出错的环境。

为你的API选择正确的HTTP错误代码的一个很好的资源: http://www.codetinkerer.com/2015/12/04/choosing-an-http-status-code.html

文章节选如下:

从哪里开始:

2XX / 3XX:

4XX:

5XX: