RESTful

RESTful风格API的好处

1. 看Url就知道要什么资源
2. 看http method就知道针对资源干什么
3. 看http status code就知道结果如何

RESTful是面向资源的（名词）

REST 通过 URI 暴露资源时，会强调不要在 URI 中出现动词。比如：

复杂url
获取某个员工某个月的薪酬记录

/employees/{id}/salaries/{month}

用HTTP方法体现对资源的操作（动词）

• GET ： 获取、读取资源
• POST ： 添加资源
• PUT ： 修改资源
• DELETE ： 删除资源

GET
安全且幂等
获取表示
变更时获取表示（缓存）

POST
不安全且不幂等
使用服务端管理的（自动产生）的实例号创建资源
创建子资源
部分更新资源
如果没有被修改，则不过更新资源（乐观锁）

PUT
不安全但幂等
用客户端管理的实例号创建一个资源
通过替换的方式更新资源
如果未被修改，则更新资源（乐观锁）

DELETE
不安全但幂等
删除资源

HTTP状态码

通过HTTP状态码体现动作的结果,不要自定义

200 OK 
400 Bad Request 
500 Internal Server Error

RESTful的缺点
需要强调的一点是，RESTful不是一种规范，而是一种风格，它是不具有强制性的。所以风格这种东西说不准，公说公有理，婆说婆有理。就算是相同水平的程序员设计的“RESTful”也很难一样。而在开发团队中，最忌讳的就是不统一！
1、RESTful是面向资源的，所以接口都是一些名词，尤指复数名词。简单的CRUD还是很合适的，但很多业务逻辑都很难将其抽象为资源。比如说登录/登出，怎么看也不是一个资源，如果硬是抽象为创建一个session/删除一个session。这不仅反直觉，还违背了RESTful的思想。
2、RESTful只提供了基本的增删改查，对于复杂的逻辑是一点办法没有，比如批量下载、批量删除等。对于复杂的查询，更是无从下手。而且开发时会面临诸多选择，修改资源用PUT还是PETCH？采用查询参数还是用body？
3、关于错误码的问题更是复杂的一批，RESTful建议使用status code作为错误码，以便统一。在实际开发中，业务逻辑的含义数不胜数，很难统一。比如400状态码到底是表示传参有问题，还是该资源已被占用了。404是表示接口不存在，还是资源不存在。
发展到最后，开发人员的时间精力都不是用于怎么实现这个逻辑，而是变成了纠结这逻辑到底是个什么资源？把时间都给浪费掉，最后还给出了一个不伦不类的“RESTful”API。
最重要一点是RESTful与RPC没有高低之分，所有的代码规范、接口设计以及各种规定，其实都是为了在团队内部形成共识、防止个人习惯差异引起的混乱。相比之下形成JSON-RPC规范相对容易以及更方便使用。