您始终可以定义自己的错误并对其进行自定义。请点击以下链接了解更多信息,
http://blogs.mulesoft.com/dev/api-dev/api-best-practices-response-handling/
以下是相同的内容:
使用 HTTP 状态码
最常被误用的 HTTP 状态代码之一是 200 – ok 或请求成功。令人惊讶的是,您会发现很多 API 在创建对象时使用 200(状态码 201),甚至在响应失败时:
无效200
在上述情况下,如果开发人员仅仅依靠状态码来查看请求是否成功,程序将继续没有意识到请求失败并且它做错了什么。如果程序中存在对该记录的依赖关系,这一点尤其重要。相反,要使用的正确状态代码应该是 400,表示“错误请求”。
通过使用正确的状态代码,开发人员可以快速查看应用程序发生的情况并“快速检查”错误,而无需依赖正文的响应。
您可以在 HTTP/1.1 RFC 中找到完整的状态码列表,但为了快速参考,以下是一些最常用的 RESTful API 状态码:
200 正常
201 已创建
304 未修改
400 错误请求
401 未授权
403 禁止
404 页面/资源未找到
405 方法不允许
415 不支持的媒体类型
500 内部服务器错误
当然,如果您想真正发挥创造力,您可以随时利用状态码:
第418章 我是个茶壶
请务必注意,Twitter 著名的 420 状态代码 - 增强你的平静,并不是真正的标准化响应,对于太多请求,您可能应该坚持使用状态代码 429。
使用描述性错误消息
同样,状态码可帮助开发人员快速识别调用结果,从而快速检查成功和失败。但在失败的情况下,确保开发人员了解调用失败的原因也很重要。这对于您的 API 的初始集成(请记住,您的 API 越容易集成,人们就越有可能使用它)以及出现错误或其他问题时的常规维护尤其重要。
您会希望您的错误正文格式正确且具有描述性。这意味着告诉开发人员发生了什么,为什么会发生,最重要的是——如何修复它。您应该避免使用通用或非描述性错误消息,例如:
redx 您的请求无法完成
redx 发生错误
redx 无效请求
通用错误消息是 API 集成的最大障碍之一,因为开发人员可能会花费数小时试图找出调用失败的原因,甚至完全误解错误消息的意图。最终,如果他们无法弄清楚,他们可能会完全停止尝试。
例如,我在一个 API 上挣扎了大约 30 分钟,试图弄清楚为什么我会收到“不允许此调用”错误响应。在反复重新格式化我的请求并尝试不同的方法后,我终于打电话给支持人员(心情非常沮丧),却发现它指的是我的访问令牌,由于我无法复制和粘贴,它恰好是一个字母这样的事情。
同样,“无效的访问令牌”响应会为我省去很多麻烦,并且在在线获得支持时不会觉得自己像个彻头彻尾的白痴。它还可以为他们节省宝贵的时间来解决真正的错误,而不是尝试排除最基本的步骤(顺便说一句——每当我遇到错误时,我现在首先检查密钥和令牌)。
以下是描述性错误消息的更多示例:
greencheckmark Your API Key is Invalid, Generate a Valid API Key at http://...
greencheckmark 此操作需要用户 ID。在 http://...
上阅读更多信息
greencheckmark 您的 JSON 格式不正确。在此处查看示例 JSON:http://...
但您可以走得更远,请记住 - 您需要告诉开发人员发生了什么、为什么会发生以及如何解决它。最好的方法之一是使用标准化的错误格式进行响应,该格式返回代码(供支持参考)、所发生情况的描述以及指向相应文档的链接,以便他们可以了解更多/修复它:
{
“错误” : {
“代码”:“e3526”,
"message" : "缺少用户 ID",
"description" : "编辑用户需要 UserID。",
“链接”:“http://docs.mysite.com/errors/e3526/”
}
}
在支持和开发方面,通过这样做,您还可以跟踪这些页面的点击量,以了解哪些区域对您的用户来说更麻烦 - 让您能够提供更好的文档/构建更好的 API。