2018 年是 API 世界轉型的一年。
諸如 OpenAPI 規格 (OAS) 等開放標準已廣泛成長和採用，API 工具領域的領導者，如 AWS API Gateway 和 SwaggerHub 也擴展了對 OAS 3.0 的支援。我們也看到供應商持續整合的趨勢，包括 2019 年 3 月 Salesforce 以 64 億美元收購 Mulesoft，以及 2018 年 7 月 Broadcom 以 189 億美元收購 CA Technologies。
在 Smartbear，我們很高興為我們的 API 工具帶來許多新的進展，包括 Swagger Inspector 的發布，用於探索和產生現有 API 的 OAS 3.0 定義；API 標準化的發布，用於大規模強制執行 API 標準；以及 SwaggerHub 中 OAS 3.0 程式碼產生支援；以及 新增的原生 Jenkins 外掛程式，以支援我們的使用者在 ReadyAPI 測試平台中不斷發展的工作流程。
在 2018 年，我們也看到軟體團隊對新平台的投資增加，以協助促進他們的 API 開發。如今，超過 20 萬個 API 提供者正在利用 SwaggerHub 來標準化他們的 API 設計，並透過 OpenAPI 規格擴展他們的 API 開發。我們有機會聽取這些團隊中幾位領導者的意見，他們分享了他們如何透過採用 SwaggerHub 來支援令人難以置信的成長或使他們的 API 工作流程現代化。
當我們邁向新的一年時，我們想借用一些這些故事，並強調為什麼更多軟體團隊在 2019 年投資 API 開發平台的原因。
1. 標準化是擴展的關鍵
我們一再從在 API 數量不斷增加的組織中工作的 API 架構師那裡聽到的事情之一是，缺乏標準化是他們團隊的時間和資源的最大負擔之一。
對於大多數團隊來說，設定和強制執行 API 標準的過程完全是手動的。通常，這個過程涉及多個團隊或團隊成員，而且隨著 API 和利害關係人數量不斷增加，這個過程會變得更加痛苦。
這是 Viasat 團隊在 2017 年採用 SwaggerHub 時面臨的問題。根據 Viasat 的軟體工程師 Roger Prenger 所說：
「我們有很多介面使用相同的資料類型，而且我們一直在努力解決不同介面上資料外觀的變化。問題是，它在一個 API 中被稱為一件事，在另一個 API 中被稱為另一件事，而在又一個 API 中被稱為第三件事。追蹤系統中的資料變得令人困惑。」
在 SwaggerHub 中，Viasat 發現可以使用名為 網域的可重複使用元件來標準化資料模型。透過網域，他們可以建立可在所有 API 中使用的通用模型，而無需額外的強制執行。
「我們找到了一種在 SwaggerHub 中使用網域的方法，以擁有一個通用的基本資料結構，我們可以在所有 API 中使用它。」
2. 消除溝通障礙
在現今比以往任何時候都擁有更多溝通管道的時代，您會認為協作將是一個完全簡化的過程。不幸的是，我們經常從新的 SwaggerHub 使用者那裡聽到的情況是，分散的溝通管道（Slack 訊息、電子郵件、JIRA 評論）可能導致對 API 生命周期中所做的變更缺乏可見性。
當涉及到 API 開發時，尤其是在規劃和設計的早期階段，擁有一個用於溝通變更、提出問題和提供回饋的標準格式，對於避免下游問題至關重要。當您跨團隊和跨地區工作時，這變得更加重要。
這是我們從 Bonotel 的 CIO Scot Hastings 那裡聽到的：
「SwaggerHub 大大改善了我們內部團隊和外部合作夥伴之間在 API 開發方面的溝通。這很關鍵，因為我們在內部不做大量的 API 開發，大多數工作都是透過我們的合作夥伴完成的，他們也互相合作。SwaggerHub 充當所有移動部件之間協作的集中主機，使流程非常高效、直觀且無縫。」
協作是否正在成為您目前 API 開發工作流程中的障礙？了解 Bonotel 如何在 SwaggerHub 中簡化協作。
3. 設計優先的轉變
在 2018 年，我們看到越來越多的組織採用「設計優先」的 API 開發方法。在 2018 年 10 月進行的對 3,000 多個 API 提供者的調查中，我們將於 2019 年 1 月正式發布，我們發現近一半的組織至少對正在開發的某些 API 遵循設計優先的方法。
轉向設計優先的方法可幫助團隊在 API 開發的早期階段獲得一致性，從而減少錯誤、加快迭代速度，並實現並行開發。這是 Realpage 行動開發總監 Travis Koenig 在 SmartBear 用戶會議 SmartBear Connect 上談論「現代化企業 API 開發流程」時所討論的。
正如 Travis 解釋的那樣：
「SwaggerHub 使我們能夠以先前不可能的方式執行專案，讓我們的整個生命週期的許多團隊能夠更並行地執行，並加快開發速度。」
4. 集中 API 探索
內部探索是一個挑戰，通常在多個團隊和利害關係人參與 API 的開發和維護之前會被忽略。與探索相關的常見問題之一是如何找到並使用最新版本的 API。當團隊依賴像 Github 這樣的原始碼控制主機不僅儲存原始碼，還儲存 API 定義時，通常會發生這種情況。
這就是為什麼我們在 SwaggerHub 中建立了支援託管和版本控制 OAS 定義和 API 文件功能的原因。 SwaggerHub 可以作為團隊探索現有 API 的中央儲存庫，並讓開發團隊將存取權限分配給具有不同角色的相關利害關係人，包括 API 設計者和使用者。當 SwaggerHub 中的內容發生變更時，這些變更也會同步到您的 Github 儲存庫，使 SwaggerHub 成為您 API 文件的事實來源。
Evosus, Inc. 的架構師 Steve Hawkins 解釋了在 SwaggerHub 中改善 API 探索如何幫助降低成本和努力：
「 SwaggerHub 為我們 API 的開發和呈現提供了一個有效的入口網站。我們將 SwaggerHub 用作 API 使用者的參考文件。我們了解到，實作我們 API 的開發人員正在使用程式碼產生選項來減少他們的工作量和成本。」
5. 超越開源工具
作為開源 Swagger 工具背後的公司，我們了解開源的力量，特別是對於那些試圖快速擴展並希望消除技術障礙的組織而言。但隨著您的 API 程式不斷成長並變得更加複雜，顯然需要有工具來支援您的工作流程。
這也是 Viasat 的系統工程師 Cyndi Recker 在她在 SmartBear Connect 2018 上發表的演講「透過設計優先的方法支援快速系統成長」中所討論的內容。
「在『擴大規模』階段，您會迅速採取行動，試圖將所有內容整合在一起。當您通過擴大規模階段時，您真的需要鎖定一些業務運作方式。在改用 SwaggerHub 方面，這對我們來說是一個優勢。Swagger 開源是您在 SwaggerHub 中獲得的基礎，但我一直被問到，為什麼我應該改用 SwaggerHub？我可以告訴您，隨著您的團隊成長、您的產品成長、您的市場成長，這才是解決問題的方法。」
擁有支援您成長的工具將有助於打破隔閡、改善協作，並減少可能阻礙建構可擴展 API 程式的摩擦。而且由於 SwaggerHub 將 Swagger Editor、Swagger UI 和 Swagger Codegen 等工具的功能整合到一個中央平台中，因此改用 SwaggerHub 對您的團隊來說將是一個無縫的過程。
準備好迎接 2019 年了嗎？
我們很高興看到超過 20 萬名 SwaggerHub 使用者和數百萬名 Swagger 開源使用者在 2019 年取得的所有偉大成就。我們將繼續發展我們的工具，以滿足現代 API 團隊的需求，建構新的功能來幫助您完成工作，並與您信任的工具整合，以交付高品質的 API。
讓 SwaggerHub 成為您 2019 年 API 之旅的一部分。 按一下此處立即安排演示。