目錄：

開放銀行基礎(chǔ)設(shè)施

• 平衡業(yè)務(wù)價值和開發(fā)者體驗(yàn)
• 安全呐籽、安全璃谨、還是安全

API不等于“接口”

• 面向互聯(lián)網(wǎng)
• 自動化體驗(yàn)

API的潘朵拉魔盒

• API治理全景圖
• API的持續(xù)演進(jìn)

API的正確打開姿勢

• 面向業(yè)務(wù)場景設(shè)計
• 面向客戶持續(xù)運(yùn)營

開放銀行的實(shí)現(xiàn)離不開對外開放的接口，從目前各家銀行的技術(shù)實(shí)現(xiàn)看桐款，有以下三種常見方式咸这。

image

（對外接口開放的三種常見方式：H5、SDK和API）

從相對嚴(yán)謹(jǐn)?shù)拈_放實(shí)踐角度魔眨，H5和SDK都不是真正意義上的開放接口媳维，存在較大的定制化約束酿雪，也很難真正在整個行業(yè)進(jìn)行標(biāo)準(zhǔn)化。所以API是希望實(shí)現(xiàn)真正開放銀行業(yè)務(wù)的金融機(jī)構(gòu)必須擁抱的對外接口方式侄刽。

ProgrammableWeb在API的系列科普文章中用電源插座做了比喻指黎，雖然全球范圍插座的模式還是有差異（比如歐洲和美洲標(biāo)準(zhǔn)不同，電壓也有110V和220V）州丹，但在一個大區(qū)域里我們拿著電器是可以各地通用的醋安。插座標(biāo)準(zhǔn)化的好處自然是不言而喻的，背后電從哪里來的復(fù)雜實(shí)現(xiàn)完全不用消費(fèi)者費(fèi)心墓毒。當(dāng)然API比插座還要更加強(qiáng)大吓揪，插座只是提供簡單的供電，而API提供的是各種能力所计，這些能力被外部的應(yīng)用調(diào)用和組裝之后柠辞，就可以演變出各種定制化、個性化的服務(wù)醉箕。比如我們現(xiàn)在習(xí)以為常的根據(jù)地理位置提供的各種服務(wù)，從附近餐廳推薦到附近的網(wǎng)紅景點(diǎn)徙垫，其實(shí)都是基于地理位置服務(wù)（API）的調(diào)用和信息疊加讥裤。

如何正確規(guī)劃API仍然是各家銀行的挑戰(zhàn)。從開放銀行出發(fā)姻报，API本身就是對外的業(yè)務(wù)己英，現(xiàn)在普遍性的將API定位為內(nèi)部IT系統(tǒng)接口的思路是阻礙API認(rèn)知的主要障礙之一。希望通過本文和大家一起提升對開放API的理解吴旋。

開放銀行基礎(chǔ)設(shè)施

今年1月14日损肛，央行公布了北京市6個擬納入金融科技創(chuàng)新監(jiān)管試點(diǎn)的應(yīng)用，API和大數(shù)據(jù)荣瑟、區(qū)塊鏈等一起被認(rèn)為是金融領(lǐng)域技術(shù)的前沿應(yīng)用治拿。這些技術(shù)應(yīng)用的主旋律其實(shí)都是圍繞著金融服務(wù)的開放使能，接下來的數(shù)字化貨幣DECP無疑會更進(jìn)一步推動這樣的數(shù)字化開放生態(tài)形成笆焰。

全球數(shù)字化先鋒的西班牙對外銀行——BBVA劫谅，針對Open API，Open Banking 和 Banking-as-a-Service 進(jìn)行了區(qū)分嚷掠。BBVA認(rèn)為Open Banking向第三方提供對現(xiàn)有銀行客戶數(shù)據(jù)的訪問權(quán)限捏检，而Banking-as-a-Service向第三方提供對銀行功能的訪問權(quán)限，以便非銀行機(jī)構(gòu)可以將銀行現(xiàn)有業(yè)務(wù)范圍之外的用戶連接到銀行服務(wù)不皆。兩者的基礎(chǔ)都離不開Open API贯城，對外開放的API，不論是對外提供數(shù)據(jù)的訪問霹娄，還是把銀行自身的金融服務(wù)變成社會公共平臺能犯。

構(gòu)建這樣的開放API平臺是一項頗具挑戰(zhàn)性的任務(wù)鲫骗，銀行長期面向內(nèi)部業(yè)務(wù)需求設(shè)計系統(tǒng)的慣性，及業(yè)務(wù)和IT部門的分隔悲雳，成為API設(shè)計和落地的巨大障礙挎峦。筆者有交流的銀行決策者對于開放API的支持已經(jīng)是毫無保留，但橫在他們面前的問題是如何規(guī)劃合瓢？誰來負(fù)責(zé)坦胶？ROI怎么算？

