圖片來源：CSDN@tbprice

API的工作原理其實(shí)很易于理解。我們通過微信支付來解釋，就可以輕松地了解 API 工作原理。當(dāng)我們在點(diǎn)外賣時(shí)，系統(tǒng)會(huì)提示我們“使用微信付款”或其他類型的第三方付款方式。該付款功能就是依賴API來完成的。當(dāng)我們點(diǎn)擊付款按鈕時(shí)，API 會(huì)調(diào)用以檢索信息（也稱為請求）。該請求是通過 API 的統(tǒng)一資源標(biāo)識(shí) (URI) 從應(yīng)用程序處理到 Web 服務(wù)器，包括請求動(dòng)詞、標(biāo)頭，有時(shí)還包括請求正文。

從產(chǎn)品網(wǎng)頁收到有效請求后，API 會(huì)調(diào)用外部程序或 Web 服務(wù)器，即第三方支付系統(tǒng)。服務(wù)器向 API 發(fā)送包含所請求信息的響應(yīng)。API 將數(shù)據(jù)傳輸?shù)匠跏颊埱蟮膽?yīng)用程序，此處為產(chǎn)品網(wǎng)站。雖然數(shù)據(jù)傳輸會(huì)根據(jù)所使用的 Web 服務(wù)而有所不同，但請求和響應(yīng)都是通過 API 發(fā)生的。用戶界面上看不到這些傳輸，這意味著 API 在計(jì)算機(jī)或應(yīng)用程序內(nèi)交換數(shù)據(jù)，在用戶看來是一種絲滑的無縫連接。

API怎么分類？

隨著溝通場景的變化，API的分類維度也會(huì)不同：

按照API提供方劃分：自有API、三方API（例如：身份認(rèn)證、短信服務(wù)、支付服務(wù)、AI大模型等)。
按照API技術(shù)屬性劃分：系統(tǒng)API（例如：緩存、定時(shí)、通知、監(jiān)控等）、業(yè)務(wù)API（會(huì)員API、商品API、內(nèi)容API、交易API等）、平臺(tái)API（單獨(dú)登錄API、搜索API、AI客服API等）。
按照API調(diào)用方式劃分：同步API、異步API。
按照API顆粒度劃分：服務(wù)類API（例如：美團(tuán)外賣API、淘寶商城API、京東快遞API等）、功能類API（例如：短鏈API、歸屬地API、企業(yè)認(rèn)證API等）。
按照API是否對外開放劃分：內(nèi)部API、開放API。

產(chǎn)品經(jīng)理在哪些場景需要設(shè)計(jì)API？

在開發(fā)基于互聯(lián)網(wǎng)的應(yīng)用時(shí)（SPA應(yīng)用、APP應(yīng)用、小程序、智能設(shè)備應(yīng)用等），技術(shù)架構(gòu)基本都是客戶端-服務(wù)器模式，此時(shí)服務(wù)端基本都是API，產(chǎn)品經(jīng)理只需要描述業(yè)務(wù)即可。
在給上下游提供技術(shù)接口時(shí)，基本都以API方式提供，此時(shí)產(chǎn)品經(jīng)理需要設(shè)計(jì)API、定義API。
在企業(yè)服務(wù)貨幣化時(shí)，以API方式提供，此時(shí)產(chǎn)品經(jīng)理需要設(shè)計(jì)API、定義API、定價(jià)API等。

產(chǎn)品經(jīng)理在哪些場景會(huì)用到三方API

由于成本因素、數(shù)據(jù)或資源持有因素、技術(shù)能力因素等，企業(yè)在研發(fā)數(shù)字化系統(tǒng)時(shí)，不可能所有服務(wù)都自研，也不會(huì)都使用開源代碼自建，大量使用三方API成為必然選擇。

通用基礎(chǔ)場景，例如登錄：在設(shè)計(jì)應(yīng)用程序時(shí)，最基礎(chǔ)的功能就是用戶的登錄功能，而用戶不需要在每個(gè)軟件都單獨(dú)注冊賬號，而是可以使用微信、QQ和支付寶等賬號來登陸應(yīng)用程序。類似的場景還包括KYC認(rèn)證、單點(diǎn)登錄、安全管理、資金收付、社交分享、用戶溝通等。

