我们已经在 Swagger 博客上写了很多关于 REST API 的文章，但我们一直在寻求从 API 领域的各个方面提供新的视角。
基于超媒体的 API 受到越来越多爱好者的推崇。API 倡导者兼 API 架构师 Michael Hibay 就是这样一位积极致力于向科技界普及超媒体的优点、缺点以及如何有效采用这种风格的人。
虽然传统的 HTTP REST API 在处理多种类型的调用方面表现出色，但处理版本控制和弃用问题则成为重要的限制，这可能对客户端和服务器的可演进性产生负面影响。这就是 作为应用程序状态引擎的超媒体（HATEOAS）架构风格可以提供帮助的地方。
HATEOAS 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 的人（OAS 中一切都静态绑定）进入一个一切都是动态的环境是困难的。但是，我发现重要的是，如果您正在进行超媒体设计，您实际上建立了我称之为“设计范围”的东西。从根本上讲，您编写词汇表、领域模型，然后通过协议绑定反向工作，从开发技术角度来看，进行日常工作的工具和测试。您从领域反向推导，然后以瞬态方式将其绑定到您的协议，无论该协议是什么。然后确保您的客户端不会绑定到超出特定生命周期的任何这些定义，这样您无法控制的组织外部的消费者就不会绑定到像 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 的热门采访。