200 get 201 post 这个一般是框架来给设定的。
401&403， If 不设置，通常不会返回这个的，
<blockquote>在REST 里状态码的含义：
404 资源没有被找到
400 params error
200 query success
201 post success[create resource success]
201 put success
401 unauthorized
403 当前资源forbidden
500 服务器内部错误，可能情况1：有一个未知的bug，
可能情况2：我知道哪里出错了，但这个和你客户端没关系，我不想让你知道我服务端有什么问题，此时也可以将状态码设置成500
</blockquote>
403的使用场景：A用户和B用户都可以访问一个api，如果A用户操作了B用户的数据，此时要返回403
有些api是把202设置为put ok，有些把put ok, post ok都设置成201
<blockquote>In http:
202 请求已经发送，服务器尚未处理</blockquote>
<blockquote>验证用户身份之传统网站和RESTful API 的区别：
传统中：使用cookie、session来保存，传递用户的身份信息。
RESTful API中：使用Token令牌来授权和验证用户身份。
cookie和Token本质来讲区别不大， 但在实现的机制上有一些区别，因为cookie很多时候是浏览器的行为，你每次访问的时候浏览器会自动携带cookie，而token的实现机制和cookie差不多，但是token在更多时候是由我们自己存储和管理，所以token更加灵活一些。</blockquote>
版本控制： api一定要有版本号
如何在tp5里实现对版本控制的支持。
学习restful api的最佳方式： 照猫画虎
豆瓣开放api 足够简单
GitHub开发者api 足够标准
标准rest在内部开发真的不好用
如果是两种不同类型的查询请求，最好是设计成2个接口，而不是把这两个查询合并到一个方法里去，如果放到一个里边去，你的多组查询条件组合在一起的话，它的URL里的传参就特备复杂，通常来说需要做一个标字位，当你标字位是1的时候，是A类查询，当标志位是2个时候，是B类查询，但是这个过程太繁琐，最好不要这样搞。
<blockquote>在内部开发中，还是不要完全做成资源型，豆瓣和GitHub的api是完全开放的，因为它不了解它的用户需求是什么，而我们自己在开发中，我们是了解自己的需求是什么。</blockquote>