在解決開放API平臺規(guī)劃設(shè)計這些具體問題之前晴楔，樹立正確的理念必須先行顿苇。我們認(rèn)為銀行組織在不同層面推行API開放至少有以下幾點(diǎn)顯著收益：

內(nèi)部API可提高組織的敏捷性，執(zhí)行效率和有效性税弃。銀行面對耗時數(shù)十年構(gòu)建的遺留系統(tǒng)網(wǎng)絡(luò)纪岁，業(yè)務(wù)變化響應(yīng)力越來越差。使用內(nèi)部API则果，將客戶體驗(yàn)和業(yè)務(wù)流程幔翰，與底層技術(shù)約束，進(jìn)行隔離西壮，能很大程度上提高了業(yè)務(wù)敏捷性遗增。挑戰(zhàn)在于確保API封裝了真正的業(yè)務(wù)功能，而不僅僅是新瓶舊酒的老程序包裝款青。

B2B（“合作伙伴”）API優(yōu)化了銀行外部的流程和合作關(guān)系做修。B2B API通常在特定的業(yè)務(wù)流程和合作關(guān)系（例如付款或提供數(shù)據(jù)）的背景下，與選定的業(yè)務(wù)合作伙伴抡草，客戶和其他利益相關(guān)者實(shí)現(xiàn)高度定制化的集成饰及。這種集成能力在數(shù)字化時代成為了很多合作的先決條件。

外部API通過開放和創(chuàng)新促進(jìn)市場范圍擴(kuò)展康震。通過這種類型的API開放燎含，銀行可以通過互聯(lián)網(wǎng)向開發(fā)者開放數(shù)據(jù)、產(chǎn)品目錄腿短、業(yè)務(wù)渠道或其它業(yè)務(wù)資產(chǎn)瘫镇。這樣的做法毫無疑問可以幫助銀行擴(kuò)大其市場份額，增加銷售答姥，產(chǎn)生新的收入來源或促進(jìn)圍繞其業(yè)務(wù)的開放式創(chuàng)新铣除。

產(chǎn)品API通過連接和擴(kuò)展生態(tài)系統(tǒng)來增加價值。借助API鹦付，銀行產(chǎn)品可以成為開放商業(yè)生態(tài)系統(tǒng)的一部分而獲得價值尚粘。例如，Visa發(fā)布的一個產(chǎn)品API郎嫁，允許發(fā)卡行向客戶提供“卡控制”功能 —— 設(shè)置支出控制泽铛、接收警報以及打開和關(guān)閉帳戶杠茬。產(chǎn)品API看起來可能與其它類型的API非常相似瓢喉，無論產(chǎn)品是一種付款方式，一種服務(wù)走贪，還是某種諸如移動錢包之類的數(shù)字“實(shí)體”坠狡。關(guān)鍵區(qū)別在于擦秽，由于它們可以直接控制產(chǎn)品或服務(wù)缩搅，并集成另外的產(chǎn)品或服務(wù)硼瓣，因此產(chǎn)品API主要是購買和使用產(chǎn)品的人感興趣亿傅，商業(yè)生態(tài)伙伴也會感興趣如何利用產(chǎn)品API形成增值服務(wù)。

image

（圖示：典型銀行的API架構(gòu)酬滤，綜合參考多家領(lǐng)先銀行模式氯檐。）

全球領(lǐng)先的數(shù)字銀行對于API的整體規(guī)劃都是產(chǎn)品模式，但不可忽視的是耗拓，API產(chǎn)品化的能力在每家銀行都不會是一蹴而就的，內(nèi)部和外部API的快速落地和規(guī)范是能力培養(yǎng)的良好階梯竿刁，而這個過程中有兩個核心要素。

平衡業(yè)務(wù)價值和開發(fā)者體驗(yàn)

Deutsche德意志銀行的Bank API Program和Barclays巴克萊銀行的Open Banking平臺都是相對比較成熟的開放銀行API平臺负甸，獲得了全球行業(yè)協(xié)會的不少贊譽(yù)。評判銀行開放API優(yōu)劣的關(guān)鍵點(diǎn)之一就是API設(shè)計在業(yè)務(wù)價值和開發(fā)者體驗(yàn)之間的平衡蚕捉。

很多銀行在此方面都經(jīng)歷了慘痛教訓(xùn)，一方面業(yè)務(wù)要求的API開發(fā)者使用過程中效率低敛熬，每次都需要在API調(diào)用獲取的結(jié)果之上做大量的重復(fù)勞動。比如針對卡的查詢瑞妇，業(yè)務(wù)總是希望“包羅萬象”改备，把報文字段都傳出來悬钳。造成的實(shí)際結(jié)果就是各種分類查詢實(shí)際上都需要拿到數(shù)據(jù)再完成自身的邏輯處理，并且經(jīng)常就某個字段能不能被開放而增加復(fù)雜邏輯。

