前后端通讯，必须先确定接口，那么这个接口要如何确定呢？
随意阶段
一开始也没啥规范标准，都是根据自己的习惯喜欢，系统功能的情况来制定，基本上是怎么方便怎么来。
基本的方式是按照“动作”来定义，比如 addUser、updateUser 这类的。
RESTful
有个老外看不下去了，倡导一种统一的接口风格。
大体的意思就是，先定义一种资源，比如用户，然后定义一组动作，就是增删改查。然后还有一些code建议等等风格。
于是就变成了这样：
【get】user/10 // 获取用户
【post】user // 添加用户
【put】user/10 // 修改用户
【delete】user/10 // 删除用户
话说，查询怎么表示来着？
这种方式看起来挺好，但是实践的时候就会遇到各种问题，于是你就会发现，原本开会讨论的是功能如何实现，分工如何来做，变成了讨论怎么起名才能够符合这种风格。
比如用户登录，以前可以叫做 login，那么现在要如何做呢？
【get】userOnline // 验证用户是否登录
【post】userOnline // 登录，在线用户 + 1
【delete】userOnline // 退出，在线用户 - 1
好像还可以解决。
那么如何区分物理删除、逻辑删除呢？只有一个【delete】。
或者说不需要区分了，后端自己决定？还是一刀切？
还有常见的订单，
- 生成订单
- 未付款/已付款
- 商家发货
- 物流运输
- 卖价收货
这些状态涉及三方：商家、物流、买家，这个要如何区分？还是说统统都用【put】，然后加参数识别？
想想都头疼。
还有各种不常见的功能和需求。为了符合这种风格，是不是有点太累了？
GraphQL
这种方式挺好的，但是有一点没弄明白，为啥需要前端提交一个数据结构的说明？
这是不是有点折腾呀，把这种需求说明，事先约定好，然后直接在后端保存下来不香吗？
然后制定一个编号，前端要用的时候，直接提交这个编号即可，后端获得编号，然后加载具体需求，这样是不是更便捷？
还安全，不用担心前端瞎提交结构。
到底要如何指定接口？
既然都有不足的地方，那么能不能综合一下，把优点留下，不足去掉呢？
我们可以大胆尝试一下：
- 名称方面不限制名词还是动词，合理即可
- 结构说明放在后端，前端提交对应的编号即可
- 动作可以参考使用。
- 其他待定
关于动作
这个有点纠结，可以使用，但是又不想一刀切的使用，如果设计成两类情况，一类情况需要用，另一类情况不需要用，那么这个是不是有点混乱？
其实，对于简单的增删改查，这种方式确实挺简洁的，但是复杂的就不适合了。
还有就是，似乎不是所有的前端环境都支持这些个动作，get、post肯定支持，但是其他的就不一定了。
还有，前端不仅仅是浏览器，还包括各种APP。万一有哪个环节就是不支持，怎么办？
初步设想
【模块ID】【动作ID】-【名称】
比如：
【post】10010 - addUser
【post】10020 - updateUser
【get】 10030 - deleteUser/:id
【get】 10040 - getUser/:id
【post】10050 - findUser
模块
可以基于资源设置，也可以不用，总之合理即可-
动作
包括且不限于 添加、修改、删除、查询。也不限制数量，可以有多个修改、多个删除。
可以做个约定：- 10-19 表示添加类；
- 20-29 表示修改类；
- 30-39 表示删除类；
- 40 表示依据ID获取一条记录
- 50 表示查询和分页
这样数量就不受限制了。
名称
这个主要是为了可读性，其实可以不要。
如果去掉这个名称的话也是可以运行了，只是看一堆数字，不知道是干啥的可读性比较差，有了这个名称就一目了然了。method
只需要get和post，其他的可以支持，但是不起作用。
其实动作ID和这个 method 有些类似，区别在于，我可以随意定义动作ID，没有限制。而 method 有各种限制和制约。
这样应该差不多了。
