225 业务 关于api自动化的思考

入职之初就在思考，如何在现有框架下实现 api 开发的自动化，因为只做请求转发的话，业务重复性太高，如果不抽象出来比较可惜

思路

• 针对相同的业务做一系列约定(变量、业务步骤)
• 应该分离变与不变， 不变的部分应该可以直接生成，变化很少的部分应该可以实现外部登记，变化很多的地方要么暴露接口，要么再作分离

目标

• 接口应该有通行的解决方案（业务处理步骤）
• 接口参数应该可以实现可配置
• 终极目的是为了快速迭代开发
• 应留下一定的可扩展性（以应对需求的变化)

关于数据源返回值处理

• 1.默认数据源返回的是一个数组，应该可以用类似 'data.realname ' => 'response.data.name'的方式实现映射，用点来分离数组嵌套，用key,value实现最终返回值对数据源返回值的映射关系

• 2.异常逻辑如何定义，一是针对特定域特定值的处理，如数据源 code 等于 -1,那么返回异常；另一个是针对无值的处理，如压根没有code域，或者返回的字符串不是json格式

• 3.数据处理步骤如何组织，有些非通用步骤，如有的需要 Rsa ，有的需要DES，有的需要 json_decode，有的需要再调用其他接口获取token,这里可以考虑实现一个 Decoration ，留下接口让他们自己玩吧，反正最后返回一个数组（对象）就可以了

• 4.关于错误码管理，错误码应该是一个全局的配置，因为在数据源调度类和数据源的业务类都会涉及到这些业务，但是错误逻辑是没法枚举的，此处应该可以让后续的开发者自己扩展（不是hard code扩展）

自动化任务解决哪些痛点

• 1.少写一点是一点，包括字段映射的部分，包括存入日志和缓存库构造的数组

• 2.之前通过复制解决的问题，尽量用自动化的方式

• 3.数据源调度类和数据源业务类的逻辑分离

通用函数库

1. 字段映射
2. http
3. autoload
4. decentDump

数据源调度类解决的问题

• 1.构造函数 -> 获取 did 、key ，初始化开始时间
• 2.获取参数
• 3.参数校验 -> 参数校验组件 （传入数组并配置规则）-> 全局错误码管理
• 4.从db获取数据 -> 配置需要的字段数组 -> fetcher 组件
• 5.db如果取得数据，此处应该也有字段映射->函数实现
• 6.数据源管理 -> 数据源字符串替换
• 7.日志记录功能 -> 一部分参数是系统自带，另外一部分参数是映射 ->函数实现（可能为空）
• 8.数据返回功能 -> 复制吧