REST – 善，恶，丑

在他一篇新博文中，Arnon Rotem-Gal-Oz 表达了他关于 REST 的意见 (来自 Arnon 的关于 REST 更一进步的讨论可参见这里)

根据 Arnon 的说法，使用的 REST 最主要的三大优势是：

• 相对容易的集成： > …一个好的 RESTful API 从前面最初的 URI 就可以发现。这并不意味着任何一个调用你的服务的应用都能神奇地知道该做什么。而是意味着读取你的 API 以试图集成它的开发者能过得很轻松。特别是有了多媒体为你提供下一步要做什么的路线图。
• 使用普适的标准 -HTTP 是最普遍的 REST 实现： > 说到 HTTP 这一 web 协议，发出 JSON 或者 ATOMPub 意味着找到一个在任何语言任何平台都能连接到你的库变得非常容易了。
• 伸缩性： > …无状态的通讯，复制存储带来了良好的伸缩性潜质。

Arnon 同时讨论了一些 REST 的劣势。在他看来，REST 的两大主要劣势是：

• “低端 REST”(仅仅使用 GET 和 POST) 实现，又特指 REST over HTTP: > 虽然从技术上来说它应当是 RESTful，但对于我而言二个动词的统一接口也未免太小了以致于起不到什么真正的作用 (事实上导致了不少非 RESTful 的实现)
• 现今编程语言的局限： > …编程语言并非是面向资源的，所以映射 URI 的处理代码可能会变得一团乱麻。另一方面，相对而言很难使得 REST API 是超文本驱动的 (这也是 REST 的一个限制)

最后，Arnon 指出了 REST 一些糟糕的例子，这大部分是由于对 REST 的滥用而造成的:

• 狂热的追随者 (Arnon 所用的措辞 - 再次证明 REST 的争论经常会上升成信仰) > 这并非仅只针对 REST，任何好的技术 / 思想 (Agile,TDD 等等) 都会有一部分追随者认为它 [加入最喜爱的相法] 是有史以来最好的东西，任何人都应该像他们一样去做或者差不多。
• 对于 REST 的误解： > …构建一个 GETsful 的实现 (比如，用 http GET 去完成所有的事情) 或者使用原始的 RPC，URI 即是命令，使用 HTTP 动词进行 CRUD 操作，等等。

Arnon 以这样陈述总结了他的文章：

REST 看似容易实则不然 - 它要求转换思路 (比如，认定资源，外部化状态转移等等。)…做得好的可以成为你工具集当中重要而有用的工具之一，[否则]…就像任何架构 / 技术一样 - 一个拙劣的实现可以抵消掉所有的益处

关于 WS* vs. REST 的 SOA 争论看似无穷无尽。实际上任中一个都不是“万金油”(要小心"大锤" 综合症)。

…当你全盘的考虑整个业务的时候你必然会发现某些地方不一样的架构原则非常合适。架构风格 (以及架构模式) 是你用于解决挑战的工具。有些地方使用锤子非常合适，但保证你的工具集中不仅仅只有一把锤子也是非常明智的。

例如：大多数 REST 实现不支持异步调用和事件。因此，事件驱动架构风格对于 REST 来说可能就是不合适的。另一个例子，SOAP 信封提供的业务与基础设施影响相分离现在留给了 REST 的实现者来处理。所以，要求对基础设施影响进行大量潜在变更的实现恐怕对于 REST 就不太合适了。

由于 Web 2.0 的进步，特别是 Mashup 和 AJAX，REST 最近获得了更多的拥护。这些情况下，REST 通常是使用 Javascript 来访问并使用 JSON 作为编配机制。基于此，许多 REST 的支持者声称 REST 比起大量的 WS* 标准而言更易于消费。诚然，如果你“手工”实现消费者的话，确实如此。换个角度来看，许多编程语言里都有由 WSDL 产生服务消费者的工具，使得这一工作微不足道了。

REST vs.[某某某] 的清单永远也列不完，而且完全取决于这一清单的作者。Arnon 在他的文章里为实施方案选择合适的架构提供了一个很好的借鉴。

查看英文原文： REST – The Good, the Bad and the Ugly