API經(jīng)濟(jì)的興起

在談API經(jīng)濟(jì)之前，我們需要先了解API的概念,。

API的全稱是Application Programming Interface,即應(yīng)用編程接口,，它是軟件系統(tǒng)不同組成部分銜接的約定標(biāo)準(zhǔn)。本質(zhì)上,，API 是對(duì)應(yīng)用進(jìn)行封裝,、對(duì)外開放訪問接口，以便被其他應(yīng)用或者客戶端訪問,。

隨著軟件的種類越來越多,、功能越來越豐富，軟件在設(shè)計(jì)的時(shí)候，通常是將一個(gè)復(fù)雜的大系統(tǒng)劃分成多個(gè)小的單元,，而各個(gè)小的單元需要相互協(xié)作,，編程接口的設(shè)計(jì)就顯得尤為重要。編程接口的設(shè)計(jì),，要能夠提升單元內(nèi)部的內(nèi)聚性,、降低單元之間的耦合程度，最終提升整個(gè)軟件系統(tǒng)的健壯性和可擴(kuò)展性,。

在了解了API(對(duì)業(yè)務(wù)進(jìn)行API化）的概念后,，我們?cè)诳匆幌翧PI經(jīng)濟(jì)這個(gè)話題，API經(jīng)濟(jì)伴隨著Gartner 定義的第三平臺(tái)（云計(jì)算,、移動(dòng)互聯(lián)網(wǎng)、大數(shù)據(jù),、社交）而產(chǎn)生的,。API 經(jīng)濟(jì)的熱潮，在西方國(guó)家出現(xiàn)比較早,。早在2012年,，國(guó)際互聯(lián)網(wǎng)巨頭如Salesforce、Google,、Twitter 等公司,，就通過API為他們帶來了巨大的經(jīng)濟(jì)效益。

API 經(jīng)濟(jì),，聽起來很縹緲,，但其實(shí)離我們?nèi)粘Ｉ詈芙e個(gè)例子：我們?cè)诮?jīng)常使用的導(dǎo)航軟件高德地圖,，在輸入我們出發(fā)地址和目的地之后,，可以顯示從出發(fā)地址到目的地之間的距離和路徑；接下來,，選擇打車菜單,，我們可以看到神州專車和首汽約車，并顯示對(duì)應(yīng)的價(jià)格,，如下圖所示,，我們可以根據(jù)自己的需要，選擇使用哪個(gè)網(wǎng)約車,。

高德地圖和首汽約車之間的應(yīng)用的調(diào)用,，使用的就是API調(diào)用的方式，兩個(gè)公司之間API的調(diào)用,，可能產(chǎn)生一些計(jì)費(fèi)和流量管理的需求,。

對(duì)于云廠商或者互聯(lián)網(wǎng)公司而言，完全可以將自己的應(yīng)用（如地圖服務(wù),、字典服務(wù),、郵件服務(wù)等）,，以API的方式暴露到互聯(lián)網(wǎng)上，其他公司使用API的時(shí)候,，可以進(jìn)行一定程度的收費(fèi),，從而實(shí)現(xiàn)API 經(jīng)濟(jì)。

所以說,，API經(jīng)濟(jì)的本質(zhì),，是企業(yè)通過技術(shù)把自己的業(yè)務(wù)服務(wù)化，然后通過API的方式暴露給客戶,，然后被客戶使用,，從而收取一定的費(fèi)用。伴隨著國(guó)內(nèi)數(shù)字經(jīng)濟(jì)的發(fā)展,，API經(jīng)濟(jì)將會(huì)成為數(shù)字化的核心力量,。

API 經(jīng)濟(jì)的實(shí)現(xiàn)

從技術(shù)角度而言，需要對(duì)企業(yè)的業(yè)務(wù)服務(wù)化,，然后通過API實(shí)現(xiàn)對(duì)外暴露,，在這個(gè)過程中，從技術(shù)角度來說,，需要考慮以下幾個(gè)部分：

• API靈活的訪問控制

• API的身份認(rèn)證和授權(quán)

• API合同和費(fèi)率限制

• API訪問分析和報(bào)告

• API的計(jì)費(fèi)

API訪問控制

對(duì)于企業(yè)而言,，API大致分為兩類：

• 對(duì)內(nèi)的API：通常不會(huì)直接產(chǎn)生經(jīng)濟(jì)效應(yīng)，雖然在內(nèi)部,，也需要對(duì)其進(jìn)行安全控制

• 對(duì)外的API：通常會(huì)將應(yīng)用的API接口暴露給互聯(lián)網(wǎng),，因此其訪問控制和安全就變得尤為重要。

