API 產品管理中的平台思維

大流行顯著放大了組織採用數字優先戰略的需求，這已不是什麼秘密。 那些因其他組織目標而被取消優先級的數字化轉型在一夜之間以前所未有的緊迫性轉移到了前沿和中心。 根據 2020 年麥肯錫全球高管調查，儘管 COVID-19 帶來了重大挑戰，但公司將內部運營數字化並擴大數字產品組合的速度加快了數年。

這些數字化轉型的核心是集成，由應用程序編程接口 (API) 促進。 API 曾經被簡單地認為是在軟件系統之間傳輸數據的“信使”或“中介”，現在被認為是數字生態系統的“連接組織”，為構建和利用 API 的組織提供了無限的集成和商機。 由於 API 所代表的獨特的潛在 API，監督其開發的產品經理必須採用一種方法來釋放其潛在價值，這種方法強調靈活性和可擴展性，以確保完美的集成體驗。

事半功倍

甚至在過去空前的一年之前，API 對組織的價值就已經有據可查，API 經濟已經蓬勃發展了一段時間。 要了解當今的集成格局，探索最佳品種 (BoB) 哲學的起源會很有幫助。 在 1990 年代之前，軟件供應商銷售的企業資源規劃 (ERP) 套件解決方案試圖解決各種組織挑戰。 這些套件越來越被視為笨重且不切實際，因為它們未能解決特定於組織的用例。 結果，供應商開始構建更集中的工具來解決一個功能領域的挑戰，而不是試圖為每個人做所有事情的更大的套件。 企業歡迎從各種更小、更專業的工具中進行選擇的想法，並開始組裝最符合其特定需求的個人解決方案集合。

連接點

隨著 BoB 方法的興起，集成成為產品戰略的重要組成部分。 一個能夠很好地解決某個業務領域問題的工具必須能夠與可能與其一起使用的其他 BoB 產品很好地集成。 考慮一下 HubSpot，這是組織實施的銷售和 CRM 軟件，用於跟踪和優化他們的銷售渠道和客戶關係。 HubSpot 可輕鬆與其他 BoB 軟件集成，例如 DocuSign（數字簽名）、Twilio（電子郵件/短信通知）和 Zendesk（客戶支持），無需客戶工程團隊的額外開發。

對互補工具無縫插入的需求伴隨著整個行業向擁抱開放而不是限制系統之間交互的轉變。 在此過程中，產品支持的集成數量成為值得營銷的指標。

平台主張

然而，集成的真正價值超出了它們協調不同工具和系統的能力。 在最好的情況下，API 是將產品轉變為平台的集體機制。 根據定義，產品是具有特定應用的工具； 因此是“應用程序”。 他們創造多種價值主張的能力有限，進而無法創造多種收入來源。 另一方面，平台以不同的方式增加價值：通過提供可以構建大量產品的基礎設施層。

API 通過利用利用它們的第三方的專業知識開闢新的業務渠道。 消費開發者可以設計一個房地產應用程序，使用 Google Maps 的 Places API 來幫助用戶尋找房屋，或者他們可以利用 Skyscanner 的 Flight API 和 Expedia 的 Hotel API 創建一個專門針對特定地點旅行的生態旅遊網站。 這些開發人員和外部合作夥伴通過訪問可以適應其業務的現有數據和服務而受益，而像 Expedia 這樣的 API 所有者擴大了他們的覆蓋範圍並利用如果他們繼續僅在其產品上列出酒店就不會存在的機會。

使其模塊化

對於產品領導者來說，制定成功的 API 策略需要將思維方式從產品思維轉變為平台思維。 這意味著以模塊化、開放式的方式構建產品，允許重新組合其功能，並優先考慮消費開發人員的靈活性。 想想宜家貨架系統，客戶可以通過不同的方式購買、組裝和定制，以滿足各種需求。 優秀的 API 產品經理會看到 API 的本質：用於擴展業務和發展有價值的合作夥伴關係的工具。 認識到這種潛力意味著實施最佳實踐以確保採用。

取悅開發者

如果一個可靠的 API 策略有一個基本支柱，那就是開發人員體驗 (DX)。 對於 API 集成，“客戶”產品經理需要取悅正在消費的開發人員。 這些是最終調用/集成 API 的用戶，是可以幫助實現產品到平台願景的潛在合作夥伴。 將他們的體驗貼上“DX”而不是“UX”的標籤承認他們不是典型的最終用戶——他們在技術上明顯更熟練。 為了同情他們，了解他們的具體需求和期望至關重要。

最佳實踐

