目的
开发了几个项目用了几种 API URL约定/规范。
没有好坏，顺手即可，写这个鬼，有时候有更好的方便自己对比一下。
一，方法型
其中 GET POST
或用新得 GET POST PUT DELETE 因人而异， 能用新的当然自我感觉好点
GET /article/findById 详情 ?id=1
/article/add 添加 {id:'',title:'xxxx'}
/article/list 查询 ?keyword=xxx&size=0&page=1 | title=%xxxx%&size=x&page=1 查询也能用自己公司习惯技术来衍生.
/article/edit 编辑 {id:'1',title:'bbbb'}
/article/delete 删除 [1,2,3]
/article/createByChatGpt 通过CPT创建一个文章
二，资源型/目录型一
把url当成文件来处理
这种resetful 风格基本都是 查询GET, 编辑PUT， 创建 POST，删除 DELETE
/articles/:id 详情
/articles 列表
/articles 添加 POST {id:'',title:'xxxx'}
/articles 添加 PUT {id:'1',title:'xxxx'}
/articles 删除 DELETE [1,2,3]}
/articles/:id/products 文章下面商品列表
/articles/1/products 添加 POST {id:'',goodName:'xxxx'}
/articles/1/products 修改 PUT {id:'1',goodName:'xxxx'}
如果商品下面还有，也就是有三级
/articles/:id/products/:goodsId/items
第三方调用变得有点恶心，需要在URL放入articleId 和 goodsId。用起来不舒服
Resetful风格描述非 CURD
/articles/:id/like 喜欢 POST
/articles/:id/like 取消喜欢 DELETE
/articles/add/chatgpt 通过Chatgpt 创建文章 POST {'senetance: 'xxxx'}
另外一个扩展导致我烧了CPU。例如
/articles/:id/bundles 不合理，因为bundles先于articles,
退其次 使用
bundles/:id/articles 使用中间表这周缝合 bundleArticles (类似 linux 文件管理 映射的概念)
把bundle设计成 ariticle 上级当然没问题，但是如果还有其他资源也需要有自己的集合那么就GG
当然新的业务约定是，一个功能越能兼容多的功能是更好的 满足 control v c
也就是bundles 能集合文章或产品等 。。
二，资源型/目录型二
对比起一型， 去除了URL上面 ID们, 让我们操作多级对象时 不需要去改URL，
一级对象还是遵循Resetful风格, 二级及以上去除了复数描述，也能解决articles 需要扩展bundle时可以直接放在article 目录下
/article/articles/:id 详情
/article/articles 列表
/article/articles 添加 POST {id:'',title:'xxxx'}
/article/articles 添加 PUT {id:'1',title:'xxxx'}
/article/articles 删除 DELETE [1,2,3]}
/article/products 文章下面商品列表 GET
/article/products/:id 商品详情 GET
/article/products 添加 POST {id:'',aritcleId:'1',goodName:'xxxx'}
/article/products 修改 PUT {id:'1',aritcleId:'1',goodName:'xxxx'}
/article/bundles
/article/bundles/:id
/article/bundle/articles ? bundleId=1&title=%xx%
关于API 版本
有人喜欢用 /v1/article** 这种感觉轻一点
有人喜欢在 head 里面加入version:v1 这种来进行描述，
关于业务级别/权限
基础接口使用 resources 进行管理员权限控制
动作型
/login
/login/wechat/mp
/login/weibo
/search 全局搜索
用户个人前缀
/home/**
/home/articles 我的文章
/home/notifications 我的通知
监听/第三方
/listener/wechats/:id/pay 支付事件
/listener/wechats/:id/click 点击事件
/listener/orders/status/change 状态更改
开放级别
/open/**
/open/aritcles/hots 热门文章 (也是使用 linux 映射的概念)
/open/aritcles/hots/weekly 热门文章 (也是使用 linux 映射的概念)
带权限开放接口
参考 http authorization type
URL 还没找到好的约定前缀
MVVM
如果mvvm与后台restful 同步就可以避免 url post item的时候需要手工去组装 文章id 到url里面
POST /home/articles/文章id/item
总结
还有些地方没考虑全
