工作需要打通 ERP 和一个 SaaS 的人力资源系统（这里暂时不提名字）。
需求非常之简单：要从人力资源系统读取某个部门所有人员的薪资。
把接口需求发给该人力资源系统（简称 B 公司），B 公司直接拒绝，说他们的开放 api 没这个功能，不能限定某个部门的人员，只能查询全部。
因为人员薪资不能全员公开，所以我们退而求其次，打算开发一个中间服务，调用 B 公司的接口读取全员薪资后，过滤出来特定部门的数据再转发。
然后仔细研究 B 公司的接口文档后发现，居然没有查询全员的接口，提供的方案只有两个接口：
一是组织部门的变更历史记录，可以输入时段查询；
二是全员的变更历史记录，可以输入时段查询；
B 公司建议接口调用者调用这两个接口遍历所有变更后，在外部建立人员和部门的数据并保持跟 B 公司系统同步，其他接口只能在外部数据中查询。
完全颠覆了我对接口的认知。
以上吐槽不是重点，在 v2 来问一下，是不是这是 SaaS 的某种接口设计最佳实践？
不再提供实时数据查询，只提供变更记录查询，我猜测可以减低对数据服务的同步压力。
我见识少，各位彦祖说说其他 SaaS 厂商的接口也这个风格吗？
需求非常之简单：要从人力资源系统读取某个部门所有人员的薪资。
把接口需求发给该人力资源系统（简称 B 公司），B 公司直接拒绝，说他们的开放 api 没这个功能，不能限定某个部门的人员，只能查询全部。
因为人员薪资不能全员公开，所以我们退而求其次，打算开发一个中间服务，调用 B 公司的接口读取全员薪资后，过滤出来特定部门的数据再转发。
然后仔细研究 B 公司的接口文档后发现，居然没有查询全员的接口，提供的方案只有两个接口：
一是组织部门的变更历史记录，可以输入时段查询；
二是全员的变更历史记录，可以输入时段查询；
B 公司建议接口调用者调用这两个接口遍历所有变更后，在外部建立人员和部门的数据并保持跟 B 公司系统同步，其他接口只能在外部数据中查询。
完全颠覆了我对接口的认知。
以上吐槽不是重点，在 v2 来问一下，是不是这是 SaaS 的某种接口设计最佳实践？
不再提供实时数据查询，只提供变更记录查询，我猜测可以减低对数据服务的同步压力。
我见识少，各位彦祖说说其他 SaaS 厂商的接口也这个风格吗？
Select Language