建立非银行服务生态系统以及实际上任何类似的生态系统需要什么？ 一个用于存储和处理数据的主系统以及一个API。 在本文中，我们将分析我们创建的API的两个版本-第一个和最成功-并探讨它们之间的重要区别。
为了创建非银行服务生态系统，选择了Sberbank Digital Corporate Bank部门的主要产品-Sberbank Business Online企业客户的互联网银行。 相应地，非银行服务生态系统的金融科技API也以此为基础。
金融技术API的第一版于2016年发布。 它是根据大型金融组织的API的经典配方，着眼于我们银行的其他API创建的。 以下是主要成分：
- SOAP协议用于数据传输
- XML格式
- 所有请求的电子签名
- 异步运行
- 安全通道所需的硬件VPN
- 专有认证和授权系统
- 过去建立的用于传输财务信息的格式（例如1C直接银行格式）
我们做出了这样的决定，并开始与几种非经典银行服务进行试点集成：Evotor在线商店，Seeneco的Business Analytics财务管理系统，基于MyOdelo云的会计等。
集成结果远非期望。 从现代非金融服务的API来看，合作伙伴完全没有想到经典银行产品开发中的惯例。 我们希望获得类似于现代互联网巨头的API：Facebook，Google，Yandex。
最后，他们遇到了一个经典的银行API-繁琐，晦涩，需要高级和特定技能，了解工作流程的复杂性，实施过多的安全要求...总的来说，很多事情导致违反所有可能的集成期限。
我们分析了这种经验，并决定从头开始制作新版本的fintech API。 为了与第三方非金融服务获得最大的双赢，预先概述了最重要的要求：
- 没有考虑到细微差别的通用格式和繁重格式。 让我们变得更轻松！
- API应该适合尽可能广泛的潜在合作伙伴，为Sberbank客户提供非金融产品。 在推出智能冰箱之前，这不是开玩笑。
- 需要使用用于创建可视界面的实践和方法来设计API。 为此，您需要识别和分析使用该API的UX方案。 遵循经典规范绝对是不值得的。
- 我们需要摆脱多卷描述，以便开发人员可以快速获得结果。 使用沙盒进行测试时，您需要在一个小时内获得第一个积极的结果。
- 我们尽可能拒绝与特定平台绑定的专有解决方案。 一切都应该是跨平台的，而不是限制所使用的基础架构和开发环境中的合作伙伴。
- 合作伙伴不应因其不做的事情而烦恼-复杂的数据结构，银行平台组件的机制以及我们的旧系统的功能。 我们躲起来，不埋头。
通过此列表，我们继续进行第二版fintech API的实施和选择解决方案：
- 基于OAUTH 2.0的身份验证
- 基于HTTP的REST架构，没有额外的复杂性
- 完全同步运行
- JSON格式
- 可选使用电子签名-必要时
- 使用已部署的SWAGGER测试沙箱。 使用此调试环境，合作伙伴的开发人员无需编写代码即可模拟业务流程并获得结果。
- 应用Internet初创公司使用的简易步骤方法来创建API文档
- API开发敏捷实践-快速的结果和反馈收集
实际上发生了什么变化
为了评估API的两个版本之间的差异，我们比较了其三个关键组件的实现：授权，卢布付款单的实现和电子签名。
在API的第一个版本中，为了获得授权，合作伙伴需要用户名和密码，证书和AccessToken，这些证书是通过对申请以下内容的客户端进行OAUTH身份验证而获得的：
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:upg="http://upg.sbns.zzzzz.com/"> <soapenv:Header/> <soapenv:Body> <upg:preLogin> <upg:userLogin>U1</upg:userLogin> <upg:changePassword>!d63NvJ+Sa</upg:changePassword> </upg:preLogin> </soapenv:Body> </soapenv:Envelope>
在API 2.0中，授权变得更加紧凑。 要访问服务，您只需要在客户端的OAUTH身份验证期间收到的AccessToken：
{ "access_token": "fdba5482-460c-4535-b829-9fd836fd01f0-1", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "7f545a14-ab7b-45ff-823a-0421e9f3b42e-1", }
在API 1.0中，使用卢布付款单也基于SOAP：
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:upg="http://upg.sbns.zzzzz.com/"> <soapenv:Header/> <soapenv:Body> <upg:sendRequestsSRP> <upg:requests><![CDATA[ <Request xmlns='http://zzzzz.com/upg/request' orgId='84b70f22-703f-bf04-db60-bd110572f40d' requestId='a81ddc6d-fb92-416d-83f9-6785a59a4b17' version='1.0' sender='PARTNER' clientOrgIdHash='ee0fb56b01a9d9b9648a2c60549b77702eb2a6de8f2189c4349447e43b250da5' clientAccessToken='ee0fb56b01a9d9b9648a2c60549b77702eb2a6de8f2189c4349447e43b250da5-1'> <PayDocRuInvoice docExtId='a81decfd-fb92-416d-83f9-6785a59abb65' orderNum='62' deadLine='2017-04-10T17:16:03'> <PersonalAcc>40802810000000000000</PersonalAcc> <AccDoc docDate='2017-02-15' docSum='777' transKind='01' paytKind='01' priority='1'> <Purpose>!!!!! 18%</Purpose> </AccDoc> </PayDocRuInvoice> </Request> ]]></upg:requests> <upg:sessionId>5a869c00-e979-4280-b11a-6dbbb8a90214</upg:sessionId> </upg:sendRequestsSRP> </soapenv:Body> </soapenv:Envelope>
在API 2.0中，以类似的方式，一切变得更加简单和易于理解：
{ "amount": 12.01, "date": "2018-06-22", "deliveryKind": "", "expirationDate": "2018-06-23", "externalId": "1516ec0c-761c-11e8-adc0-fa7ae01bbebc", "operationCode": "01", "orderNumber": "1237", "payeeAccount": "40706810000000000000", "paymentNumber": "1", "priority": "5", "purpose": " №1237. .", "urgencyCode": "NORMAL", "vat": { "amount": 100.01, "rate": "7", "type": "NO_VAT" }
我们还促进了电子签名。 这就是API 1.0中的样子。
所以请求看起来
这是属性列表
现在完成签名在API 2.0中，通过JSON可以轻松进行所有操作：
要求自己
结果签名总结
金融科技API 2.0试点启动表明情况变得更好了。 与合作伙伴产品集成的时间-从开始工作到正式投入商业运营-减少了3倍以上。 有关我们陪同服务的问题数量已减少了一个数量级，最重要的是，这些问题的复杂性有所降低。 最后，关于API的复杂性和不可预测性的投诉数量减少了两个数量级。 总的来说，我们做到了。 如果您有任何疑问，欢迎发表评论，我们将很乐意告诉您详细信息。
该材料由Sberbank数字企业银行项目经理Andrey Khokhlov准备