这是一个创建于 1276 天前的主题，其中的信息可能已经有所发展或是发生改变。
工作需要打通 ERP 和一个 SaaS 的人力资源系统（这里暂时不提名字）。
需求非常之简单：要从人力资源系统读取某个部门所有人员的薪资。
把接口需求发给该人力资源系统（简称 B 公司），B 公司直接拒绝，说他们的开放 api 没这个功能，不能限定某个部门的人员，只能查询全部。
因为人员薪资不能全员公开，所以我们退而求其次，打算开发一个中间服务，调用 B 公司的接口读取全员薪资后，过滤出来特定部门的数据再转发。
然后仔细研究 B 公司的接口文档后发现，居然没有查询全员的接口，提供的方案只有两个接口：
一是组织部门的变更历史记录，可以输入时段查询；
二是全员的变更历史记录，可以输入时段查询；
B 公司建议接口调用者调用这两个接口遍历所有变更后，在外部建立人员和部门的数据并保持跟 B 公司系统同步，其他接口只能在外部数据中查询。
完全颠覆了我对接口的认知。
以上吐槽不是重点，在 v2 来问一下，是不是这是 SaaS 的某种接口设计最佳实践？
不再提供实时数据查询，只提供变更记录查询，我猜测可以减低对数据服务的同步压力。
我见识少，各位彦祖说说其他 SaaS 厂商的接口也这个风格吗？
需求非常之简单：要从人力资源系统读取某个部门所有人员的薪资。
把接口需求发给该人力资源系统（简称 B 公司），B 公司直接拒绝，说他们的开放 api 没这个功能，不能限定某个部门的人员，只能查询全部。
因为人员薪资不能全员公开，所以我们退而求其次，打算开发一个中间服务，调用 B 公司的接口读取全员薪资后，过滤出来特定部门的数据再转发。
然后仔细研究 B 公司的接口文档后发现，居然没有查询全员的接口，提供的方案只有两个接口：
一是组织部门的变更历史记录，可以输入时段查询；
二是全员的变更历史记录，可以输入时段查询；
B 公司建议接口调用者调用这两个接口遍历所有变更后，在外部建立人员和部门的数据并保持跟 B 公司系统同步，其他接口只能在外部数据中查询。
完全颠覆了我对接口的认知。
以上吐槽不是重点，在 v2 来问一下，是不是这是 SaaS 的某种接口设计最佳实践？
不再提供实时数据查询，只提供变更记录查询，我猜测可以减低对数据服务的同步压力。
我见识少，各位彦祖说说其他 SaaS 厂商的接口也这个风格吗？
 |
1
shyrock OP 我天，技术问题没人回了吗。。。
|
 |
2
Rheinmetal 2021-06-03 19:13:15 +08:00
这不就是合并 diff 么 重新实现一个 git 呗 我看挺好
|
|
3
shyrock OP @Rheinmetal #2 我是甲方，要求乙方给接口，他就给个 diff，拒不提供更方便的接口，付费也不干。。。所以好奇这是新的接口规范吗？
|
Select Language