开放型接口怎么设计

[maxio]

最近做一个系统，接了不少业务之后出现问题了，不同业务有不同的监控系统要对接，设计了接口，现在对接了两套监控系统，结果又出现了第三套监控系统，原来设计的接口又不适用了。。 感觉每次调整接口不是办法，但是后边可能还有更多的监控系统，每个调用时候的传入参数都不相同，我也没办法现在去把所有的调研一遍。 那这种情况，可以设计一个什么样的接口来应对以后的情况吗？

[loading]

这个世界没有银弹

你先兼容几个大厂吧，等大厂接口成了事实标准就好了。

[maichael]

抽象好底层，业务层做组装，由业务层来扛差异。

[Mithril]

没有接口可以应对所有情况的，哪怕你用 GraphQL 你也得看别人用不用。而且 GraphQL 也不是能应对所有变化的。
只能从设计上把接口层隔离出去，保持更底层的稳定。如果以后要应对很多不同系统，就想办法用一些脚本或者配置文件生成这一层的代码。如果就只处理几套接口那自己硬写就完了。

[qiayue]

脏活累活才是价值所在
类似 ping++

[newtype0092]

之前搞过类似的，总体来说就是分三层：
下层是完全与外部无关的，一份搞定
中间层是处理对接整体逻辑流程的，就是如果外部系统接入的逻辑步骤大致相似的，可以抽象成一套
上层是具体的接口层，对每个外部系统分别处理参数格式化之类的逻辑

这样下来是个树形结构，因为相同功能的外部系统整体逻辑不会差异太多，所以第二层基本只需要两三类，这样下来已经在保持灵活的基础上尽量减少工作量了。

[Mithril]

@newtype0092 所以说这个世界上没有什么问题是加一个中间件解决不了的，如果不行就再加一个。