使用平臺(tái)資源場景，例如旅行預(yù)定：各大旅行平臺(tái)軟件的基礎(chǔ)功能是匯總航班和酒店等信息，展示在不同的日期下的不同價(jià)格。通常這些數(shù)據(jù)來自于上千個(gè)網(wǎng)站和主頁，這項(xiàng)服務(wù)也是通過API來完成的。類似的場景還包括快遞及物流、外賣平臺(tái)、幾大電商平臺(tái)等，企業(yè)必須用到三方API。

使用三方技術(shù)能力場景，例如AI大模型：AI大模型是24年的新寵，大部分企業(yè)無法自研，將會(huì)以使用為主。類似的場景還包括云計(jì)算技術(shù)、區(qū)塊鏈技術(shù)、大數(shù)據(jù)技術(shù)、存儲(chǔ)技術(shù)等。

使用企業(yè)服務(wù)類SaaS 應(yīng)用，例如CRM：CRM（客戶關(guān)系管理工具）等平臺(tái)通常包含許多內(nèi)置 API，使公司能夠與他們已經(jīng)使用的應(yīng)用程序集成，例如消息傳遞、社交媒體和電子郵件應(yīng)用程序。這大大減少了在不同應(yīng)用程序之間進(jìn)行切換以執(zhí)行銷售和營銷任務(wù)的時(shí)間。類似的場景還包括財(cái)務(wù)SaaS、人力SaaS、辦公SaaS、營銷SaaS等。

產(chǎn)品經(jīng)理如何寫好API產(chǎn)品文檔？

產(chǎn)品PRD主要的閱讀對象是后端開發(fā)（RD）、前端開發(fā)（FE）、交互設(shè)計(jì)師（UI、UE）、測試（QA），他們會(huì)在PRD中獲取自己需要完成的工作目標(biāo)，并以此為基礎(chǔ)進(jìn)行方案設(shè)計(jì)。

在前文中我們學(xué)習(xí)了API知識(shí)，擁有了和開發(fā)人人員溝通的語言，現(xiàn)在我們需要將這些知識(shí)轉(zhuǎn)化為我們對需求的描述，以便開發(fā)人員讀懂我們的需求。

以下是一個(gè)具體案例：假設(shè)我們是一家電子商務(wù)平臺(tái)的產(chǎn)品經(jīng)理，現(xiàn)在需要設(shè)計(jì)一個(gè)新的API，用于實(shí)現(xiàn)用戶訂單的創(chuàng)建功能。在編寫API產(chǎn)品文檔時(shí)，我們需要考慮以下幾個(gè)方面。

接口功能描述：首先，我們需要明確這個(gè)API的功能是什么，即用戶訂單的創(chuàng)建。在文檔中詳細(xì)描述該功能，包括輸入?yún)?shù)、輸出結(jié)果等。
參數(shù)說明：對于訂單創(chuàng)建功能，可能涉及到用戶信息、商品信息、支付信息等參數(shù)。在文檔中列出所有可能的參數(shù)，并說明每個(gè)參數(shù)的含義、類型、是否必填等信息。
請求示例：提供幾個(gè)具體的請求示例，展示開發(fā)人員如何調(diào)用該API以實(shí)現(xiàn)訂單創(chuàng)建功能。示例應(yīng)該覆蓋不同情況下的參數(shù)組合，以確保開發(fā)人員理解清楚。
返回結(jié)果：說明調(diào)用API后會(huì)得到什么樣的返回結(jié)果，包括成功時(shí)和失敗時(shí)的情況。對于成功的情況，應(yīng)該詳細(xì)說明返回的訂單信息；對于失敗的情況，應(yīng)該說明失敗的原因。
錯(cuò)誤碼定義：定義可能出現(xiàn)的錯(cuò)誤碼及其含義，以便開發(fā)人員在調(diào)用API時(shí)能夠根據(jù)錯(cuò)誤碼快速定位問題。
安全考慮：對于涉及用戶隱私或支付等敏感信息的API，需要考慮安全性。在文檔中說明如何保障用戶信息的安全，例如使用HTTPS協(xié)議、參數(shù)加密等。

通過以上的詳細(xì)描述，產(chǎn)品經(jīng)理可以編寫出清晰、完整的API產(chǎn)品文檔，有效地傳達(dá)需求給開發(fā)人員，并確保他們能夠正確地實(shí)現(xiàn)所需功能。