另一方面环疼，開發(fā)者本身也是API的設(shè)計者，各種為了自己眼下應(yīng)用實(shí)現(xiàn)方便而開口的API應(yīng)運(yùn)而生，最后的結(jié)果就是形成大量無人問津的API栅贴，逼得組織上馬API調(diào)用率這樣的指標(biāo)桐早。

設(shè)計階段缺乏平衡思考是銀行API開放目前的普遍問題友存，類似英國Open Banking這樣的標(biāo)準(zhǔn)化協(xié)會組織在此方面有一定的幫助屡立，也是中國銀行業(yè)目前急需的勇皇。但隨著開放銀行模式的深化落地焚刺，銀行必然需要根據(jù)自身業(yè)務(wù)特點(diǎn)進(jìn)行API設(shè)計兄淫，此時圍繞API的思維建設(shè)就至關(guān)重要坡脐。

針對中國銀行的現(xiàn)狀挖滤，我們認(rèn)為對于有志于快速構(gòu)建開放API作為基礎(chǔ)設(shè)施的銀行，需要成立專門的API治理團(tuán)隊，兼顧業(yè)務(wù)和開發(fā)者視角，參考全球先行者的經(jīng)驗(yàn)，形成API設(shè)計的指導(dǎo)原則诊沪，逐步建立適合于銀行自身發(fā)展方向的開放價值觀挤悉！

安全昏鹃、安全怠褐、還是安全

談開放就不得不關(guān)注安全宪巨，安全是開放的基本前提极祸，特別是在銀行這樣的金融服務(wù)領(lǐng)域蒜田。API普遍存在的問題是大家會不自覺的將安全放一邊美莫，或者“外包”給專門安全團(tuán)隊傀顾『“內(nèi)部接口椭岩，安全不用討論了”這樣的言語充斥于需求分析階段塌计。

開放API平臺安全意識的轉(zhuǎn)變需要從過去“內(nèi)向”變成“外向”章钾，傳統(tǒng)針對接口的技術(shù)安全性掃描只是整個安全策略的冰山一角府寒，如果我們看看英國Open Banking在安全問題上的FAQ纤房，就能夠感受到開放API安全的廣闊含義：

原文：

“How do I know Open Banking is safe?”

Open Banking has been designed with security at its heart – here’s how:

• Bank-level security – Open Banking uses rigorously tested software and security systems. You’ll never be asked to give access to your bank login details or password to anyone other than your own bank or building society.

• It’s regulated – only apps and websites regulated by the FCA or European equivalent can use Open Banking.

• You’re in charge – you choose when, and for how long, you give access to your data.

• Extra protection – your bank or building society will pay your money back if fraudulent payments are made. You’re also protected by data protection laws and the Financial Ombudsman Service.

從客戶視角，英國開放銀行組織認(rèn)為安全是核心堕扶，具體體現(xiàn)在銀行自身構(gòu)建糊探、行業(yè)規(guī)范褥紫、客戶自主等方面姜性，底線是銀行要為不安全事件造成的客戶損失買單。

這種外向的轉(zhuǎn)變髓考，從客戶視角思考部念，讓安全成為了API規(guī)劃、設(shè)計氨菇、開發(fā)和運(yùn)營共同的責(zé)任儡炼，意味著每個環(huán)節(jié)的都需要執(zhí)行相關(guān)的安全實(shí)踐，建立相關(guān)的安全思考查蓉。

我們建議銀行在構(gòu)建開放API的能力時射赛，關(guān)注安全內(nèi)建的思想，把安全的實(shí)踐植入到工作過程中奶是。這不僅僅意味著開發(fā)人員需要遵守良好技術(shù)規(guī)范楣责，也需要業(yè)務(wù)人員從客戶及商業(yè)環(huán)境角度去分析安全相關(guān)的場景。

API不等于“接口”

國內(nèi)的先行者聂沙，如 浦發(fā)銀行的API開放平臺 和 招商銀行的企業(yè)開放平臺秆麸，離真正的開放API平臺還有不小的距離，從整體設(shè)計上看來還是受制于過去銀行內(nèi)部系統(tǒng)間報文溝通接口的慣性及汉，沒有能夠真正的從互聯(lián)網(wǎng)和開發(fā)者體驗(yàn)視角出發(fā)去轉(zhuǎn)變思維觀念沮趣。

面向互聯(lián)網(wǎng)

互聯(lián)網(wǎng)時代某種意義上已經(jīng)過去，而互聯(lián)網(wǎng)技術(shù)給當(dāng)下數(shù)字化時代留下了寶貴資產(chǎn)坷随。其中很重要的一項就是應(yīng)用之間交流溝通的協(xié)議 —— HTTP（超文本傳輸協(xié)議）房铭。正是這種協(xié)議的存在才能有互聯(lián)網(wǎng)應(yīng)用的百花齊放，才能有一秒數(shù)十萬次的遠(yuǎn)程交易處理温眉。

