(四) 错误代码和错误信息的处理 - Build API For Your Company 系列

介绍

异常处理 是必须处理的一块内容，当发生错误时（用户提交无效的请求、服务器出错等等），我们需要让用户知道什么地方出错了，没有任何错误反馈是很让人无语的。目前主要采用这两种方式来处理异常：

• HTTP Status Codes
• Custom error codes and messages

HTTP 状态码概要 (200-507)：

2xx -- All about success － 用户请求被接受并返回响应
200 - Generic everything is ok.
201 - Creating something is ok.
202 - 请求被接受并返回响应，但是会被异步处理
204 - No Content

3xx -- All about redirection
301 - 永久性的重定向
303 - See other

4xx -- All about client errors 
这些状态码意味着客户端做了一些错误或者无效的操作，需要用户在发送数据之前重新检查数据；
400 - Wrong Request.
401 - Unauthorized.
403 - The current user is Forbidden from acessing the data.
404 - The URL is not a valid route, or item resource does
    not exist.
405 - Method Not Allowed
410 - Data has been deleted, deactived, suspended, etc.

5xx - All about server errors -- 意味着服务发生了状况，例如数据库链接失败，业务逻辑出错等等；
500 - Something unexpected happened and it is the APIs fault.
503 - API is not here right now. Please try later.

如果你维护服务器（Nginx），可能会对 502 这个代码有印象，它表示你的 PHP-FPM 出错了。507 可能意味着你的硬盘挂了。

上面只是一些常用的状态码，如果你想参考一下完整的状态码解释列表，在这里 REST && WOA Wiki 。

还有一篇不错的文章推荐给你： Using HTTP status codes in a REST service

状态码的 RFC(2616) 标准：
http://www.rfc-editor.org/rfc/rfc2616.txt

自定义的错误代码和错误信息

HTTP 状态码有时候满足不了我们的需求，所以有些应用的API会自己定义一套错误代码来记录处理错误信息（这样处理的时候也更方便，更直观，但是需要去维护，个人观点），这些一般都会记录在API文档里面：

{"errors":[{"message":"Sorry, that page does not exist","code":34}]}

这是 twitter 的错误响应返回格式， 可以在它的开发者官网看到详细的解释：

https://dev.twitter.com/overview/api/respo...

这种格式个人认为还是非常不错的，实际开发中很方便。

当然在 laravel 中有很棒的扩展包帮助我们规范这些流程 Dingo , 你可以先去浏览一下这个包的 wiki，以后的系列中也会再说到这个包的使用的

https://github.com/dingo/api/wiki

Say Something

本来说是在这篇文章里面讲 POST MAN 和其他的一些测试工具的，但是看来放到下篇 接口测试 的文章里其实更合适，嘿嘿。最近毕业一大堆事情要忙，时间紧迫啊。但是还是会把 Laravel 聚会 给办起来的，大神，给我力量吧。。