REST 架构风格

目前基于网络应用的架构风格主要有三种：

 

RPC架构风格   将服务器看做是由一些过程组成，客户端调用这些过程来执行特定的任务。SOAP就是RPC风格的一种架构。过程是动词性的（作某件事），所以RPC建模是以动词为中心的。

 

分布式对象架构风格    认为服务器是由一些对象和对象上的方法组成，客户端经过调用这些对象上的方法来执行特定的任务。而且客户端调用这些对象上的方法应该就像是调用本地对象上的方法同样，这样开发就能够彻底按照统一的面向对象方法来作。可是很惋惜，这样的抽象并非颇有效，由于分布式对象与本地对象存在着巨大的本质差异，想要掩盖这些差异不少时候甚至是有害无益的。

 

REST架构风格   将服务器抽象为一组离散资源的集合。资源是一个抽象的概念，而不是表明某个具体的东西。注意：要真正理解REST，就必定要加强本身的抽象思惟能力，充分理解到资源是抽象的。资源是名词性的，所以REST建模是以名词为中心的。

 

     上述是目前基于网络的应用的主要的三种抽象方式。这三种不一样的抽象方式会严重影响客户端与服务器的交互模式，而不一样交互模式的交互效率差异至关大。分布式对象的交互模式不少时候效率很低，由于掩盖了分布式对象与本地对象的差异，不少时候都会致使细粒度的API。实践已经证实，与RPC和分布式对象相比，REST是一种对于服务器更加有效的抽象方式，将会带来粒度更大和更有效率的交互模式。这样的效果与Fielding设计REST的初衷是吻合的，REST就是专门为交互的性能和可伸缩性进行过优化的一种架构风格。而SOAP在设计的时候优先考虑的历来不是性能和可伸缩性，而是互操做性，其开发效率比较低。

      REST的主要优点其实在于它是一种对于服务器的更加有效的抽象方式。

     性能分析：与基于二进制通讯的RPC例如RMI对比，REST是基于文本传输的，从这点看应该说性能不如前者，可是REST强调通讯语义对于中间组件的可见性，这样能够改善性能和可伸缩性。例如浏览器就是一种中间件。浏览器能够根据通讯的语义来肯定数据有没有发生改变，从而进行有效的缓存。RMI传输数据再有效，它的数据也没法作有效的缓存。所以RMI的性能未必比REST好，何况不能缓存会带来严重的可伸缩性问题。