@
rabbbit 是的,这是第一个分歧点,我比较 RESTful ,endpoint 想做成 `/{组件}/{功能}`
第二个分歧点在 payload 部分,比如一个划定时间段的日程组件(`.../schedule`),对方倾向平铺 `{"monday":[{...},...],"tuesday":[...],...}`, 我是倾向规则化 `{"weekly":[{...},...],"exceptions":[...],...}`
以上两个分歧延伸到了其他接口上,再举个例子就是磁盘管理组件:
- 显示当前可用的磁盘、每个磁盘的状态
- 用户对磁盘的配置(配额、清理策略等)
- 用户执行的操作等(挂载、格式化等)
由于上面几点在原型里比较模糊,产品迟迟没有给出确定的需求,我就自己打了个草稿:
- 按功能把 endpoint 分了两级
- response body 按磁盘->分区做了结构化的组合,然后加了一些冗余字段
- 比如状态机区分:错误/格式化中/未挂载/正常/同步中/索引中
- 状态机的冗余属性:格式化中状态下代表格式化进度(类型不变)
- revision:用于将状态机与用户行为同步,比如用户请求格式化,重命名等( POST 非幂等)
- 其他冗余字段如当前分区格式等...
可能对比现有的原型确实复杂了点,之前确实也没这方面的项目经验