超媒体 API 引发的 REST 生存危机

几周以前，软件开发者 Evan Cordell 在 API-Craft 邮件组中引发了一场对话，就关于 REST 在超媒体方面的约束，与常见 Web API 需求之间如何存在分歧进行了讨论。

在讨论“REST 的生存危机（RESTisential crisis）”话题的时候，Cordell 注意到，经过数年之久的辩论和实践，REST 风格终于开始透露出它藏得最深的秘密——超媒体约束。尽管 Web 证明了 REST 风格完美适用于人类驱动的交互，但对于它在一般性可编程 Web API 方面的效用的担心，在 Web API 社区中却似乎在不断上升。

在这场讨论中，他首先给出了 REST 的描述，以及在面向特定领域 Web API 时超媒体的制约，接下来考虑了对其他架构风格的需求，选用 REST 中最好的部分，并替换掉其中的一些约束，以获得不同的价值，例如有效和可靠的 M2M（Machine-to-Machine）通讯。

讨论中所列出的主要担忧，涉及了不同的途径，用来应对接口随着时间推移而产生的变更。第一套解决方案要求并行运行若干 API 版本，甚至若干 API 编配以用于特定客户端体验，例如Netflix 所展示的做法。其灵活性方面则需要面对设计和运营方面的重大挑战。

第二个解决方案要求预先投入更多的努力，来设计一套更易于应对变化的RESTful 超媒体API，并限制对客户端的影响——就像HTML 浏览器和服务器的工作和演进那样。但部分讨论参与者（特别是Web 工程师 Mike Kelly ）对此表达了自己的担心，主要集中在实现该方案涉及的复杂度和 API 使用者需要承担的额外负担方面。以下是讨论摘要，包括对 Evan 最初帖子内容和章节标题的摘录：

1) 好的 API 不会发生变化

• 考虑一下 Joshua Bloch 在设计公共 Java API 方面的经验，我们似乎可以认为，相同的规则也可以运用到可编程 Web API 上。
• API 是遵循外观模式的接口，面向客户端的部分不应该发生变化。然而，可以将多重或演进的实现（包括运行时数据）暴露出来，而无须改变 API 约定。

2) 版本管理不起作用

与“传统”API 相比，“Web API”公开出来的内容要多得多。它暴露出数据；而且对于持续变化数据的大型集合，它通常还会把其当前状态公之于众。那么，当我们的领域模型拥有两个版本，它们共享部分数据子集但使用不同方式访问的时候，该如何有效的进行版本管理？这会强迫客户端发生分裂。

• 超媒体能够帮助 API 演进并变得不那么脆弱，但是如果数据和领域模型发生根本性改变，那么在没有开发者人工介入的情况下，客户端将无法自动适配这些变动。

3) 超媒体毁掉了资源定位

• REST 阻止了来自客户端的固定 URI 和任何关于服务器资源的先验知识。在实践中，保存了 URI（例如书签）和服务器的客户端，需要处理其 URI 空间的演变（重定向）。
• 超媒体无法将 API 提供者与 API 使用者的惰性行为隔离开，后者将不会遵循恰当的超媒体流，而是直接针对目标资源和 URI。
• 由于超媒体 API 往往非常复杂，难以理解和使用，所以开发者将必然会优化其客户端并采用捷径——而这将会使为了将 API 变更与客户端隔离的所有努力化作泡影。

4) 对人类用户来说，超媒体富有意. 义；但对机器则并非如此

• 机器并不善于处理随时间推移发生的变化，相反人类则非常擅长解读变更并决定下一步想要做什么。超媒体与人类在本质上非常贴近，而对机器来说这意味着相当程度的隔阂。
• 领域模型方面的变动，要求客户端使用它的方式也发生改变，超媒体并没有对此采用什么特别的手法。

一个真正的 REST/ 超媒体客户端，其实是人机交互（HCI）的一种形式，而不是 API。（或者说，是 AHI——应用与人交互）。

5) 带外数据究竟有什么坏处？

• API 是否真的有必要天生可发现？
• 当 API 响应的格式具有高度复杂性、难以阅读的时候，API 凭什么应该具有自我说明性（self documenting）？
• 真正易于阅读的材料应该是：组织结构精妙的 HTML、由浏览器渲染、具有交互式例子和清晰的描述。

6) 超媒体 API 与 WADL 真的不一样吗？

可发现的超媒体 API 有什么不同？“HAPI”看上去就像是一套 WADL 弥漫其中的 API。我们依旧必须从单独一个端点开始，依旧必须了解基于其响应，我们可以用 API 干什么。

• 其中部分必须具有领域模型的描述，而它们还将随时间推移发生改变。

7) Web 的模拟

• 假定这样一个场景：在原生移动应用中使用 REST API，我们拥有两门语言（Android ML 和 iOSMLS，分别拥有所需的代码）；
• 使用针对特定领域的超媒体媒体类型，依旧需要编写能够理解这一领域的客户端代码。

8) 关于 REST，有哪些是真正的优点？

• 除了超媒体和文档网（Web of documents）外，REST 还提供：

  • 强制要求无状态服务器，从而使其易于扩展
  • 鼓励通过资源将信息解耦合

基础内容非常简单，我们可以与服务器以语义上富有意义的方式进行对话，而且只需要在所有平台和语言中包含 http 库即可。

以上摘要包含了对若干讨论参与者回复内容的摘抄，特别是 Evan Cordell，以及 Mike Amundsen、Jorn Wildt 和 Mike Kelly。作为免责声明，需要指出的是，本文作者也在开始阶段参与了这场讨论。

从自身的经验来看，各位读者是否认为我们需要更好地区分 REST 和 Web API 架构风格，区分人类驱动超媒体和 M2M 通讯的使用案例？

查看英文原文： RESTistential Crisis over Hypermedia APIs