毫無疑問開放API也需要通過這樣的協(xié)議在互聯(lián)網(wǎng)之上被調(diào)用和集成缸匪。盡管標(biāo)準(zhǔn)的RESTful架構(gòu)很早就被定義出來，成為互聯(lián)網(wǎng)應(yīng)用應(yīng)該遵循的統(tǒng)一接口原則类溢，但HTTP的開放性讓我們可以用多種方式來設(shè)計系統(tǒng)和應(yīng)用間的接口凌蔬。

REST全稱是表述性狀態(tài)轉(zhuǎn)移，表述的對象就是資源闯冷。任何事物砂心，只要有通過網(wǎng)絡(luò)被引用的必要，它就是一個資源蛇耀，比如一個賬戶辩诞，一筆交易，甚至是一次壞賬纺涤。要讓一個資源可以被識別译暂，需要有個唯一標(biāo)識抠忘，在網(wǎng)絡(luò)中這個唯一標(biāo)識就是 URI（Uniform Resource Identifier）。URI 既可以看成是資源的地址秧秉，也可以看成是資源的名稱褐桌。這樣的做法在互聯(lián)網(wǎng)普及的今天是常見做法衰抑，只是背后的技術(shù)標(biāo)準(zhǔn)可能并非為大家所熟悉象迎。對于開放API設(shè)計來說，這是必修課呛踊，也需要我們銀行業(yè)務(wù)人員理解資源的抽象原理和唯一標(biāo)識機(jī)制砾淌。

REST設(shè)計的背后是對HTTP協(xié)議的充分利用，包含HTTP成熟的性能和安全實(shí)現(xiàn)模式谭网，同時也簡化了API的調(diào)用成本汪厨，提升開放者的體驗(yàn)。下圖來自于BBVA在卡方面的API設(shè)計愉择，我們看到最前面的關(guān)鍵字POST劫乱、GET、PATCH和DEL即是HTTP協(xié)議里規(guī)定的標(biāo)準(zhǔn)“動作”锥涕。開發(fā)者會知道用POST去創(chuàng)建一個資源（開新卡）衷戈，用GET去獲取資源信息（查詢卡信息）。

image

(BBVA Cards API列表截圖层坠，遵循RESTful架構(gòu)規(guī)范殖妇，對外提供卡相關(guān)的操作。）

完全不遵循RESTful架構(gòu)的接口設(shè)計顯然學(xué)習(xí)成本非常高破花。比如每家銀行同業(yè)在接口報文上的設(shè)計都是不一樣的谦趣，對于外部開發(fā)者，想要使用這樣的接口首先要學(xué)習(xí)特定銀行的業(yè)務(wù)上下文座每，想要大規(guī)模對外開放是不可能的前鹅。

其次，銀行內(nèi)部報文一般是對數(shù)據(jù)的格式化峭梳，以提供特定業(yè)務(wù)所需要的信息嫡纠。直接針對這樣的報文進(jìn)行接口設(shè)計，很難獲得業(yè)務(wù)上的通用性延赌。作為外部調(diào)用方除盏，開發(fā)者更關(guān)心的是業(yè)務(wù)行為，而不是業(yè)務(wù)信息挫以，比如開卡本身是一個業(yè)務(wù)行為者蠕，外部僅需要知道結(jié)果，而不是整個開卡的過程信息掐松。REST方式的API設(shè)計也能夠利用HTTP的標(biāo)準(zhǔn)返回編碼傳遞信息踱侣，比如赫赫有名的404粪小，即表示請求的資源不存在（可能是一張被查詢的卡并沒有簽發(fā)）。

最后抡句，報文這種數(shù)據(jù)表格方式的傳遞信息對于未來的業(yè)務(wù)變化是一種阻礙探膊，每一個業(yè)務(wù)字段的變化都可能造成接口的不穩(wěn)定，都需要使用者進(jìn)行程序修改待榔。試想在互聯(lián)網(wǎng)這樣成千上萬應(yīng)用集成互聯(lián)的開放時代逞壁，是不可能有集中制度來保證大家整齊劃一改變的。

由于篇幅有限锐锣，這里不可能進(jìn)入RESTful API的詳細(xì)設(shè)計方法腌闯，但作為每家銀行邁向開放的重要一步，銀行人都需要學(xué)習(xí)互聯(lián)網(wǎng)的基礎(chǔ)規(guī)范雕憔，利用好幾十年來積淀出的開放經(jīng)驗(yàn)姿骏。

自動化體驗(yàn)

在這樣一個講究客戶體驗(yàn)的時代，毫無疑問API作為產(chǎn)品被商品化的過程中斤彼，體驗(yàn)比拼也是至關(guān)重要的分瘦。試想使用一個API需要首先閱讀冗長的說明文檔，然后聯(lián)系相關(guān)開發(fā)團(tuán)隊給測試環(huán)境琉苇，最后還要協(xié)調(diào)上線的聯(lián)調(diào)嘲玫，這樣的API可能沒人會認(rèn)為是真正開放的。

不幸的是上面的體驗(yàn)仍然是大多數(shù)銀行在談?wù)揂PI時的現(xiàn)狀翁潘。不遵守規(guī)范和對開放技術(shù)的陌生成為構(gòu)建良好API體驗(yàn)的阻礙趁冈，結(jié)果是形式化的傳統(tǒng)報文被包裝成對外接口（名義上的API），使用上仍然是系統(tǒng)之間的點(diǎn)對點(diǎn)集成拜马。

