程序实现--对外接口可不仅仅是“给大佬递餐”，前置工作还是要做滴

我们来看一个案例。

前端页面上，用户在订单详情页确认完信息后，点击“确认支付”，发起余额支付。

这里，我们做如下3项假定。

1）后台程序暴露的“支付”Rest接口名为 order/pay。

2）后台程序对于“支付”的处理逻辑，我们简化成下面的业务流程。

3）后台程序是微服务结构，包括提供RestAPI接口的springmvc服务和后面的订单服务、账户服务。

那么，下面两种实现，你选择哪一种？

 比较上面两种实现方式，第一种是在order/pay这个rest接口里先校验订单状态，通过后才调用订单服务的“支付订单”接口。 第二种是直接转发请求给订单服务的“支付订单”接口。

相比来说，第一种更靠谱一些。

Why？

看上去，虽然两种实现方式都能达到目的，第一种方式还多了一个前置的校验。为什么我建议采用第一种方式呢？

这是典型的程序业务处理的方式。——接收到请求入参后，先进行前置校验，如果校验失败直接终止返回，否则才走后面的业务处理流程。

有同学就说了，直接调用订单服务的“支付订单”接口，“支付订单”接口的实现里不是也有订单状态的前置校验吗？

从技术的角度来说，这是有区别的。“支付订单”作为一个业务处理接口，我们要做的控制会比较多，例如日志、耗时、幂等、锁等。因此，从这个角度来说，在需要支付订单的时候再调用，是不是更合理呢？

类似的案例，也包括，我们的mq消费者，在从队列里拿到消息后，先进行必要的判断和校验，然后再调用业务方法。而不是一上来就直接把参数丢给业务方法。

本文设计文稿自：https://www.processon.com/view/link/611e38c2e0b34d3511f7c479

热门相关：名门盛婚：首席，别来无恙！   楚氏赘婿   我成了暴戾帝君的小娇包   网游三国之城市攻略   楚氏赘婿