如何构建基于WebAPI的开放平台架构实践？

新生代码农如何在硝烟弥漫的商业丛林中生存和崛起？ 洞见,让一部分先遇见未来。 关注公众号“码农商业参谋"，获取更多技术干货和商业新风向。 背景随着业务的发展,越来越多不同系统之间需要数据往来,我们和外部系统之间产生了数据接口的对接。当然,有我们提供给外部系统(工具)的,也有我们调用第三方的。而这里重点讲一下我们对外的接口。 目前,我们运营和维护着诸多的对外接口,很多现有的接口服务寄宿在各个不同的项目,哪些应用在使用api也没有管理起来。并且以前的调用模式也是比较复杂,排错困难。 目前已经对外提供服务的有短信平台,审核中心,ETCP,官网系列(充值,登陆,注册),服务中心,AuterCenter,HomeAPI(即将上线)。同时内部还有工单系统,安全中心,基础服务,GEMC等。其他的还有一些内部工具服务。 从目前的需求上看,我们对外提供接口的需求很大。当然,能够持续对外提供服务是好事。 但是,对接标准不统一,服务寄宿不合理, 无文档,无测试报告,无demo,无接口变更记录都将导致api的可持续和可维护变得越来越难。 我们将更多的考虑对外服务的安全性,高可靠性,可维护性,尤其是离产品和用户最近的那些API。 同时,尽量做到所有api及其调用关系都有数据可查。因此,对于新接入的API,提供专业、规范的设计标准和文档规范势在必行。 让所有支撑服务化,所有服务标准化。 OPenAPI将作为支撑的中间件,与其他系统服务一起为运维、安全、产品和运营的各种需求提供强有力支撑。 需求 1.对服务提供方(如官网服务)及其API进行管理 2.对接入的应用进行管理 1)用户先申请appkey,appsecrect 2)下载sdk 3)通过appkey,appsecrect生成token _aop_timestamp String 否 请求时间戳 _aop_signature String 是 请求签名 access_token String 否 用户授权令牌 4)调用API 3.api规范 1)命名规范 入参,返回值 参考: https://developer.github.com/v3/ http://cizixs.com/2016/12/12/restful-api-design-guide 2)API文档规范 4.日志记录 1) API调用记录 2) API调用异常记录 3).... 5.安全 1)参数加密 2)IP白名单限制 3)接口限制 6.性能 1)客户端缓存 2)服务端缓存 3)限流 对于高频访问进行限制,如每个appkley1min调用次数 使用场景 架构设计 1基础架构 2UML设计 3认证机制 验证（Authentication）是为了确定用户是其申明的身份，比如提供账户的密码。不然的话，任何人伪造成其他身份（比如其他用户或者管理员）是非常危险的 这里使用TOKEN+签名认证 保证请求安全性 主要原理是： 1.做一个认证服务，提供一个认证的webapi，用户先访问它获取对应的token 2.用户拿着相应的token以及请求的参数和服务器端提供的签名算法计算出签名后再去访问指定的api 3.服务器端每次接收到请求就获取对应用户的token和请求参数，服务器端再次计算签名和客户端签名做对比,如果验证通过则正常访问相应的api，验证失败则返回具体的失败信息 核心实现(含代码片段): 1.用户请求认证服务GetToken,将TOKEN保存在服务器端缓存中,并返回对应的TOKEN到客户端（该请求不需要进行签名认证） 2.客户端调用服务器端API,需要对请求进行签名认证,签名方式如下 1get请求：按照请求参数名称将所有请求参数按照字母先后顺序排序得到：keyvaluekeyvalue...keyvalue 字符串如：将arong=1,mrong=2,crong=3 排序为：arong=1, crong=3,mrong=2 然后将参数名和参数值进行拼接得到参数字符串：arong1crong3mrong2。