超媒体API引发的REST生存危机_语言 & 开发_Jerome Louvel

《泛智能开启下一代云时代》白皮书来了！点击下载了解详情 



 写点什么

几周以前，软件开发者 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 变更与客户端隔离的所有努力化作泡影。