Restful API设计规范：响应码

和别人合作开发过许多项目，也看别人开发过很多项目，发现前后端总会在数据对接的方面产生摩擦。轻则互相推卸责任，重则当众谩骂。

今天把别人整理好的一个关于Restful设计的响应码部分摘录，再结合自己的开发经验，总结写个东西，以备后用。

原文连接：简洁 RESTful API 设计规范！整个人都清爽了！——公众号“程序员晓梦”

---

操作成功状态码

操作成功状态码以2开头，是2xx的形式。可以根据不同方法返回更精确的状态码。

请求方法	状态码	含义	解释
GET	200	OK
POST	201	Created	创建资源成功
PUT	200	OK
PATCH	200	OK
DELETE	204	No Content	删除成功，查询已不存在

客户端错误状态码

客户端状态码为4xx形式，主要用来提示客户端相关错误。（这里的错误是服务器端的主观判断）

状态码	信息	解释
400	Bad Request	服务器不能解析客户端的请求
401	Unauthorized	用户未验证身份（即未登录）
403	Forbidden	用户不具有该资源访问权限（已登录）
404	Not Found	所请求资源不存在或不可用（临时）
405	Method Not Allowed	用户不具有该HTTP方法的权限（已登录）
410	Gone	所请求资源不存在或不可用（永久）
415	Unsupported Media Type	客户端要求返回的格式不支持，如接口只支持JSON，但客户端要求返回XML
422	Unprocessable Entity	客户端上传的附件无法处理
429	Too Many Request	客户端的请求次数超过限额

服务端错误状态码

服务端错误状态码是5xx的形式。但是出于保护的原因，一般情况下，服务端不会向客户端泄露过多错误细节，所以总的来说，服务端错误状态码在生产环境中只有两个是比较常用的。

状态码	信息	解释
500	Internal Server Error	客户端请求有效，服务器处理时发生了意外
503	Service Unavailable	服务器无法处理请求，一般用于网站维护状态

---

总的来说，我觉得上面的状态码已经足够前后端分离时使用了。大家都遵循这套规则，就可以节省很多沟通成本。

当然，最关键的是，前端和服务端都需要有可以生成/解析这套状态码的工具！！这也算是基础建设中的一部分吧……