雖然 API 已經存在超過 50 年，但它們在過去十年左右才成為主流，並且圍繞著這項技術有大量的討論和興趣。 無論是面向公眾還是內部，擁有 API 都有許多優勢。 然而，許多組織和團隊在踏上邁向成功 API 之旅時仍然面臨困難和問題。 我最近與 APIvista 的技術長 Chris Busse 進行了訪談，APIvista (@busse) ，深入探討 API 以及組織應該如何思考 API。 APIvista 是一家以 API 為中心的開發和管理服務公司，協助客戶透過 API 交付新的業務價值。Chris 在 IT 產業擁有超過 20 年的經驗，對於公司和組織應該如何制定其 API 策略提供了寶貴的見解。
建構成功的 API
根據 Chris 的說法，成功的 API 需要像公司產品組合中的任何一流產品一樣，受到相同的關懷和關注。
「理解並對您的 API 消費開發人員抱持真正的產品管理同理心，就像您對待任何客戶一樣，對於設計出容易被採用的優質 API 有很大的幫助。」
在處理 API 時應用產品管理原則和實務，是將您的 API 視為一流產品的第一步。產品經理了解他們的終端客戶。API 也是如此。 了解 API 的終端消費者的需求，並了解 API 如何融入他們的軟體開發生命週期，對於建構穩固的 API 至關重要。在 API 開發和部署生命週期的每個階段，將終端消費者的需求納入考量，將有助於引導 API 的開發朝正確的方向發展。 然後是使用者體驗的同理心。設計 API 以及圍繞它的成品和服務時，要旨在減少預期消費者的學習曲線，這應該始終是首要任務。以終端使用者為中心建構 API 是設計思維方法的基礎。設計思維試圖在終端消費者、業務和技術之間找到平衡。 API 也是如此，理想情況下，精心設計的 API 可以找到這種最佳平衡。這表示業務價值會隨著 API 使用量的增加而產生和推動，並且實施的技術沒有錯誤且符合公認的標準。 透過適當的產品管理和使用者體驗原則的平衡，終端消費者可以輕鬆地採用和使用 API。就像任何產品一樣，採用會帶來更多的採用。 Chris 認為，這對於公用 API 尤其如此。我們經常看到，如果社群從 API 中獲得很多價值，他們就會挺身而出，為 API 的採用做出貢獻，從建立文件到開發客戶端 SDK。
上市速度是否需要考量？
對於您的發布日期，有良好的預估非常重要。通常，API 的上市速度與設計一致性之間需要權衡。雖然上市速度很重要，但它不應該導致 API 的首次發佈效率低下且設計不良。 為此，Chris 建議在 API 的開發階段盡可能多地找出一些初始目標消費者並獲得他們的回饋。這將允許 API 良好地首次發佈，同時仍然可以滿足發佈期限。從組織黑客松到找出試用客戶，收集使用者回饋的方法並不缺乏創新。
需要注意的錯誤
這個策略的一個常見錯誤是，組織僅根據這些初始客戶的需求量身定制其 API，並希望該 API 具有可以滿足整體市場需求的共通點。然而，實際情況是，這些共通點會導致更多的差異。 因此，建議對這些初始客戶的回饋採取開放式的態度。制定具體的版本控制策略也可以幫助克服這一點。 根據 Chris 的說法
「組織需要制定一個完善的計畫，說明他們將何時以及如何向 API 添加新的變更，從而隨著時間的推移，滿足更多終端消費者的需求。」
如果組織希望遵循某個理想，上市時間可能會受到影響。我們以超媒體 API 為例，它是 API 的新標準。雖然發佈基於超媒體的 API 可以帶來很多好處，但組織需要絕對確定終端客戶具有使用這些 API 的成熟度和專業知識。請記住，透過採用新的標準，發佈者也期望他們的終端消費者具有一定程度的精通程度。 Chris 解釋說：
「雖然他們可能在社群空間或數位使用者體驗空間中擁有技術先進或尖端的產品，但他們中的一些人經歷了漫長的旅程，並且可能仍在努力將他們的 API 提升為一流的產品。」
何時採用「設計優先」方法
如果組織的成熟度足以繼續採用理想的方法，那麼設計優先才有意義。正如 Chris 解釋的那樣，在許多情況下，當提出並確定 API 的設計時，API 的開發工作已經開始，但設計在開發過程中被更新。 這並不是單一事件，如果各個團隊之間的溝通不夠順暢，就可能經常發生。這種漂移只會增加團隊的工作量，在某些情況下，還會導致團隊之間的挫敗感、敵意和不信任。 如果團隊提供 API 的設計給開發團隊，讓他們可以開始實作 API，他們需要與他們保持開放的溝通管道，並且需要大量的信任存在。 因此，雖然像 OpenAPI 規格（以前稱為 Swagger 規格）、RAML 和 API Blueprint 等描述格式確實滿足了很好的需求，但將開發方法視為「設計優先」或「程式碼優先」需要更多思考。 因此，重要的是要經歷 API 的旅程，並找出哪種方法適合您的開發團隊，因為紙上的理想並不總是實務中的最佳方法。 Chris 重申了設計一致性的重要性。無論建構 API 的方法為何，組織下不同產品和服務的不同 API 都應具有相同的內部準則。終端開發人員應該感覺到該組織提供的所有 API 都是由同一個組織建構的。即使這些 API 不會彼此互動，也是如此。 例如，像 Google 這樣的公司，其產品有多個不相關的 API，例如 YouTube、Google+ 和 Google 地圖，仍然可以遵循一些內部標準，幫助開發人員輕鬆適應他們的 API。Chris 建議他所有的客戶都要注意這種一致的呈現方式。
衡量成功
API 投資的挑戰之一，在於其投資報酬率 (ROI) 初期可能難以衡量。API 投資的成功與否，可以透過企業獲得的回頭客次數、合約續約的頻率，以及企業產品和服務的受歡迎程度來衡量。這些自然會帶來成長和營收，而且往往事後，高層主管們才會意識到這一切歸功於公司將 API 視為一流產品的投資。 另一個衡量成功的良好指標是用戶採用率。您需要花費大量時間在 API 的使用者體驗上。Chris 和他的團隊衡量的其中一件事是「Hello World」的時間。這是 API 的最終使用者成功呼叫 API 所需的時間。文件和程式碼範例越好，最終使用者進行身分驗證和呼叫 API 所需的時間就越少。
設定正確的期望
企業必須了解到，使用他們發布的 API 也會為客戶帶來成本和努力。這些 API 還將與其他提供類似服務的 API 和產品競爭客戶的資源。因此，期望使用者在 API 建置完成後就會自動開始使用是不正確的。 與任何產品一樣，API 需要時間和努力才能接觸到目標受眾。API 的採用時間比許多人認為的要長，即使是最成功的 API 也需要 3-5 年才能達到其受歡迎程度。從取得採用，到投入 API 的支援和維護，API 的各個階段都有總體擁有成本，而且要取得真正的成功還有一段長路要走。 用 Chris 的話來說：
「不同的公司可能處於 API 生命週期的不同階段，期望他們以相同的動力到達終點是不切實際的。」
歸根究柢，每個 API 都在嘗試解決最終使用者的痛點。將價值歸因於痛點，以及 API 提供的解決方案，這將最終使其在技術和業務層面上都取得成功。
API 的未來
Chris 認為，人類用來與機器互動的介面將會淡化到背景中，而運算將變得既普及又隱形。在過去幾十年中，我們已經看到介面發生了顯著的演變，從第一台電腦的巨大箱子到我們口袋裡攜帶的 7 英吋 iPhone 顯示器。API 也可能如此，會出現更好、更有趣的介面，讓終端開發人員使用它們。
有興趣了解更多嗎？
Chris Busse 本週將在麻薩諸塞州波士頓舉行的 API 策略與實務會議 (APIStrat) 上發表演講。了解更多資訊。 在 Twitter 上關注 Chris Busse，他會在 Twitter 上分享他對 API 領域的看法。 如果您有興趣了解更多關於 APIvista 的資訊，請查看他們的網站。