在傳統(tǒng)的開發(fā)模式中,，API的訪問控制都是通過在應(yīng)用的源代碼中實(shí)現(xiàn)的,，這種訪問控制的實(shí)現(xiàn)，主要由應(yīng)用程序開發(fā)人員來實(shí)現(xiàn),，對(duì)于對(duì)內(nèi)的API而言,，這種方式是沒有什么問題。但是在對(duì)外開放的API中,，開發(fā)人員在編寫代碼的時(shí)候,，很難講后續(xù)API的所有調(diào)用場(chǎng)景考慮周全，比如：調(diào)用次數(shù),，調(diào)用頻率,，調(diào)用權(quán)限等。因此,，針對(duì)產(chǎn)生經(jīng)濟(jì)效益的API,，我們需要將API 調(diào)換用的安全從應(yīng)用代碼中隔離出來，放到API 專有的平臺(tái)中來管理。

API 的身份認(rèn)證與授權(quán)

API 的身份認(rèn)證與授權(quán)本質(zhì)上是為了保證 API 的安全,。

在 API 經(jīng)濟(jì)的時(shí)代,，API 的身份認(rèn)證與授權(quán)，必須要兼顧安全性,、可用性,、可擴(kuò)展性：

• 針對(duì)于 API 的身份認(rèn)證，可以使用 OpenID,。

• 針對(duì)于 API 授權(quán),，可以 OAuth2.0。

OpenID 是一種開放的身份驗(yàn)證標(biāo)準(zhǔn),。用戶通過 OpenID 身份提供商獲取 OpenID 帳戶,。然后，用戶將使用該帳戶登錄任何接受 OpenID 身份驗(yàn)證的網(wǎng)站,。

OpenID 建立在 OAuth 2.0 協(xié)議之上,，允許客戶端驗(yàn)證最終用戶的身份并獲取基本配置文件信息 RESTful HTTP API，使用 JSON 作為數(shù)據(jù)格式,。

開放授權(quán) （OAuth）是一個(gè)開放標(biāo)準(zhǔn)，允許用戶讓第三方應(yīng)用訪問該用戶在某一網(wǎng)站上存儲(chǔ)的私密的資源,，而無(wú)需將用戶名和密碼提供給第三方應(yīng)用,。OAuth 2.0 是 OAuth 協(xié)議的下一版本，相比于 OAuth1.0,，更關(guān)注客戶端開發(fā)者的簡(jiǎn)易性,；它為移動(dòng)應(yīng)用（手機(jī)、平板電腦,、Web 等）提供了專門的認(rèn)證流程,。

OAuth 2.0+ OpenID 的方式，在互聯(lián)網(wǎng)已經(jīng)被大量使用,。

舉一個(gè)我們身邊的例子：我們登錄很多手機(jī) app 或者網(wǎng)站,，都可以通過微信認(rèn)證，例如今日頭條,。

在這個(gè)認(rèn)證和授權(quán)的過程中,，微信就是 OpenID 身份提供方，而今日頭條,，就是 OpenID 身份依賴方,。

下面用通過微信登錄今日頭條的例子來演示 API 的身份認(rèn)證與授權(quán)過程。

1 打開瀏覽器,，登錄今日頭條網(wǎng)站,，如圖 2 所示。點(diǎn)擊通過微信授權(quán)登錄。這時(shí)候,，相當(dāng)于客戶端向今日頭條的服務(wù)器發(fā)起授權(quán)請(qǐng)求,。

2 今日頭條響應(yīng)一個(gè)重定向地址給客戶端，這個(gè)地址指向微信授權(quán)登錄,。

3 瀏覽器接到重定向地址,，再次發(fā)起訪問，這次是向微信授權(quán)服務(wù)器發(fā)起請(qǐng)求,，屏幕出現(xiàn)二維碼,，如下圖所示：

在這個(gè)過程中，微信認(rèn)證服務(wù)器也對(duì)用戶進(jìn)行了身份認(rèn)證,，只是因?yàn)橛脩粼趻呙璧臅r(shí)候,，微信已經(jīng)在手機(jī)登錄了（用戶在微信認(rèn)證服務(wù)器上，首先驗(yàn)證了自己的身份,，然后用微信同意今日頭條客戶端發(fā)起的授權(quán)請(qǐng)求,，也就是拿起手機(jī)用微信掃描二維碼）。

4 此時(shí)拿手機(jī)微信掃描電腦屏幕的二維碼,，并且在手機(jī)微信上點(diǎn)擊同意授權(quán)登錄,，如下圖所示：

5 接下來，微信授權(quán)服務(wù)器會(huì)返回給瀏覽器一個(gè) code,。 瀏覽器通過獲取到的 code,，向認(rèn)證服務(wù)器發(fā)起申請(qǐng)有效令牌 （token）的請(qǐng)求。認(rèn)證服務(wù)器返回 token,。

6 瀏覽器拿到 token,，向認(rèn)證服務(wù)器獲取用戶信息。認(rèn)證服務(wù)器返回用戶信息,。

