REST架构实质（转）

REST(Representational State Transfer) 曾经被误解为只是CRUD（增删改查），从这个层面上，好像REST只是和RPC一个层面的东西，没有什么了不起，其实这些都是对REST误读。

理解REST需要从系统集成整合以及架构的伸缩性方面入手，这方面有一篇很重要的REST博文： I finally get REST. Wow.
http://www.pluralsight.com/community/blogs/tewald/archive/2007/04/26/46984.aspx

作者认为：每个通讯协议都有一个状态机，当你使用RPC时，你要做些方法来改变通讯的状态，但是这些状态是封装在服务器端或客户端的专门通讯模块中，比如通过Hessian/SOAP等Proxy技术进行RPC调用，虽然可以在客户端很方便地象调用本地服务一样，缺点总是伴随优点到来，由于Proxy封装了客户端和服务器的通讯，就很容易让客户端和服务器紧耦合。

这其实是C/S架构的一个本质问题，而B/S架构通过简单的浏览器则解耦了客户端和服务器的耦合，别小看丑丑的浏览器，特别是当初还没有AJAX辅助时，浏览器被很多传统C/S讥笑和不屑，但是他们不知道B/S架构后面蕴含的深刻朴实的设计道理，是真正大道至简。所以，当我们重新回归RIA富客户端代表的C/S架构时，必须吸取Web架构的本质优点，这样才是螺旋式上升。

回归话题，由于传统架构隐藏了通讯模块进而发生了紧耦合，而REST最大作用则是将通讯状态以URI显式表现出来，也就是将通讯状态的透明性，这样做最大的好处就可以在通讯环节引入伸缩性。

REST核心思想就是：以URI形式将状态机表现为动态的节点图，我们就能引入动态负载平衡dynamic load-balancing, 数据重导向data-directed-routing, versioning 等其他正常的Web底层设计架构Web infrastructure，从而使客户端和服务器之间服务器之间享受Web架构的好处。

谈到系统集成，SOAP/Web服务/SOA被厂商吹嘘了很多年，很多应用也在使用SOAP，SOAP和REST无疑是相互竞争的，SOA其实也是一种的RPC，是一种基于XML的RPC，因此，同样存在通讯状态隐藏的致命问题。

上述博客作者写了另外一篇文章来比较(http://www.pluralsight.com/community/blogs/tewald/archive/2007/04/27/47031.aspx)
比如，两个城市之间航班看成一个协议，这个协议有下面几个状态：
<ready>
- searched (查询)
- retrieved details (获得细节)
- reserved (预订)

通过URI表现出来是：
<none>
- http://quuxTravel.com/searched
- ??? depends on previous state
- ??? depends on previous state

客户端通过get方式http://quuxTravel.com/searched?src=London&dest=NYC进行查询，得到结果如下：
<itineraries>
<itinerary src=“London“ dest=“NYC“ price=“400.03“>
<getDetails uri=“http://quuxTravel.com/details?itinerary=402“ />
<reserve uri=“http://reservations.bookingsunlimited.com/quuxTravel?itinerary=402“ />
</itinerary>
<itinerary src=“London“ dest=“NYC“ price=“109.88“>
<getDetails uri=“http://quuxTravel.com/details?itinerary=219“ />
<reserve uri=“http://reservations.bookingsunlimited.com/quuxTravel?itinerary=219“ />
</itinerary>
</itineraries>
客户端目前处于“查询”状态，通过遍历上述itineraries旅游线路结果集合，寻找出最便宜的一家，如果用户想查询一个不在上述结果的信息比如飞行总体时间，他能通过上述结果属性getDetails/@uri中保存的URI信息再次GET获得，这样就会切换到 retrieved details状态。然后又会回到searched状态。

当用户选择一条路线后，通过保存在reserve属性中的URI值就进入 reserved状态，客户端得到一些reserved方面的信息，至此，整个业务算完成了。

如果使用RPC如何来完成呢？我们必须创建一个接口如下：
interface IFlightSystem
{
Itineraries Search(string src, string dest);
Details GetDetails(int itineraryId);
Confirmation Reserve(itineraryId);
}
客户端可以通过调用这个接口的几个方面来完成上述一些业务.

在这里，接口表达了和前面REST同样的协议，所不同的是, RPC客户端依赖服务器端这个接口，也就是两者通过接口耦合了，更致命的是：searched (查询) retrieved details (获得细节) reserved三个状态耦合到同一个服务器中，如果我们想将这三个状态分离分散到多台服务器上，除非重写服务器端代码，否则无能为力。

而在前面REST调用中，每个状态都是通过URI重新定位，这样，我们可以在这三个状态中引入伸缩性，比如searched状态的URI在A服务器，而retrieved details的URI则是B服务器的网址，而reserved的URI则是c服务器，看看我们的业务不再是铁板一块了。

这就是REST本质魅力，REST和RPC/SOAP本质区别是透明性。REST透明性可以让我们以更细粒度引入伸缩性，这样以REST为主要形式可以组建一个分布式的大型架构，而这个目的恰恰是重量解决方案SOA提出的目标，现在我们有了另外一个轻量的选择。