航司电商OpenAPIs架构导论(航司协同平台&集市)

术语及概念前提

        对于Open API(Public API), Open APIs, OAI & OAS, IATA Open APIs, Microservices,Swagger等几个概念,如下图所示:



真正价值

        扩大在线客户群体,挖掘蕴藏的潜力和市场。



建设蓝图

        后面详细介绍S/1/2/3几个关键环节。


建设路径

    在建设过程中,必须根据不同的阶段,对应的最终用户,决定战略路径和实施重点。


建设层次

        但是对于每个建立的APIs群体和层次,必须因地制宜的规划和布局。


建设规划

        分为三个关键阶段迭代建设。其中协同平台和协同集市是真正生产力和数字化能力的体现。


航司数字化能力根基 / Digital Capabilities



航司微服务”蜂巢” / Airline Microservices Hive



航司协同平台 / Airline Coordination Platform



航司协同集市 / Airline Coordination Marketplace



建设目的

        终极目标:App Store的模式及生态。



建设要素



建设难点



建设风险



逻辑架构



时间轴及路径建议



Open APIs趋势



APIs经济:协同生产力、创业、盈利、生态



FinTech API生态

        相对较为完善且成熟的行业API生态系统。



Open Bank Project

https://openbankproject.com/,https://github.com/OpenBankProject

开源API和应用市场,通过生态环境下的第三方协同开发及应用,以期促进金融机构安全且敏捷的增强他们的数字化产品及服务能力。



Open Data

与OpenAPIs息息相关且经常被涉及的概念和现实产物。

类似于开放式系统、开源代码等,其期望数据能够免费被提供给每个人使用和重新发布,但不受版权、专利、其他约束条件限制。


API黄页 / API Directory

https://www.programmableweb.com/apis/directory

绝非某一个行业,或IT趋势,而是全球性数字化能力的趋势,通过开放API,提升协同开发能力及生态。



航空业APIs

几乎全部GDS、重要航旅企业,尤其是互联网航旅公司都有了较为完善及成熟的OpenAPIs的实现及运营。



IATA’s OpenAPIs



IATA’s OpenAPIs

StB(Simplifying the Business)提出的“连接,协同,共享”航司及机场的资源,更简洁的服务于旅客。



架构的进化

根据OpenAPIs平台及集市的完善和生态的成熟,内部中后台架构是一个不断迭代及优化,且萃取的过程。



资源及服务黄页

明确企业已有数据、信息、业务流程、工具等等资源,从而确定对于不同访问权限和开发者的暴露能力。


API业务策略 / API Business Strategy

根据最终开放的开发者不同,定义API业务及架构策略。



API货币化 / API Monetization

当APIs成熟后,航司企业需要考虑如何按照不同类型的API来“盈利”。



OpenAPIs角色及分工

开发者、发布者/管理者、消费者、用户构成整个生产及消费群体。



OpenAPIs生命周期

API具有独立于其所依赖的后端服务的生命周期,且完全不同一般的软件服务的上线发布流程。



OpenAPIs社区建设

除了Portal上的宣传之外,更需要注重长期及全方位的感染开发者及宣传航司理念。



开发SDK及Dev Studio全面支持

平台的成熟、开发者的簇拥、生态的完善。(但是航司需要对于Dev Studio慎重。)



IATA NDC的区别对待

http://ndc.developer.iata.org/docs/NDC%20RESTful%20Architecture%20Whitepaper.pdf



开发者Portal,http://developer.airline.com

即API的Content Management System,航司第二个官网。



OpenAPIs管理平台职能



APIM的Gartner评分

基于《Magic Quadrant for Full Life Cycle API Management》,选择业界产品支持。



APIM的业界评分

基于互联网开发人员的评定。



APIM选型考虑因素

UA在2017年对于APIM选型的参考。



The OpenAPI Specification (OAS) 开发规范

原Swagger Specification,旨在定义人机均可读的编程语义的接口文档,及契约规范。



OAS的API-First开发模式

OpenAPI-Specification 3.0来自及衍生与Swagger 2.0 Specification(即OpenAPI 2.0)。



Swagger工具集

通过优秀的标准化工具将业界规范融合在日常开发及管理之中,提升OpenAPIs的标准化质量水平。



DevOps

通过DevOps提升Microservices开发的敏捷性和自动化水平,以期应对OpenAPIs的个性化敏捷化的诉求。



容器化 / Containerization

即Docker & Kubernetes的应用,及与Microservices的结合;DevOps中的重要一环,必须应用的技术堆栈。



WSO2 APIM实践



Azure & AWS混合实施方案参考


©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容