@rabbbit 嗯，我确实复杂化了。

不过我上面还有一层意思是，冗余设计覆盖到了我能想到的产品那边的未来需求：比如之后储存组件需求变化，大概率后端不需要任何调整（ e.g. 加个进度条，增删合并分区，安全弹出之类的），只是前端来调整对后端接口的使用就好。

不过反思了下我这种冗余设计确实不妥，相当于把 OS 的接口间接暴露给前端了，还是应该先等原型改完再定。

@fregie 这点其实我也是认同对方的，这样双方都轻松一些，后面开会对的时候明确好责任就好，有时候把事情简单化更难。

@rabbbit 是的，这是第一个分歧点，我比较 RESTful ，endpoint 想做成 `/{组件}/{功能}`

第二个分歧点在 payload 部分，比如一个划定时间段的日程组件（`.../schedule`），对方倾向平铺 `{"monday":[{...},...],"tuesday":[...],...}`, 我是倾向规则化 `{"weekly":[{...},...],"exceptions":[...],...}`

以上两个分歧延伸到了其他接口上，再举个例子就是磁盘管理组件：

- 显示当前可用的磁盘、每个磁盘的状态
- 用户对磁盘的配置（配额、清理策略等）
- 用户执行的操作等（挂载、格式化等）

由于上面几点在原型里比较模糊，产品迟迟没有给出确定的需求，我就自己打了个草稿：

- 按功能把 endpoint 分了两级
- response body 按磁盘->分区做了结构化的组合，然后加了一些冗余字段
- 比如状态机区分：错误/格式化中/未挂载/正常/同步中/索引中
- 状态机的冗余属性：格式化中状态下代表格式化进度（类型不变）
- revision：用于将状态机与用户行为同步，比如用户请求格式化，重命名等（ POST 非幂等）
- 其他冗余字段如当前分区格式等...

可能对比现有的原型确实复杂了点，之前确实也没这方面的项目经验

@CivAx 谢谢，我等 workday 先电话过去问问再决定要不要麻烦您吧。方便的话也可先加个好友 V2VDaGF0IElEOiBVbmJpbmlsaXVt

@Lintech 试了移动香港，visa/amex 两张外币卡都不让 Pickup ，去年首发、期间买配件 Pickup 都没问题，只能先问问客服了🫠

@MacsedProtoss 不太像，据观察 19-20 号从昨天到今天可用的时间窗一直在减少，目前 20-21 还有大量的时间窗能 Pickup ，昨晚和今天我都试了好几次，确认过被拒绝后原来的时间窗还是能 Pickup 的

@Lintech 不知道这种情况找客服 argue 有用吗？还是说要等一段时间呢？