API设计之道：从商户ID参数设计 看 对外商户API与内部中台服务 的参数设计理念的差异

我司零工结算平台的系统架构模式是：

前端的bosskg业务线 -----→ 中台的RPC服务 -----→ 后端的税地服务商系统

其中，bosskg为合作商户提供了HTTP形式的结算付款API接口，中台RPC服务“zhongtai-trans”为bosskg等业务线提供RPC付款交易服务。

以结算查询来讲，

• bosskg为每个合作商户提供一个商户id。
  bosskg的商户结算查询API，请求参数会包括商户id属性、商户侧结算单号，这不难理解。

• zhongtai-trans是一个中台微服务，为bosskg、youfu、hrtech等业务线（我们称为business_line）提供结算付款交易能力。
  zhongtai-trans的付款查询RPCAPI，包含业务线（business_line）、业务线侧结算单号。

基于上面的系统关系，我们现在思考这么一个场景：zhongtai-trans的付款查询RPCAPI，这2个参数已经完全满足业务线系统的查询需要。为防止个别开发者或系统随意调用，我们要考虑从增加额外请求参数来加一道安全门槛。是否可以借鉴bosskg商户API的模式，也增加一个商户id的入参呢？

加是可以的。

不过，增加这个商户id，不能理解为是借鉴bosskg的设计理念。

为什么？

我们得理解bosskg提供的API与zhongtai-trans提供的API的职责所在。

• 首先要明确，bosskg提供的API是什么？ 
  是商户API。是为外部商户系统提供的HTTP网络对接接口。显然，付款查询API显然要包含商户id、商户结算单号（或平台结算单号）。

• zhongtai-trans提供的API呢？
  要明确，zhongtai服务是为谁服务的？
  是为bosskg、设计云、hrtech等业务线系统服务的。因此，zhongtai-trans提供的付款查询API，有结算单号和业务线属性即可。如果出于安全的考虑，可以通过增加参数的方式提高正确调用的门槛，可以增加商户id、结算金额、结算日期等字段。

有思想、知章法，才能做出更好的系统！
正如本案例，对外API的设计与对内API的设计有不同的职责和考量。通过增加商户id达到了解决RPCAPI非正当调用的效果，不过，合理的设计理念的出发点，还是很重要的。