我們在 Swagger 部落格上撰寫了許多關於 REST API 的文章，但我們一直在尋找來自 API 世界各地的新觀點。
超媒體 API 受到越來越多熱衷者的擁護。API 傳道者和 API 架構師 Michael Hibay 就是其中一位，他積極參與向科技界宣導超媒體的優點、缺點以及如何有效採用這種風格。
雖然傳統的 HTTP REST API 非常適合處理多種類型的呼叫，但處理版本控制和棄用問題已成為重要的限制，可能會對用戶端和伺服器的演化能力產生負面影響。這就是 超媒體即應用程式狀態引擎 (HATEOS) 架構風格可以派上用場的地方。
HATEOS API 可以有效地協助伺服器和用戶端分離，讓您可以獨立演化和更新它們，而彼此之間沒有相依性。這種架構風格讓您可以在回應內容中使用超媒體連結，以便用戶端可以透過遍歷這些超媒體連結來動態導覽至適當的資源。
我有機會與 Michael 交談，討論他對他最喜歡的主題的看法，並且也聽取了他對 OpenAPI 規格 — OAS 3.0 最新發展的看法。
是什麼讓您對超媒體產生興趣？
事實上，是 Swagger 讓我第一次對超媒體感到興奮。我的任務是為應用程式設定 OpenAPI 規格設定檔，並結合 HATEOAS（超媒體即應用程式狀態引擎）的元素。我了解 HATEOAS 的概念，儘管並非那麼深入。我越深入研究基於超媒體的程式碼程式庫和產品支援，我就越感興趣。
透過這個過程的教育，我了解到：「嘿，我不能這樣做，而且不僅我不能這樣做，而且沒有人能這樣做，因為目前它們是無法一起完成的事情。」一旦我開始研究，我真的就深入了那個兔子洞，我發現解決方案是超媒體。
隨著時間的推移，我發現有些時候社群內會出現焦慮感。超媒體的聲譽也帶來了一些包袱，因此必須改變許多人的觀點，但也必須利用我所知道和學習到的知識，真正幫助其他人解決他們的問題。
您認為組織採用超媒體有什麼優勢？
從組織和實務的角度來看，超媒體可以大大降低 API 使用的複雜性。它還可以最大限度地降低基礎架構成本，如果適當地完成和實施，它可以真正減少更新和維護 API 所需的思考量。
一旦組織採用基於超媒體的方法來開發 REST API，建置 API 的學習曲線就會相當短。這讓開發人員可以更有效率，讓資源分配更容易。超媒體主要有助於長期發展，而且從組織的角度來看，如果您考慮總持有成本，可能會有 25% 的成本是 API 的實際初始開發期，而您將在產品推出後將 75% 的資金用於其他所有項目。
超媒體屬性有助於使長期 API 演化能力和長期成本大大降低，因為超媒體的基本屬性是它很容易隨著時間的推移進行塑造和演化。當您的用戶端不像 OpenAPI 規格提出的那樣與您的伺服器緊密耦合時，您就可以更自由地專注於營運，並隨著時間的推移根據需要變更表示形式，讓您的組織可以非常輕鬆地進行這些變更。
組織在採用超媒體途徑時似乎有很多好處。您認為組織會面臨哪些阻力或挑戰？
俗話說，附註總是說，讓超媒體開發變得容易所需的工具尚未開發出來，這是事實。要理解在設計 API 時考慮到超媒體也並不容易，尤其是在有消費方面的情況下。消費者通常習慣於與 CRUD API 整合。很難改變他們「我正在尋找 CRUD API，而這看起來不像 CRUD API，我該怎麼辦？」的態度。在教育方面存在許多滲透和採用挑戰，阻礙了它。
但最近，我開始意識到最大的挑戰是，許多產業實際上都把重點放在錯誤的事情上。雖然有許多非常好的超媒體格式和非常好的資源，可以讓您更容易使用超媒體，但實際上沒有人關注用戶端。超媒體是為了讓用戶端更容易。而我認為這實際上是目前最大的障礙—缺乏通用的用戶端，可以降低使用 API 的門檻，使它們對非專業、非技術消費者來說也一樣可用。一個可以將超媒體的可演化性與使用命令列上的 CURL 呼叫 CRUD API 的簡單性結合在一起的用戶端。我認為這才是主要的重點。事實上，這也是我在今年 API 策略與實務會議上談話的主題。
說得很好！您在先前關於挑戰的回應中提到了設計，我想知道產業如何處理超媒體設計。
當您查看設計超媒體 API 與 CRUD API 時，您實際上必須先談論網域，然後才能從網域本身（包括網域模型）反向建模所有內容。您談論資源以及它們可以做什麼，然後從那裡反向工作。
要讓熟悉 OAS（OpenAPI 規格）這種所有東西都靜態綁定的開發者，轉而適應所有東西都是動態的環境，是相當困難的。但我認為重點在於，如果你在進行超媒體設計，實際上是在建立我所謂的「設計範圍」。從根本上來說，你要先撰寫詞彙表、你的領域模型，然後再反向使用協定綁定，從開發技術的角度來製作日常工作的工具和測試。你要從領域出發，然後將它以暫時性的方式綁定到你的協定，無論那是什麼協定。接著，要確保你的客戶端不要綁定到任何超出特定生命週期的定義，這樣在你無法控制的組織外部使用者，就不會綁定到像是會隨時間變更的 URL 之類的東西。
有些組織採用了超媒體，但這種採用尚未達到臨界規模，因為使用者採用非常困難。你會發現許多成功案例都來自客戶端。他們實際上會控制客戶端。
依您之見，您認為有哪些組織或 API 是採用超媒體格式並取得成功的良好範例？
Comcast 是我見過真正最成功、且大規模使用超媒體的組織之一。我當然隨時都在注意，希望能找到更多範例。
您認為 OpenAPI 規格 3.0 可以滿足以超媒體為中心的組織嗎？如果必須說一個大概的百分比，OAS 對超媒體的相容性是多少？既然我們知道人們喜歡數據，您會怎麼說？
OpenAPI 規格基本上是一項很棒的工作，許多聰明人付出了極大的努力來解決問題。我相信它絕對朝著正確的方向前進，而且絕對可以幫助超媒體愛好者設計出色的 API。
OAS 3.0 仍然有些地方無法完全滿足基於 HATEOAS 的架構，這是意料之中的，因為它並不是為了解決這些問題而建立的。超媒體的動態性質不會帶來操作和演化上的困難；OAS 基本上是一個靜態設計框架。當你靜態定義你的介面，並將其綁定到你實際在 URL 中發布的表示形式時，你已經為整個宇宙創建了一個合約，讓他們可以訂閱。如果你對合約進行任何更改，都會對你的使用者造成連鎖反應，所有這些都違背了 HATEOAS 所啟用的解耦客戶端伺服器的基本性質。
但大多數情況下，我認為最新的規格在找出 2.0 中存在的漏洞方面做得很好。OAS 3.0 消除了格式中先前的不一致之處，真正允許設計人員在不使用過於複雜的格式的情況下，架構出色的 API。
是什麼讓您對開發者倡議和技術傳播產生興趣？
[笑] 我是整體技術倡議領域的新手。我投入其中的動機，實際上是希望幫助開發人員不要面臨我之前遇到的相同問題。我透過許多產業進行過各種 API 開發，範圍涵蓋大型公司、小型公司到小型新創公司。我真的希望幫助人們不要犯我犯過的錯誤，並消除我職業生涯中難以克服的障礙。
我們對 Michael Hibay 的訪談是 Swagger 部落格持續進行的專家訪談系列的一部分。請查看另一篇與 OpenAPI Initiative 的 Darrel Miller 的熱門訪談。