以下內容雖然不代表詳盡的列表，但是構建一流 API 的基本實踐，可確保為消費開發人員提供無摩擦、一致、可預測的集成體驗。 產品經理應該以可擴展的方式設計 API，定義最佳實踐框架並將其發佈為團隊在構建新 API 時可以參考的文檔。

一致的命名約定和端點

為明確識別 API 的性質和用途的 API 端點建立一致的命名約定可以消除歧義，並有助於實現積極且可預測的 DX。 最好為所有 API 選擇一個通用的基本 URL，並為尾隨 URL 選擇一個避免行話和縮寫的框架。 Nordic API 提供了一個有用的端點命名提示列表。

詳細的成功和失敗響應結構

開發人員希望並期望熟悉的數據對象和狀態代碼用於成功和失敗響應。 這意味著成功場景的 2xx 狀態代碼、客戶端故障的 4xx 代碼和服務器端錯誤的 5xx 代碼。 然而，特異性是關鍵。 對“發送電子郵件”API 的調用只會返回 4xx 響應而沒有額外的信息，這會導致開發人員體驗不佳，因為它只是確認錯誤出現在客戶端請求中，而沒有提供關於究竟出了什麼問題的額外信息。

 { "status": 400, "message": "incorrect request" }

相比之下，以人類可讀格式和唯一錯誤代碼形式提供特定詳細信息的響應可以幫助開發人員快速決定如何糾正錯誤場景、編寫代碼來解決問題並重試 API 調用。

 { "status": 400, "message": "To recipient not specified", "code": 21221 }

為了獲得最佳 DX，響應結構和傳達狀態的密鑰應該在 API 之間保持一致。 例如，上面的錯誤代碼字段在每個 API 中都應始終稱為“代碼”，而不是某些 API 中的“代碼”和其他 API 中的“錯誤代碼”。

可配置的速率限制

速率限制通過確定用戶在單個時間單位內可以調用它的次數來控制 API 的可訪問性。 過高的速率限制會使系統充滿無法管理的請求，從而降低性能，而不合理的低速率限制會導致待處理的事務在用戶系統中排隊。 兩者都導致糟糕的DX。 在設計 API 時，最好允許可以根據特定業務案例和環境調整的速率限制。 例如，大批量客戶可能確實需要更頻繁地調用 API。

為了最好地確定適當的速率限制，首先根據調用 API 的頻率和數量將 API 分為有意義的類別是有幫助的。 例如，配置主要客戶數據（配置文件/帳戶創建）的 API 調用頻率較低，可以處理較低的速率限制，而事務 API（“創建訂單”、“發送電子郵件”）調用頻率更高，需要更高的速率限制。 為不同的用例建立類別或層級可以實現更可靠和可擴展的 API。 有關明確定義的速率限制的示例，請參閱 Slack 的 API 文檔。

綜合文檔

文檔用作 API 的用戶手冊。 它清楚地向開發人員闡明了 API 的作用、使用方法以及對它的期望。 好的文檔以清晰易懂的語言編寫，內容詳細且具有交互性，並提供大量演示和代碼片段以簡化集成。 通過這種方式，它有助於輕鬆入職並加快首次 Hello World (TTFHW) 時間，這是一個重要指標，表示開發人員可以多快地成功調用他們的第一個 API。

文檔應清楚地確定 API 請求中的哪些字段是強制性的，哪些是可選的，以及這些字段的最小和最大長度和數據類型。 從本質上講，它應該包括為消費開發人員設定期望和消除障礙所必需的一切。 例如，在他們的系統中創建數據庫模式的開發人員應該不必在以後調整表中列的長度，因為文檔沒有指定參數。

API 文檔不僅可以作為消費開發人員的可靠參考，而且可以作為 API 本身的營銷工具，從而提高采用率。 通常，第一個遇到 API 文檔的人是面向業務的利益相關者，他們在產品評估的初始階段瀏覽它。 因此，它不僅應該包括有關 API 技術元素的詳細信息，還應該清楚地闡明 API 實現的業務用例。

市場上有許多工具可以幫助生成全面的 API 文檔。 查看諸如 Stripe 等高質量文檔的示例也很有幫助。

把它放在一起

集成代表了一個包含許多組件的廣闊領域，但了解良好 API 的核心原則是製定可靠策略的基礎。 API 不僅僅是系統連接器。 它們是擴展數字網絡的基石，也是開闢新收入來源和釋放未開發價值的關鍵。 正因為如此，一個成功的 API 策略不僅僅是構建產品。 這是關於建立潛力。 API 產品經理必須採用平台思維方式，並優先考慮那些能夠讓潛在合作夥伴順利採用的因素，然後他們可以使用他們的 API、集成和運行它。