对于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保持功能的可扩展性,这样的设计可能会导致接口的增多,但是会有很多好处:我们无需在web层做很多判断,也就是if-else判断,因为像这种公用的接口,如果做很多判断,后续的解读会很麻烦,对于接口的交接与维护也会很麻烦,拆分接口,每个接口的维护就很简单了。对于业务方很友好,我们可以发现,这种设计之后,业务方其实只需要传入A,B参数就好接口的维护会很方便,这种设计,如果某一天我们要删除其中一个业务方,原来的方式可能是屏蔽掉代码中的if-else逻辑,但是代码一直在这,而拆分之后,只需要删除这个对外的web层API就可以了。另外如果某一天我们需要对某一个业务方进行做限量等操作,如果都集成在一个接口里面,使用参数区分业务方,那做限流就会很麻烦,特别是post请求,而拆分之后,就很好做了。
做接口API时,我们不仅要保证API的可重用行,还要保证API的简单性,以及可维护性。我们也要保证接口内部实现逻辑的可复用。
对于上面写的在web层将参数写死的方式不是很优雅,我们可以采用另外一种方式,就是我们可以将对应的参数生成一个key,给业务方,业务方传入key,后端根据key解析出对应的固定数据,然后进行使用的方式也可以
文章为作者独立观点,不代表 股票程序化软件自动交易接口观点