简要说一下REST API也是我们常说的RESTful API，是一套规范，指导我们通过Http协议方法隐射到对应的业务逻辑。
标准规范如下：
| 方法 | 描述 |
|---|---|
| GET | 用于查询操作，对应于数据库的 select 操作 |
| PUT | 用于所有的信息更新，对应于数据库的 update 操作 |
| DELETE | 用于更新操作，对应于数据库的 delete 操作 |
| POST | 用于新增操作，对应于数据库的 insert 操作 |
| HEAD | 用于返回一个资源对象的“元数据”，或是用于探测API是否健康 |
| PATCH | 用于局部信息的更新，对应于数据库的 update 操作 |
| OPTIONS | 获取API的相关的信息。 |
在开发过程中，团队慢慢的养成了一个习惯，所有的接口的采用POST进行操作。
团队大部分同事都有这么一个辩解：因为业务逻辑是由后端同事进行处理的，并不需要GET（查询）、DELETE（删除）、POST（新增）、PUT（全部更新）对应这么细，且有时候业务并不单单对应数据库的CURD，这样反而采用RESTful是否过于复杂了。
其实，RESTful API不仅仅只是指业务的CURD，还需要做到幂等、流控、读写分离等处理。这些往往在业务提供者的上一层进行处理，如果通过GET、DELETE这样的逻辑进行区分，会比读熟了API逻辑再进行区分容易得多。
写这个文章主要是再一次提醒自己按标准来，让他人更能理解到自己创造的东西，而不是为了自己。