開放銀行——你的API準(zhǔn)備好了嗎？

目錄：

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

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

API不等于“接口”

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

API的潘朵拉魔盒

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

API的正確打開姿勢

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

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

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

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

ProgrammableWeb在API的系列科普文章中用電源插座做了比喻，雖然全球范圍插座的模式還是有差異（比如歐洲和美洲標(biāo)準(zhǔn)不同，電壓也有110V和220V），但在一個(gè)大區(qū)域里我們拿著電器是可以各地通用的。插座標(biāo)準(zhǔn)化的好處自然是不言而喻的，背后電從哪里來的復(fù)雜實(shí)現(xiàn)完全不用消費(fèi)者費(fèi)心。當(dāng)然API比插座還要更加強(qiáng)大，插座只是提供簡單的供電，而API提供的是各種能力，這些能力被外部的應(yīng)用調(diào)用和組裝之后，就可以演變出各種定制化、個(gè)性化的服務(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個(gè)擬納入金融科技創(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無疑會(huì)更進(jìn)一步推動(dòng)這樣的數(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ù)變成社會(huì)公共平臺(tái)。

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

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

內(nèi)部API可提高組織的敏捷性，執(zhí)行效率和有效性。銀行面對耗時(shí)數(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ù)字化時(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)來增加價(jià)值。借助API，銀行產(chǎn)品可以成為開放商業(yè)生態(tài)系統(tǒng)的一部分而獲得價(jià)值。例如，Visa發(fā)布的一個(gè)產(chǎn)品API，允許發(fā)卡行向客戶提供“卡控制”功能 —— 設(shè)置支出控制、接收警報(bào)以及打開和關(guān)閉帳戶。產(chǎn)品API看起來可能與其它類型的API非常相似，無論產(chǎn)品是一種付款方式，一種服務(wù)，還是某種諸如移動(dòng)錢包之類的數(shù)字“實(shí)體”。關(guān)鍵區(qū)別在于，由于它們可以直接控制產(chǎn)品或服務(wù)，并集成另外的產(chǎn)品或服務(wù)，因此產(chǎn)品API主要是購買和使用產(chǎn)品的人感興趣，商業(yè)生態(tài)伙伴也會(huì)感興趣如何利用產(chǎn)品API形成增值服務(wù)。

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

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

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

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

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

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

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

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

安全、安全、還是安全

談開放就不得不關(guān)注安全，安全是開放的基本前提，特別是在銀行這樣的金融服務(wù)領(lǐng)域。API普遍存在的問題是大家會(huì)不自覺的將安全放一邊，或者“外包”給專門安全團(tuán)隊(duì)?！皟?nèi)部接口，安全不用討論了”這樣的言語充斥于需求分析階段。

開放API平臺(tái)安全意識(shí)的轉(zhuǎn)變需要從過去“內(nèi)向”變成“外向”，傳統(tǒng)針對接口的技術(shù)安全性掃描只是整個(gè)安全策略的冰山一角，如果我們看看英國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è)計(jì)、開發(fā)和運(yùn)營共同的責(zé)任，意味著每個(gè)環(huán)節(jié)的都需要執(zhí)行相關(guān)的安全實(shí)踐，建立相關(guān)的安全思考。

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

API不等于“接口”

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

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

互聯(lián)網(wǎng)時(shí)代某種意義上已經(jīng)過去，而互聯(lián)網(wǎng)技術(shù)給當(dāng)下數(shù)字化時(shí)代留下了寶貴資產(chǎn)。其中很重要的一項(xiàng)就是應(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è)計(jì)系統(tǒng)和應(yīng)用間的接口。

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

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

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

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

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

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

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

自動(dòng)化體驗(yàn)

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

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

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

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

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

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

API的潘多拉魔盒

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

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

API治理全景圖

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

（圖示：API治理全景圖）

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

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

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

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

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

針對這樣的持續(xù)演進(jìn)，一個(gè)良好的實(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è)施。一個(gè)成功的開放API平臺(tái)會(huì)得到市場的肯定，獲得源源不斷的需求，所有方也可以通過API消費(fèi)的貨幣化獲利。開放API實(shí)質(zhì)是銀行對外提供的一種商品、一項(xiàng)服務(wù)。因此在構(gòu)建開放API時(shí)，API as Product的原則，即把API當(dāng)作一個(gè)產(chǎn)品來看待，能夠幫助我們剝絲抽繭，找到正確的打開姿勢。借鑒良好的產(chǎn)品研發(fā)方法，開放API的構(gòu)建過程也包含以下幾個(gè)階段：

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

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

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

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

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

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

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

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

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

John Musser（ProgrammableWeb.com創(chuàng)始人）在 2012 年的 O’Reilly 開源項(xiàng)目大會(huì)上提出，“a great API on a bad service is lipstick on a pig”，面對糟糕的業(yè)務(wù)系統(tǒng)，即使設(shè)計(jì)再良好的API也是徒勞?？紤]開放API設(shè)計(jì)時(shí)，如果只考慮對已有系統(tǒng)蒙上一層薄薄的API，而忽略背后系統(tǒng)本身的開放性，那么不論這個(gè)API設(shè)計(jì)得如何精致，在其交付上線后我們可能都會(huì)面臨這樣的窘境。

因此在設(shè)計(jì)和交付開放API時(shí)，需要考慮這個(gè)開放API所依托的后端系統(tǒng)是否能夠達(dá)到能力要求至少應(yīng)該從兩個(gè)方面進(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è)計(jì)之初是面向封閉的，并沒有考慮對外開放的訴求。很多這樣的系統(tǒng)由于缺乏持續(xù)優(yōu)化而被我們稱之為“遺留系統(tǒng)”。在設(shè)計(jì)和實(shí)施開放API時(shí)，我們需要直面這樣的挑戰(zhàn)，把開放API變成一次契機(jī)，建立封閉系統(tǒng)的改造機(jī)制，逐步實(shí)現(xiàn)真正的科技開放。”

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

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

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

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

API管理平臺(tái)往往會(huì)從性能、緩存、設(shè)備、地理位置，以及開發(fā)者參與度等方面展示API的表現(xiàn)，使用的指標(biāo)也都是業(yè)界常見的。這些指標(biāo)包括流量、響應(yīng)時(shí)間、請求延遲時(shí)間、響應(yīng)錯(cuò)誤、開發(fā)者參與度等，其中有些指標(biāo)還被細(xì)化為多個(gè)具體分項(xiàng)。比如流量指標(biāo)部分還包含Total traffic/Traffic success/Traffic errors/Average TPS這四個(gè)具體分項(xiàng)，開發(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)用平臺(tái)提供的開放API，從而收獲期望的業(yè)務(wù)收益。

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

  1. TTFHW（Time to first hello world）

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

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

  2. TTFPA（Time to first profitable application）

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

千里之行始于足下

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

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

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

參考資料

文/ThoughtWorks肖然、黃雨青

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容