可以这么说，仅仅是提到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?
chainding 