通過近期體驗(yàn)獲獎的Deutsche的Bank API Program渗勘，我們看到了現(xiàn)代開放技術(shù)對于API開放的良好支撐，簡單的試用就可以幫助大家理解什么是現(xiàn)代API體驗(yàn)俩莽，API的業(yè)務(wù)價值十分明確的呈現(xiàn)給了開發(fā)者旺坠，完整的實(shí)驗(yàn)、沙盒和生產(chǎn)環(huán)境扮超，最重要的是通過自動化的腳本生成調(diào)用代碼供開發(fā)者使用取刃。

image

（Deutsche銀行的AccountInsights API頁面截圖，明確提供了相關(guān)API的業(yè)務(wù)價值出刷。）

對于開發(fā)者來說這樣的自動化體驗(yàn)是開放的基礎(chǔ)璧疗，沒有這樣的自動化能力，開放API的大規(guī)模實(shí)踐是不可能的馁龟。通過過去幾年的沉淀崩侠，自動化相關(guān)的開放技術(shù)，包括自動化的說明文檔坷檩、自動化的調(diào)用代碼生成却音、自動化的沙盒環(huán)境等改抡，都已經(jīng)擁有了全球技術(shù)社區(qū)的廣泛支持。

對于中國銀行而言系瓢，擁抱這些開放技術(shù)是必然的阿纤，同時改造自身企業(yè)的思維及文化去適應(yīng)開放的商業(yè)模式可能是更為挑戰(zhàn)，也更為關(guān)鍵的夷陋！

API的潘多拉魔盒

作為用戶欠拾，當(dāng)我們把電器插入電源插座，啟動電器時肌稻，可能鮮有人再關(guān)注從發(fā)電清蚀、蓄電匕荸、供電到計費(fèi)的整個復(fù)雜設(shè)計了爹谭，顯然這是國家電網(wǎng)單位的責(zé)任榛搔。只有在電路改造時，大家可能才會感慨原來為了得到一個可用的插座腹泌，背后的工作如此繁瑣。當(dāng)然對于專業(yè)人士來說尔觉，可能已經(jīng)了然于胸幢妄，畢竟是一個標(biāo)準(zhǔn)化相當(dāng)成熟的行業(yè)了。

類比到咱們的API浆竭，作為設(shè)計者，為了讓我們的用戶（開發(fā)者）可以像插電一樣的便捷使用拦止，我們就需要去分析背后的復(fù)雜業(yè)務(wù)邏輯，分解從設(shè)計到實(shí)施种樱，再到運(yùn)營和演進(jìn)的各個環(huán)節(jié)俊卤。構(gòu)建這樣的能力固然是挑戰(zhàn)的消恍，但得到的開放平臺和使能的新業(yè)務(wù)模式，就像面對琳瑯滿目的電器一樣佩抹，讓人充滿期待。作為追求開放銀行的踐行者无宿，會毫不遲疑地打開API的潘多拉魔盒孽鸡。

API治理全景圖

良好體驗(yàn)開放API平臺的背后是一套完整的治理體系栏豺，隨著很多企業(yè)——包含文中提到的那些先行銀行——在API構(gòu)建方面的持續(xù)積累奥洼，我們已經(jīng)逐步清晰了整個API治理的全景圖。

image

（圖示：API治理全景圖）

從治理的角度，僅僅考慮最上層的API管理功能是不夠的瓷患，API連接的服務(wù)及支撐服務(wù)運(yùn)行的基礎(chǔ)構(gòu)建是水平面下隱藏的冰山擅编。限于本文的意圖爱态，我們不再展開每一項能力（圖中實(shí)線框）進(jìn)行討論。希望利用全景圖幫助開放API平臺的設(shè)計者們更好的全局思考故河，也根據(jù)自己的業(yè)務(wù)述求逐步明確每一項能力的具體要求鱼的。

API的持續(xù)演進(jìn)

在API治理能力分解基礎(chǔ)之上凑阶，我們需要時刻強(qiáng)調(diào)時間這個維度帶來的訴求——API必須持續(xù)演進(jìn)衷快！

