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

我们来看一个案例。

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

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

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

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

 

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

 

那么,下面两种实现,你选择哪一种?

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

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

Why?

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

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

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

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

 

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

 

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

 

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