前后端分离，对后端接口设计的思考

客官°小女子只卖身不卖艺 2023-06-07 12:11 31阅读 0赞

#### 背景 ####

1.  一线城市很多公司都实现了前后端分离的开发模式。除去所谓的Restful接口设计模式，如何来设计接口呢？
2.  基本信息：项目有中文版和英文版，也有稳定区和创新区，这里的稳定区和创新区只是一个业务逻辑上的一个概念。
3.  需求：我们需要查询项目，而条件是中文还是英文，稳定区还是创新区。
4.  这里主要分析是通过接口类别来隔离业务逻辑，还是通过一个接口的参数不同来区分业务类别呢？

--------------------

#### 过程 ####

**思路一**：后台接口设计，采用完全隔离的方式。  
1， 稳定区的中文项目一个接口。  
2， 稳定区的英文项目一个接口。  
3， 创新区的中文项目一个接口。  
4， 创新区的英文项目一个接口。

优点：如果把具体的接口设计，当成一个类的话，引起类变化的原因就一个都没有了。而且在理解起来，非常简单。真正意义上做到了完全隔离。

缺点：代码会有重复逻辑结构。并且接口太多，繁琐。

--------------------

**其实，很多开发者，会问为什么不抽象一下呢？**

**思路二**：后台接口设计，采用只有一个原因引起类的变化。  
1， 稳定区项目一个接口，需要参数分类是中文或者英文。  
2， 创新区项目一个接口，需要参数分类是中文或者英文。

优点：如果把接口设计理解成一个类的话，引起类变化的原因就只有一个。好理解，简单。控制逻辑需要写一个判断，业务逻辑也需要一个判断。这里判断的原因就是不同的逻辑有不同的具体实现过程。

缺点：如果还有新项目添加的情况，会修改原来的代码，至少会添加一个判断。这样就违背开闭设计原则。不仅，有新类型项目添加，也有可能有新语言类型添加，这样需要在原来的逻辑上进行修改。

--------------------

**继续抽象。**

**思路三**：后台接口设计，采用有两个原因引起类的变化。（项目类型和中英文版本）  
一个接口，需要参数中文还是英文，稳定还是创新。

优点：接口从4个减少到1个了。

缺点：一个业务逻辑中，有很多控制逻辑，如果不小心把**控制逻辑结构**和**业务逻辑结构**混杂在一起了，当接口出现bug,我们在调试程序的时候，需要判断当前参数是稳定项目还是创新项目是中文还是英文。至少需要跟前端同事进行一系列沟通，而沟通是一件很浪费时间的事情。当然，我们可以小心地把判断逻辑隔离出来，抽象成一个小小的功能函数，把业务逻辑给抽离出来。这样在排查问题的时候，会好很多。但是，跟前台沟通的成本是减少不了。

--------------------

**思考**：

1.  无论是哪种实现方式，都应该把控制逻辑小心地抽离出来，把功能逻辑抽离出来。
2.  是思路一好呢，还是思路二好呢？如果从类的角度来思考的话，思路二比较好，只有一个参变量。也就是不能没有参数类型。但也不能像思路三那样参数太多。因为参数太多了，沟通成本高，写代码需要更加小心抽离控制逻辑和业务逻辑。
3.  最核心的还是，**考虑到当前问题是否可以耦合在一起**？  
    a) 今天是中文和英文两个语言，可是明天有可能添加法语呢？这个时候，我们最好还是扩展原来的逻辑而不是在原来的代码上进行修改。
    
    b) 今天是稳定项目和创新项目，可是明天有可能添加希望项目呢？这个时候，我们难道去修改原来的逻辑吗？在控制逻辑中多加一个判断，在业务逻辑中多添加一个判断。
    
    c) 可能开发经验不足的，会理想上或者相当然，每一类的业务逻辑是一样的，确实它的逻辑过程一定是一样的。但是，每一个类别的表结构是不一样的，也根本无法抽象起来，成为一个通用逻辑代码块。
    
    d) 其实，我们可能对代码复用有一些误解。真正的代码复用是一些基础代码，比如日志的记录代码，比如附件的逻辑代码，比如接口的入参的解密，出参的加密过程，这些代码一定是需要复用的。而对于一个业务逻辑来说，我们真的可以十分肯定它内部的类别，每个类别都是一模一样的吗？表结构是一样的吗？字段名称是一样的吗？很难保证，因为既然是类别了，它一定是有一些自己独特的性质的，不然干嘛分类，他们就是一类的呀。

#### 小结 ####

1.  **不要像思考三设计**，杂糅成一个接口了，这样需要小心抽离控制逻辑和业务逻辑。
2.  **也不要选择思路二**，单一的类别方式。这样的方式依然无法满足开闭原则，既然无法满足开闭原则，则添加新的类别后，很大可能引入新的bug。还有一种情况，如果其中一个类别有bug了，所有逻辑都跑不起来了。这就是耦合代码，也是所谓的代码复用带来的弊端。
3.  **选择思路一**。如果把接口设计想象成一个类，那么无论是扩展语言类型还是项目类型，都不会修改原来的逻辑，而是根据模板代码，如果有新的类别加入，则重新添加一套逻辑代码即可。思路一接口多，繁琐。但是在前台有不同的tab页进行分类，也不用写逻辑判断。所以还是大胆选择思路一吧。