我们在 Swagger 博客上撰写了很多关于 REST API 的文章，但我们一直在寻求来自 API 世界的新视角。
基于超媒体的 API 受到越来越多的爱好者的拥护。Michael Hibay，API 布道者和 API 架构师，就是这样一位积极参与向科技界宣传超媒体的好处、缺点以及如何有效采用这种风格的人。
虽然传统的 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 的人（在 OAS 中一切都是静态绑定的）投射到一切都是动态的环境中。但是，我发现重要的一点是，如果您正在进行超媒体设计，您实际上会建立我所说的设计范围。从根本上说，您编写您的词汇表、您的域模型，然后使用协议绑定来反向工作，以便从开发技术的角度进行日常工作的工具和测试。您从域反向工作，然后以瞬时的方式将其绑定到您的协议（无论该协议是什么）。然后确保您的客户端不会绑定到超出特定生命周期的任何这些定义，这样您无法控制的组织外部的消费者就不会绑定到诸如随着时间推移会更改的 URL 之类的东西。
有些组织采用了超媒体，但这种采用尚未达到临界规模，因为消费者采用非常困难。您发现成功的许多公司都来自客户端的角度。他们实际上会控制客户端。
您认为，哪些组织或 API 在采用超媒体格式方面取得了成功？
我见过的真正最成功地大规模使用超媒体的最大组织之一是康卡斯特。我当然一直在密切关注以寻找更多。
您认为 OpenAPI 规范 3.0 可以满足以超媒体为中心的组织吗？如果必须说，OAS 对超媒体的合规性百分比是多少（因为我们知道人们喜欢数据），您会怎么说？
OpenAPI 规范从根本上来说是一项伟大的工作，很多聪明的人为了理清它付出了巨大的努力。我认为它绝对朝着正确的方向前进，并且肯定可以帮助超媒体爱好者设计出色的 API。
OAS 3.0 仍然有一些地方不能完全满足基于 HATEOS 的架构，这是意料之中的，因为它并非为解决这些问题而构建的。超媒体的动态性带来了操作和演变方面的困难；OAS 本质上是一个静态设计框架。当您静态地定义接口，并将其绑定到将要发布到 URL 中的实际表示时，您就为整个世界创建了一个订阅的契约。如果您对契约进行任何更改，它都会对您的消费者产生连锁反应，而所有这些都违背了 HATEOS 所支持的解耦客户端服务器的根本性质。
但在大多数情况下，我认为最新的规范在真正识别 2.0 中存在的漏洞方面做得很好。OAS 3.0 消除了格式中先前的不一致性，真正允许设计人员在没有过于复杂格式的情况下构建出色的 API。
是什么让您对开发者倡导和技术传播产生了兴趣？
[笑] 我是技术倡导领域的新手。我进入这个领域的动机是真正帮助开发人员避免遇到我之前遇到的同样问题。我曾在许多行业中进行过各种 API 开发，从大公司到小公司再到小型初创公司，我全都经历过。我真的想帮助人们避免犯我犯过的错误，并消除我职业生涯中难以克服的障碍。
我们对 Michael Hibay 的采访是 Swagger 博客上正在进行的专家访谈系列的一部分。查看另一篇与 OpenAPI Initiative 的 Darrel Miller 的热门访谈。