用戶信息在瀏覽器展示出來,。截至到目前，登錄過程完畢,。

8 客戶端通過 token 向資源服務(wù)器申請(qǐng)資源（例如今日頭條只開放給會(huì)員看的一些文章或者視頻）,。

今日頭條的服務(wù)器，確認(rèn) token 無(wú)誤,，同意向客戶端開放資源,。

API 合同和限速

在 API 經(jīng)濟(jì)下，相同的一個(gè) API,，可以配置成不同的”套餐”（合同）,。不同的套餐，可以設(shè)置不同的限速,。例如：

• 對(duì)于白金套餐,，API 被調(diào)用次數(shù)不限,。

• 對(duì)于金卡套餐，API 每個(gè)小時(shí)可以被調(diào)用 100 次,。

• 對(duì)于普通套餐,，API 每個(gè)小時(shí)可以被調(diào)用 15 次。

當(dāng) API 被調(diào)用的次數(shù)超過限速的設(shè)置,，需要返回報(bào)錯(cuò),。

API 訪問分析和報(bào)告

在 API 經(jīng)濟(jì)下，我們需要對(duì) API 的訪問進(jìn)行統(tǒng)計(jì),。

API 的種類,，可以按照按照是否是 Web 類的分發(fā)。在第三平臺(tái)中,，互聯(lián)網(wǎng)中以 Web API 居多,，而 Web API 又大致分為兩類：

• JAX-RS: 是用于創(chuàng)建輕量級(jí) RESTful Web 服務(wù)的 Java API。

• JAX-WS: 是使用簡(jiǎn)單對(duì)象訪問協(xié)議（SOAP）的基于 XML 的 Web 服務(wù)的 Java API,。

JAX-RS 的一個(gè)很大的好處是支持 HTTP(s)協(xié)議,，也就是可以響應(yīng)四種 HTTP 的方法，具體而言：

• GET：檢索數(shù)據(jù),。

• POST：創(chuàng)建一個(gè)新實(shí)體,。

• DELETE：刪除實(shí)體。

• PUT：更新實(shí)體,。

在 API 經(jīng)濟(jì)下,，API 訪問和分析報(bào)告，應(yīng)可以對(duì)一個(gè) API 的某個(gè) URI 的 HTTP 調(diào)用方法進(jìn)行統(tǒng)計(jì),，如某個(gè) URI 在一段時(shí)間內(nèi)被 GET,、POST 了多少次等,。并且,，可以形成分析報(bào)告。

API 的計(jì)費(fèi)

在云時(shí)代,，計(jì)費(fèi)是很重要的一個(gè)功能,。而在 API 經(jīng)濟(jì)下，我們需要考慮 API 如何進(jìn)行計(jì)費(fèi),。

API 的計(jì)費(fèi)方式,，可以按照功能和流量收費(fèi)：

• 所謂功能，主要指的就是同一個(gè)應(yīng)用,，通過 API 進(jìn)行暴露出的不同的功能,，主要是通過設(shè)置應(yīng)用不同的 URI 訪問權(quán)限來實(shí)現(xiàn)的。

• 而流量,，主要是指 API 調(diào)用的次數(shù),。

在 API 經(jīng)濟(jì)模式下,，API 的計(jì)費(fèi)這兩點(diǎn)都需要考慮到。

API 網(wǎng)關(guān)與 API 管理的區(qū)別

API 網(wǎng)關(guān)是一個(gè)軟件系統(tǒng)的唯一入口,，它封裝了軟件系統(tǒng)內(nèi)部體系結(jié)構(gòu),、對(duì)外為客戶端提供 API?？蛻舳瞬槐仃P(guān)注軟件系統(tǒng)的內(nèi)部結(jié)構(gòu),。而 API 管理在是對(duì) API 進(jìn)行安全、授權(quán),、限速,、計(jì)費(fèi)進(jìn)行豐富的高級(jí)策略管理的企業(yè)級(jí)解決方案。

API 網(wǎng)關(guān)的出現(xiàn)早于 API 管理,。很多時(shí)候,，這兩個(gè)概念容易被混淆。API 管理包含 API 網(wǎng)關(guān)的功能,，而 API 網(wǎng)關(guān)缺乏 API 管理的高級(jí)策略,。二者具體對(duì)比如下：

表 1. API 網(wǎng)關(guān)與 API 管理的對(duì)比

結(jié)束語(yǔ)

通過本文的介紹，相信您對(duì)于時(shí)下火熱的 API 經(jīng)濟(jì)已經(jīng)有了大致的了解,。對(duì)于企業(yè)客戶而言,，若想將 API 經(jīng)濟(jì)落地，需要從本文提到的幾個(gè)技術(shù)層面進(jìn)行考量,，然后選擇適合自己的企業(yè)級(jí) API 管理解決方案,。