当涉及从 REST API 返回错误时，我正在寻找有关良好实践的指导。我正在开发一个新的 API，所以我现在可以采取任何方向。目前我的内容类型是 XML，但我计划将来支持 JSON。
我现在添加了一些错误案例，例如客户端尝试添加新资源但已超出其存储配额。我已经在处理某些带有 HTTP 状态代码的错误情况（401 用于身份验证，403 用于授权，404 用于普通错误请求 URI）。我查看了祝福的 HTTP 错误代码，但 400-417 范围似乎都不适合报告特定于应用程序的错误。所以起初我很想用 200 OK 和一个特定的 XML 有效负载返回我的应用程序错误（即。付给我们更多的钱，你会得到你需要的存储空间！）但我停下来想它，它似乎很肥皂（/吓得耸耸肩）。此外，感觉就像我将错误响应分成不同的情况，因为有些是 http 状态代码驱动的，而另一些是内容驱动的。
那么行业建议是什么？良好实践（请解释原因！）以及，从客户端 pov 来看，REST API 中的哪种错误处理使客户端代码的工作更轻松？
所以起初我很想用 200 OK 和一个特定的 XML 有效负载返回我的应用程序错误（即。付给我们更多的钱，你会得到你需要的存储空间！）但我停下来想它，它似乎很肥皂（/吓得耸耸肩）。
除非请求确实没有任何问题，否则我不会返回 200。在RFC2616中，200 表示“请求已成功”。
如果已超出客户端的存储配额（无论出于何种原因），我将返回 403（禁止）：
服务器理解请求，但拒绝执行。授权将无济于事，并且不应重复请求。如果请求方法不是 HEAD 并且服务器希望公开请求未完成的原因，它应该在实体中描述拒绝的原因。如果服务器不希望向客户端提供此信息，则可以使用状态代码 404（未找到）来代替。
这告诉客户端请求是好的，但它失败了（200 不会做的事情）。这也使您有机会在响应正文中解释问题（及其解决方案）。
您还想到了哪些其他特定的错误情况？
