REST API错误返回良好实践 [英] REST API error return good practices

问题描述

我正在寻找有关从REST API返回错误的良好做法的指导。我正在开发一个新的API，所以我现在可以采取任何方向。我的内容类型目前是XML，但我计划在将来支持JSON。

I'm looking for guidance on good practices when it comes to return errors from a REST API. I'm working on a new API so I can take it any direction right now. My content type is XML at the moment, but I plan to support JSON in future.

我现在正在添加一些错误案例，例如客户端尝试添加一个新资源，但已超过他的存储配额。我已经使用HTTP状态代码处理某些错误情况（401用于身份验证，403用于授权，404用于普通错误请求URI）。我查看了有福的HTTP错误代码，但400-417范围似乎没有报告特定于应用程序的错误。所以起初我很想用200 OK和特定的XML有效载荷返回我的应用程序错误（即付给我们更多，你将得到你需要的存储空间！）但我停下来想一想它似乎肥皂（/耸耸肩恐怖）。除此之外我觉得我将错误响应分成不同的情况，因为有些是http状态代码驱动而其他是内容驱动。

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.

那么行业建议是什么？好的做法（请解释原因！）以及从客户端pov中，REST API中的哪种错误处理使客户端代码的生活更轻松？

So what is the industry recommendations? Good practices (please explain why!) and also, from a client pov, what kind of error handling in the REST API makes life easier for the client code?

推荐答案

所以起初我很想用200 OK和特定的XML有效载荷返回我的应用程序错误（即付给我们更多，你将得到你需要的存储空间！ ）但我停下来思考它似乎肥皂（/耸耸肩恐怖）。

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).

我不会返回200除非这个请求确实没有任何问题。从 RFC2616 中，200表示请求已成功。

I wouldn't return a 200 unless there really was nothing wrong with the request. From RFC2616, 200 means "the request has succeeded."

如果超出了客户的存储配额（无论出于何种原因），我将返回403（禁止）：

If the client's storage quota has been exceeded (for whatever reason), I'd return a 403 (Forbidden):

服务器理解请求，但拒绝履行请求。授权无效，请求不应重复。如果请求方法不是HEAD并且服务器希望公开为什么请求没有得到满足，那么它应该描述实体中拒绝的原因。如果服务器不希望将此信息提供给客户端，则可以使用状态代码404（未找到）。

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

这告诉客户端请求是正常的，但它失败了（200不做的事情）。这也让您有机会在响应正文中解释问题（及其解决方案）。

This tells the client that the request was OK, but that it failed (something a 200 doesn't do). This also gives you the opportunity to explain the problem (and its solution) in the response body.

您还有其他具体的错误条件吗？

What other specific error conditions did you have in mind?

这篇关于REST API错误返回良好实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！