API接口定义的一次学习

对于API接口的设计，如果有这样一个功能。
有个功能有两个业务要使用。里面需要用到5个参数：A,B,C,D,E
对于A，B参数，两个业务方都能获取到，而对于C,D,E三个参数，两个业务的数据不一样，需要分别写死。像这种功能的设计，我原本的设计是，请求参数传入A,B,C,D,E参数，对于CDE参数，两个业务方自己写死参数，或者一个业务方有C参数，没有D，E参数，另一个业务方没有C参数，只有D，E参数，然后传入后端，这样后端只需要提供一个接口，然后拿到参数进行处理就好了。

今天学到一种理念，对于这种方式的接口设计，尽量的设计个性化，所谓个性化就是，对于两个业务方分别设计一个接口，C,D,E参数在后端web层逻辑写死就行，center保持功能的可扩展性，这样的设计可能会导致接口的增多，但是会有很多好处：
1）我们无需在web层做很多判断，也就是if-else判断，因为像这种公用的接口，如果做很多判断，后续的解读会很麻烦，对于接口的交接与维护也会很麻烦，拆分接口，每个接口的维护就很简单了。
2）对于业务方很友好，我们可以发现，这种设计之后，业务方其实只需要传入A，B参数就好
3）接口的维护会很方便，这种设计，如果某一天我们要删除其中一个业务方，原来的方式可能是屏蔽掉代码中的if-else逻辑，但是代码一直在这，而拆分之后，只需要删除这个对外的web层API就可以了。另外如果某一天我们需要对某一个业务方进行做限量等操作，如果都集成在一个接口里面，使用参数区分业务方，那做限流就会很麻烦，特别是post请求，而拆分之后，就很好做了。

做接口API时，我们不仅要保证API的可重用行，还要保证API的简单性，以及可维护性。当然，我们也要保证接口内部实现逻辑的可复用。

当然，对于上面写的在web层将参数写死的方式不是很优雅，我们可以采用另外一种方式，就是我们可以将对应的参数生成一个key，给业务方，业务方传入key,后端根据key解析出对应的固定数据，然后进行使用的方式也可以