目前基于网络应用的架构风格主要有三种：
RPC架构风格 将服务器看作是由一些过程组成，客户端调用这些过程来执行特定的任务。SOAP就是RPC风格的一种架构。过程是动词性的（做某件事），因此RPC建模是以动词为中心的。
分布式对象架构风格 认为服务器是由一些对象和对象上的方法组成，客户端通过调用这些对象上的方法来执行特定的任务。并且客户端调用这些对象上的方法应该就像是调用本地对象上的方法一样，这样开发就可以完全按照统一的面向对象方法来做。但是很可惜，这样的抽象并不是很有效，因为分布式对象与本地对象存在着巨大的本质差别，想要掩盖这些差别很多时候甚至是有害无益的。
REST架构风格 将服务器抽象为一组离散资源的集合。资源是一个抽象的概念，而不是代表某个具体的东西。注意：要真正理解REST，就一定要增强自己的抽象思维能力，充分理解到资源是抽象的。资源是名词性的，因此REST建模是以名词为中心的。
上述是目前基于网络的应用的主要的三种抽象方式。这三种不同的抽象方式会严重影响客户端与服务器的交互模式，而不同交互模式的交互效率差别相当大。分布式对象的交互模式很多时候效率很低，因为掩盖了分布式对象与本地对象的差别，很多时候都会导致细粒度的API。实践已经证明，与RPC和分布式对象相比，REST是一种对于服务器更加有效的抽象方式，将会带来粒度更大和更有效率的交互模式。这样的效果与Fielding设计REST的初衷是吻合的，REST就是专门为交互的性能和可伸缩性进行过优化的一种架构风格。而SOAP在设计的时候优先考虑的从来不是性能和可伸缩性，而是互操作性，其开发效率比较低。
REST的主要优势其实在于它是一种对于服务器的更加有效的抽象方式。
性能分析：与基于二进制通信的RPC例如RMI对比，REST是基于文本传输的，从这点看应该说性能不如前者，但是REST强调通信语义对于中间组件的可见性，这样可以改善性能和可伸缩性。例如浏览器就是一种中间件。浏览器可以根据通信的语义来确定数据有没有发生改变，从而进行有效的缓存。RMI传输数据再有效，它的数据也无法做有效的缓存。因此RMI的性能未必比REST好，况且不能缓存会带来严重的可伸缩性问题。