這種演進(jìn)能力必須考慮于API設(shè)計之初，不同于實(shí)體產(chǎn)品环葵，一個真正開放的API發(fā)布時宝冕，意味著一個資源的誕生地梨，這個資源將有可能被來自于互聯(lián)網(wǎng)的千百個產(chǎn)品和服務(wù)所使用宝剖。隨之而來的要求是這個資源的唯一標(biāo)識在后續(xù)的變更中應(yīng)該不變万细，對于一個接口來說意味著如果要增減任何參數(shù)，都需要保證向后兼容襟雷。

而內(nèi)部的業(yè)務(wù)邏輯發(fā)生變化造成系統(tǒng)需要重新發(fā)布時，我們通過API提供的服務(wù)應(yīng)該是7x24的卓缰，至少應(yīng)該盡可能縮短無法提供服務(wù)的窗口期砰诵。這背后所涉及的數(shù)據(jù)一致性保障茁彭，新老服務(wù)的路由理肺，以及基礎(chǔ)設(shè)施協(xié)調(diào)妹萨，都是需要在API設(shè)計過程中考慮的。

針對這樣的持續(xù)演進(jìn)熏兄，一個良好的實(shí)踐就是從場景視角去梳理相關(guān)的要求摩桶，比如新服務(wù)版本部署的場景硝清，新合作伙伴接入的場景，網(wǎng)絡(luò)不可用的場景等等砾肺。我們永遠(yuǎn)不可能面面俱到考慮所有細(xì)節(jié)变汪，保持業(yè)務(wù)和技術(shù)的緊密合作是開放API能夠持續(xù)演進(jìn)的核心保障裙盾。

API的正確打開姿勢

構(gòu)建開放API的完整體系固然是復(fù)雜的番官，絕不等同于對外暴露一些接口钢属，或置辦一套基礎(chǔ)設(shè)施淆党。一個成功的開放API平臺會得到市場的肯定染乌，獲得源源不斷的需求，所有方也可以通過API消費(fèi)的貨幣化獲利台颠。開放API實(shí)質(zhì)是銀行對外提供的一種商品串前、一項服務(wù)酪呻。因此在構(gòu)建開放API時玩荠，API as Product的原則，即把API當(dāng)作一個產(chǎn)品來看待闷尿，能夠幫助我們剝絲抽繭填具，找到正確的打開姿勢劳景。借鑒良好的產(chǎn)品研發(fā)方法盟广，開放API的構(gòu)建過程也包含以下幾個階段：

image

（圖示：開放API完整的生命周期筋量，需要兼顧API平臺和開發(fā)者兩個視角桨武。作為平臺方锈津，應(yīng)該特別關(guān)注設(shè)計和運(yùn)營兩個環(huán)節(jié)一姿。）

每個階段中都會有不同的側(cè)重點(diǎn)叮叹，遵循API as Product的原則去采用相關(guān)的方法蛉顽。這樣的實(shí)踐思路携冤，正是構(gòu)建開放API與構(gòu)建傳統(tǒng)系統(tǒng)接口的顯著差異曾棕。

在不進(jìn)入過多技術(shù)細(xì)節(jié)的前提下菜循，我們希望整個API團(tuán)隊（包含業(yè)務(wù)和技術(shù)）能夠關(guān)注以下兩個方面的實(shí)踐落地，保證整個團(tuán)隊跨專業(yè)的協(xié)作昧穿，真正貫徹開放API作為一個面向客戶的產(chǎn)品的核心思想时鸵。

面向業(yè)務(wù)場景設(shè)計

在開放API設(shè)計階段饰潜，優(yōu)秀團(tuán)隊強(qiáng)調(diào)從真實(shí)業(yè)務(wù)場景出發(fā)進(jìn)行設(shè)計囊拜。這樣設(shè)計出的API才是鮮活的比搭，有真實(shí)市場需求的，而不會一上架就變成“僵尸”API蜜托。平臺用戶可以使用這些API去快速構(gòu)建自己的場景應(yīng)用橄务，或者進(jìn)行進(jìn)一步的業(yè)務(wù)創(chuàng)新蜂挪。

為了促成業(yè)務(wù)和技術(shù)能夠在設(shè)計過程中基于場景去協(xié)作棠涮，設(shè)計方法上需要關(guān)注兩點(diǎn)：

1. 基于業(yè)務(wù)場景識別高價值的開放觸點(diǎn)严肪；
2. 基于業(yè)務(wù)領(lǐng)域模型定義易于理解的開放資源驳糯。

借鑒服務(wù)設(shè)計領(lǐng)域的成熟實(shí)踐 —— 服務(wù)藍(lán)圖酝枢，我們可以很好的組織業(yè)務(wù)和技術(shù)同事們完成這樣面向場景的設(shè)計悍手。

image

