超媒体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

转自 http://www.infoq.com/cn/news/2014/04/rest-at-odds-with-web-apis?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global