將 API 視為產品 的概念在 API 領域迅速普及，越來越多的組織看到了在開發 API 時應用產品管理原則的好處。這種方法涉及對您的 API 組合應用與您的團隊交付的任何其他軟體產品相同的關注程度和規劃。
這也是最近在 Nordic API Austin API Summit 上流行的概念。會議上有很多演講都涉及這個主題，包括 Vanick Digital 的 Pete Clare 的「為何產品化是釋放 API 價值的關鍵」，以及 Paypal 的 Rahul Dighe 的「嵌入 API 作為產品文化」。
SmartBear 很榮幸成為這項為期三天的活動的贊助商，我也有機會與多位演講者和與會者談論這個主題，以及 API 領域的許多其他趨勢。在這次訪談中，我與 Chris Busse，APIVista 的 CTO 進行了交流，他在那裡幫助客戶設計、發布和支援 API。我 兩年前也對 Chris 進行過類似的訪談，所以很高興再次與他聯繫，看看自上次交談以來他獲得了哪些新的見解。
Chris 長期以來都是 API 產品方法的倡導者，並且第一手了解了這種方法帶來的挑戰和機會。在我們的對話中，我們討論了將 API 視為產品的重要性、「設計優先」API 開發的作用，以及他透過在 APIVista 的工作觀察到的其他趨勢。
您可以在下面觀看和閱讀我們的完整對話
我很高興能與 APIVista 的 CTO Chris Busse 一起。Chris，到目前為止會議如何？
太棒了！我從會議中真正欣賞的一件事是他們專注於將 API 視為產品。這對我來說非常重要。這是我喜歡處理 API 設計的方式，無論是在我的客戶還是我以前的工作中都是如此。
我不知道「浪潮」是否是正確的詞，但我們看到越來越多關於這個概念的討論，並且有更多人不僅能夠分享將 API 視為產品的理論，而且實際上能夠分享他們的成功。
說「您應該這樣做」是一回事。但說「我們是這樣做的，我們取得了成功，這是我們學到的。這是您可以應用什麼，以及您可以根據我們必須經歷的掙扎更快地到達那裡。」則是另一回事。
我知道您是 API「合約優先」或「設計優先」方法的忠實擁護者。您能否進一步說明設計優先思考如何應用於產品方法？
我認為，當涉及到 API 的產品方法時，設計優先思考是關鍵，因為您必須知道您正在為誰設計。我在過去一年中隨著我們在 APIVista 成長和招募開發人員時學到的一件事是，API 開發人員通常可以分為三類。
第一類是可能在做全端工作的人。他們正在建置的那些 API 實際上是為了他們自己。也許是為了讓他們可以暴露到 Angular 前端，或者可能是移動前端，但他們正在建置 API。只在這個領域工作的開發人員可能對 API 作為產品的概念沒有那麼多的認識。
該進程中的下一個層級是正在建置 API 的開發人員，也許他們沒有在做使用者介面或前端，但他們身邊有一個可以轉身交談的人。在這種情況下，API 是為了他們認識的人而設計的，他們不需要那麼多的關心或文件就能理解，並且可以透過口頭傳達價值。他們可能不需要我們在討論將 API 視為產品時經常談到的精確度。
第三種是為您直屬圈子以外的人建置 API 時。那可能是大型企業中我甚至不知道他們在組織結構圖中的位置的人，或者可能是最終成為完全陌生人的合作夥伴。
當我們將 API 視為產品時 — 人們喜歡使用術語「API」並說 API 應該是一種產品 — 但我確實認為產品化有其時間和地點。當您為不認識您的人建置 API 時，產品思維就變得至關重要。最終消費者現在是我們的客戶。
了解消費情境也很重要。最終消費者是開發人員，但該開發人員正在為另一個客戶使用您的 API，因此您也需要了解這方面的情況。我們已經開始與一些將 API 發布給合作夥伴的客戶一起使用的一個詞是「共同創造」的概念。我們正在共同為您的客戶創造一些東西。
因此，我不僅需要了解您將如何消費我的 API 產品，還想知道它正在推動什麼商業價值。您正在為您的使用者創造什麼樣的使用者體驗？這樣一來，我也能思考「這對我的後端系統有什麼影響？」。這與介面有關，但也涉及效能和這些 API 的非功能性需求。
即使只是了解最終消費者的業務週期 — 他們的業務週期是否會出現季節性，他們是否會看到流量高峰？它確實可以幫助您思考您交付的所有方面的內容，以及 API 需要暴露的功能。
API 的產品思維需要付出很多努力，您希望最大限度地發揮這種思維的影響。我認為這是一個非常有趣的看待方式，它也提供了一個應用產品思維的框架。
要讓某個東西成為產品，您需要有客戶。如果您是為自己建置，是的，您就是您自己的客戶。也許您需要做一些關於您做過什麼、為什麼這樣做的筆記，但您沒有和客戶在一起。因此，我認為 — 就像我對將 API 視為產品感到興奮一樣 — 始終要記得將精力花在最能發揮價值的地方。
設計優先思維在紙上令人驚嘆，但公司在實際實施該流程時面臨真正的障礙。根據您的經驗，您認為實施設計優先的最大挑戰是什麼？
這需要很多工作！我們有一個客戶的合作非常順利，那是因為一些團隊之間已經存在著牢固的、預先存在的關係。他們的業務目標非常一致。在這種情況下，我們所有人都一致認同這個北極星。因此，不僅有使用者介面團隊和中介軟體團隊或 API 團隊正在建置的共享 API 合約，而且還有他們認為是一種業務的共享北極星目標，他們都在朝著相同的目標努力。如果您想反過來思考，那就是人們可能有點太孤立的地方。
有些組織的成功在於完成待辦事項清單中的故事。真正重要的是從一些日常工作中抬起頭來，記住成功是交付商業價值和客戶價值。
我認為，當人們真正圍繞著他們的北極星保持一致，並且他們將合約優先方法視為有助於實現這一目標、實現協調和高品質產品的工具時，您就會看到這種方法的成功。
我知道您在上次我們見面時的會議上談到了客戶的用例。您能否分享更多相關資訊？
在那個例子中，我談到了平行開發，使用者介面在與模擬 API 同時進行的情況下開發，而後端也在同時建構。團隊之間有很大的信任，相信他們最終會整合成功。當人們去了解客戶，然後以 MVP 的方式逐步建立整個系統時，會更容易獲得成功。我認為從 API 發布的角度來看，這才是更常見的應用案例。
好的，Chris，這次的談話很棒。非常感謝你撥冗分享這些經驗！
感謝您的閱讀！正在尋找更多 API 資源嗎？訂閱 Swagger 電子報。每月接收包含我們最佳 API 文章、培訓、教學和更多內容的電子郵件。訂閱