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