目的

开发了几个项目用了几种 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

总结

还有些地方没考虑全