unREST 是新的 REST 吗？

可以这么说，仅仅是提到 REST 这个词就能引起人们的两极分化。有段时间 REST 努力抗击 WS-* 浪潮，随后出现了一个巅峰，这就像一个障碍，REST 开始走下坡路了，人们认为REST有好处，但也许没有其他人想象的那么多。抵制对“ REST 拥护者（RESTafarians）”相信的东西照单全收的主要倡导者之一就是 Jean-Jacques Dubray ，他最近发表了一篇文章，讨论他所谓的 unREST 。JJ 是这样开篇的：

自 2007 起，一小撮人告诉整个业界“Web”可以教会大家关于分布式计算的所有东西，我们之前所做的都是错的。四年过去了，我们只能说这一说法仍然未被证实。

JJ 论证的核心是 REST 在设计时考虑了浏览器，任何试图脱离该上下文使用 REST 的做法无疑都是 unRESTful 的：

REST 在设计时考虑了终端用户，操作用户代理：浏览器 […]。任何将 REST 原则应用于代理至服务器（agent-to-server）场景的软件的做法都是错的。[…] 是时候该继续前进了，这种非常规思路的复杂性没有带来一点好处，反而降低了生产力，它强迫所有人手工编码那些在上一种分布式计算范式中唾手可得的东西。

用 JJ 的话来说，REST“并不适用于目前的问题”，“做到 RESTless 很酷”。这意味着什么呢？JJ 列出了一些规则，包括：

• 定义领域专用统一接口：“不要害羞，忘记那 4 个 HTTP 动词吧，你甚至可以定义自己的动词：Query/Do/Notify/Synchronize 就很不错。它意味着你 Web API 中的全部方法都是查询、动作、通知或同步请求类型的。”
• 规定消息：对于需要相互通信的两个端点，它们必须要能理解所交换的消息。正如 JJ 所说的“能明确标明版本的消息定义对健康的 API 定义来说是必不可少的。消息可扩展性是让分布式计算运作的重要属性。”
• 规定端点之间的契约，并保证它们被打上版本：端点之间的接口和它们交换的消息是契约的组成部分。JJ 说把机器可读的契约变为只有人类可读的这种做法是行不通的，他相信其结果只能是浪费大量时间。“统一接口并不足以构成契约，它只是契约定义的基础部分。”JJ 坚信要构建“一个健康的 Web API 消费者生态系统”的唯一途径就是使用机器可读的契约，为它们标上版本以保证契约的进化和重用。

归纳起来：JJ 相信有了这 3 条规则我们就拥有了创建成功 API 的基础。他指出这篇文章并非基于自己的突发奇想，在过去的至少十年时间里他都在和基于 Web 的协议打交道，包括 ebXML。你认同他的观点或是他最后的评论吗？

你可以自由选择 unREST，暗地里嘲笑那些要求你对 HTTP 标头、“链接”、7 个首字母缩写（译注：估计是 REST API）惊叹不已的人，他们或许还会带着 REST 传道士的口吻说你其实并不理解 REST。REST 只是一个（恶）梦，unREST 才是你想要做的。

随着人们越来越多地讨论 REST，尤其是在云这样的领域里，如果JJ 是对的，那么要改变这些做法就为时已晚了，也有可能它们本身就已经是unRESTful 的了？也许unREST 正在回到那“糟糕的旧时代”？

查看英文原文： unREST as the new REST?