（示例：通過服務(wù)藍(lán)圖官脓，面向保險業(yè)務(wù)場景的車企開放API設(shè)計卑笨，這里的一個開放資源就是車險產(chǎn)品——insurance，針對這個資源識別出兩個開放觸點(diǎn)妖滔，分別是將保險公司的產(chǎn)品添加到車企的車險產(chǎn)品中座舍，和客戶需要進(jìn)行的車險產(chǎn)品查看曲秉。）

John Musser（ProgrammableWeb.com創(chuàng)始人）在 2012 年的 O’Reilly 開源項目大會上提出承二，“a great API on a bad service is lipstick on a pig”亥鸠，面對糟糕的業(yè)務(wù)系統(tǒng)负蚊，即使設(shè)計再良好的API也是徒勞家妆】玻考慮開放API設(shè)計時，如果只考慮對已有系統(tǒng)蒙上一層薄薄的API姜挺，而忽略背后系統(tǒng)本身的開放性炊豪，那么不論這個API設(shè)計得如何精致词渤，在其交付上線后我們可能都會面臨這樣的窘境缺虐。

因此在設(shè)計和交付開放API時高氮，需要考慮這個開放API所依托的后端系統(tǒng)是否能夠達(dá)到能力要求至少應(yīng)該從兩個方面進(jìn)行評估：

1. 相關(guān)業(yè)務(wù)場景對于開放API在跨功能層面的訴求剪芍，如7x24高可用要求罪裹，是否能夠被后端系統(tǒng)滿足状共；
2. 開放API所依托的后端系統(tǒng)是否具備足夠的業(yè)務(wù)響應(yīng)力口芍，比如按周的新功能發(fā)布能力鬓椭。

而銀行業(yè)的現(xiàn)實(shí)情況是小染，在經(jīng)年累月的業(yè)務(wù)發(fā)展歷程中裤翩，核心業(yè)務(wù)逐步形成了對IT系統(tǒng)支持的依賴踊赠，這些系統(tǒng)設(shè)計之初是面向封閉的筐带，并沒有考慮對外開放的訴求伦籍。很多這樣的系統(tǒng)由于缺乏持續(xù)優(yōu)化而被我們稱之為“遺留系統(tǒng)”。在設(shè)計和實(shí)施開放API時胚嘲，我們需要直面這樣的挑戰(zhàn)馋劈，把開放API變成一次契機(jī)侣滩，建立封閉系統(tǒng)的改造機(jī)制君珠，逐步實(shí)現(xiàn)真正的科技開放策添∥ㄖ瘢”

面向客戶持續(xù)運(yùn)營

通常產(chǎn)品上線后浸颓，產(chǎn)品團(tuán)隊就開始針對線上數(shù)據(jù)和真實(shí)用戶反饋進(jìn)行分析产上，據(jù)此對產(chǎn)品進(jìn)行優(yōu)化和迭代晋涣，也就是我們常說的持續(xù)運(yùn)營谢鹊。這個實(shí)踐對于開放API來說也同樣重要佃扼，不同點(diǎn)在于所需要關(guān)注的數(shù)據(jù)。很多能力強(qiáng)大的工具已經(jīng)可以幫助我們獲得豐富的線上數(shù)據(jù)翠订，但需要我們事先明確適用的運(yùn)營指標(biāo)尽超，依據(jù)這些指標(biāo)篩選出有價值的關(guān)鍵數(shù)據(jù)似谁，進(jìn)行分析并決定開放API的演進(jìn)策略巩踏。

談到線上數(shù)據(jù)和指標(biāo)塞琼，作為開放API平臺方彪杉，首先需要考慮的是針對API管理提供的周期性報告和實(shí)時的儀表板（Dashboard）：

image

（圖示：API管理平臺產(chǎn)品Apigee Edge提供的兩種儀表盤）

API管理平臺往往會從性能、緩存渴丸、設(shè)備另凌、地理位置谱轨，以及開發(fā)者參與度等方面展示API的表現(xiàn)，使用的指標(biāo)也都是業(yè)界常見的途茫。這些指標(biāo)包括流量碟嘴、響應(yīng)時間、請求延遲時間囊卜、響應(yīng)錯誤娜扇、開發(fā)者參與度等，其中有些指標(biāo)還被細(xì)化為多個具體分項雀瓢。比如流量指標(biāo)部分還包含Total traffic/Traffic success/Traffic errors/Average TPS這四個具體分項，開發(fā)者參與度指標(biāo)則可能被細(xì)化為開發(fā)者總量玉掸、活躍開發(fā)者數(shù)量刃麸、應(yīng)用活躍度等。

