圖片來源：CSDN@tbprice

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

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

API怎么分類？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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