前后端数据交互，经常要和 Api 打交道，于是关于 Api 接口的设计，有必要好好写一写
Restful api 风格
首先还是得说一下REST 是设计风格而不是标准，也就是在写 api 接口的时候，喜欢就遵循。
这里举一个常见的 api 接口设计
常见的 CRUD 操作
POST /user/list // 获取列表
POST /user/get // 获取用户
POST /user/add // 添加用户
POST /user/edit // 编辑用户
POST /user/delete // 删除用户
与之对应 Restful Api 风格
GET / user // 获取列表
GET / user / { id } // 获取用户
POST / user // 添加用户
PUT / user / { id } // 编辑用户
DELETE / user / { id } // 删除用户
// {id} 通过后端路由 参数Params可以获取到
可以看到 Restful 风格相比于正常的 POST 而言，少了请求的路径，而同时使用请求方法字段（GET,POST,PUT,DELETE） 要与之表明的意思也很明确（前提：在增删改查的时候），也就只是增删改查而已。
我何时使用 Restful
这里我要说说我个人使用情况下，如果单单只是增删改查的话，我会使用 Restful 风格，好用是一方面，不必在修改数据的还要在 body 中添加 id 这个字段。其次 restful 确实也算广泛，但也仅仅只是在增删改查中。
实际业务中复杂情况太多了，有的时候仅仅这四个请求方法不能很明确的表达所要的意思，例如下面一些业务逻辑
POST user/login 发送登录请求
POST user/register 发送注册请求
POST user/info 获取个人信息
POST user/forget 忘记个人密码
POST user/getCode 获取验证码
此外还有充值，获取消费记录、登录记录等等就不一一列举了，总之这时候我毫不犹豫会使用 POST，可能有人会好奇，为啥获取信息和获取验证码的时候要使用 POST 请求，用 GET 不好吗？好，但后文会说为什么。
易猜测 api 接口
实际上，采用了 Restful 风格，几乎一猜就能猜到对应的 api。比如商品管理，无非就是获取商品列表，添加商品，编辑商品，删除商品。同时又传入的是对应的 ID，这要是 Mysql，ID 基本都是按顺序的，万一 api 鉴权没做好，都不知道数据怎么变动的。当然这种情况一般都是比较少见的了。
不易加密
上文不是说到为啥都要使用 POST 请求，原因也挺简单的，就是加密，GET 请求一般都不会携带过多参数，针对数据效验的话最多也就一个 MD5 效验，然而是远远不够的，而 POST 所能携带的数据不仅仅是 MD5 效验，还能携带风控算法，二次效验，浏览器指纹算法等等，能保证一定的防破解性。一些看似用 GET 请求方便的接口，但实际都要考虑所包含的风险，就如上面那个发送验证码的接口，如果不加以加密，特别容易仿造出与之对应的协议请求，再次仿造发送也不难。当然，对于这种限制类的业务，还是得要后端进行限制，例如 1 分钟只能发送一条，一天一号只能发送 10 条。
最后
其实可以发现绝大多数的网站基本上都不是采用 Restful 风格（貌似用的最多的也就是管理系统了），因为所涉及的业务逻辑实在是太复杂了，不单单只能使用请求方法来表明意思，有时候 Url 路径更能表达明确意思。
Restful 风格想的太美好了，然而实际业务中 很多时候并不能单纯的通过 get post put delete 这四种请求发送来表明真实意义，所以我在增删改查的时候才会使用 Restful api 风格。
在我写项目中遇到一些复杂业务逻辑，我是毫不犹豫使用 Post 请求的，然后通过 url 路径表明 api 所要请求的路径，同时编写 Swagger Api 文档。什么样的风格都因人而异，主要自己用的习惯就行，毕竟 api 接口只是风格，并不作为标准来衡量。