誠然司浪，這些指標(biāo)在保障開放API的健康度方面很重要泊业，一定程度上突破了傳統(tǒng)SLA只關(guān)注技術(shù)指標(biāo)的思維把沼，比如納入開發(fā)者作為用戶的參與度。但從產(chǎn)品思維出發(fā)吁伺，這些指標(biāo)還是局限于API提供方自身饮睬，并沒有從客戶視角出發(fā)，以客戶為中心篮奄。我們需要從開放API的客戶——開發(fā)者的視角去思考捆愁，為他們提供高質(zhì)量的體驗(yàn)。好的開發(fā)者體驗(yàn)可以簡單定義為：開發(fā)者通過直接高效的途徑窟却，去快速應(yīng)用平臺提供的開放API昼丑，從而收獲期望的業(yè)務(wù)收益。

聚焦在開發(fā)者體驗(yàn)方面夸赫，針對開放API的持續(xù)運(yùn)營菩帝，我們推薦兩個關(guān)鍵指標(biāo)：

1. TTFHW（Time to first hello world）

   這個指標(biāo)是衡量開發(fā)者能否高效使用API的一種方式，度量他們需要多長時間才能在自己的產(chǎn)品中使用API憔足。TTFHW是切實(shí)從開發(fā)者體驗(yàn)角度出發(fā)的胁附，畢竟作為開發(fā)者，如果連實(shí)現(xiàn)一個“hello world”都需要耗費(fèi)極大的精力和時間滓彰，很容易給這個平臺打上“使用曲線陡峭”的負(fù)面標(biāo)簽控妻。

   我們可以從開發(fā)者不同的使用場景去思考如何降低TTFHW：1、在開發(fā)者初次加入平臺時揭绑，需要考慮整個平臺信息上的易理解和易使用弓候，其中具體措施可以包括在API門戶上簡潔明了的展示平臺所能提供的能力及API分類等，同時提供自助高效的“入伙”流程他匪；2菇存、在開發(fā)者尋找所需API時，為每個API都提供易于理解的demo和配套文檔邦蜜，并保證相應(yīng)的沙盒環(huán)境可以進(jìn)行快速試驗(yàn)依鸥；3、當(dāng)開發(fā)者選定API進(jìn)行集成開發(fā)時悼沈，最好有相應(yīng)的快速啟動（Quickstart）指南以及工具來減少重復(fù)的文檔和代碼工作贱迟。

2. TTFPA（Time to first profitable application）

   這個指標(biāo)是對開放API平臺運(yùn)營方的一個提醒 ——除了平臺自身的收益之外，開放API應(yīng)該為平臺客戶帶來真正的業(yè)務(wù)收益絮供。如果說TTFHW是開發(fā)者體驗(yàn)的表層度量衣吠，那么TTFPA可以稱得上是針對開發(fā)者體驗(yàn)核心的關(guān)注了。這個指標(biāo)的具體定義會很棘手壤靶，因?yàn)槊總€客戶對于收益（profitable）的定義是不一樣的缚俏。作為起步，我們可以定義的泛化一些，比如開發(fā)的應(yīng)用多久達(dá)到期望的用戶數(shù)量忧换，或者相關(guān)日活躍用戶數(shù)（DAU）等恬惯。總而言之包雀，這個指標(biāo)迫使平臺方真正站到客戶的視角宿崭，去關(guān)注API的核心價值——開放共贏。

千里之行始于足下

API及API經(jīng)濟(jì)在數(shù)字化時代正一步一步成為現(xiàn)實(shí)才写，毫無疑問也是開放銀行得以實(shí)現(xiàn)的基礎(chǔ)。構(gòu)建開放API平臺和生態(tài)仍然是充滿挑戰(zhàn)的任務(wù)奖蔓，要求各家銀行從組織結(jié)構(gòu)到思維觀念的轉(zhuǎn)型赞草。

開放API的落地，將推動銀行完成業(yè)務(wù)和IT的進(jìn)一步融合吆鹤，并促進(jìn)銀行走出去厨疙，構(gòu)建自身業(yè)務(wù)場景洞見和生態(tài)資源整合的核心能力。

面對開放銀行帶來的巨大機(jī)遇疑务，我們衷心希望有志于此的各家銀行能夠抓住機(jī)會沾凄，把開放API的構(gòu)建作為整個組織的一項核心數(shù)字能力，創(chuàng)造一個專注客戶知允、敏捷迭代的實(shí)驗(yàn)和學(xué)習(xí)環(huán)境撒蟀。

參考資料

• 英國開放銀行Open Banking
• 英國開放銀行API標(biāo)準(zhǔn)
• 浦發(fā)銀行的API開放平臺
• 招商銀行的企業(yè)開放平臺
• Barclays巴克萊銀行Open Banking平臺
• BBVA西班牙對外銀行開放平臺Open Platform
• BBVA西班牙對外銀行開放API趨勢分析
• Deutsche德意志銀行API Program
• Gartner開放銀行2019分析
• ProgrammableWeb API簡介

文/ThoughtWorks肖然、黃雨青