REST架构风格的性能为何比其他的架构风格更好

今天与一起翻译Fielding论文的朋友杨光讨论技术问题，杨光认为因为REST是基于文本来进行通信，所以其性能肯定不如基于二进制格式的通信协议 好。因为这是一个对于REST的明显的误解，所以我觉得有必要专门在这里澄清一下。以下是我们的讨论内容，David是我，Allen是杨光。


David: 他们客户端用C#，服务器端用Java，准备用RIA+REST+Java的架构。C#也有类似XMLHttpRequest的对象。
Allen: 为啥是这么怪异的结构，都用.net得了～
David: 那是不可能的，企业应用服务器端主要还是用Java。
Allen: 那就都用java
David: C#与Java通信，主要有两种方式：基于SOAP或者基于HTTP。基于HTTP就是REST了。
David: 如果基于SOAP，肯定会影响开发效率。另外性能也会差很多。
Allen: 无论什么方法，性能都要比单一使用一种平台慢的
David: 不会的，REST只用到了HTTP。
David: 单个平台，客户服务器间走二进制的通信协议，性能也许比REST要好，那就与HTTP无关了。不过这样做不够灵活，客户端与服务器耦合太紧。
Allen: 怎么不会呢？rest也没有直接用servlet快啊。
David: REST当然可以直接用Servlet提供服务
David: 但是你基于Servlet，很多日常事务的处理都要自己做，例如URI到处理器的映射。所以最好是有一个框架帮助你做这些事情。
Allen: 一种是通过xml或者json，一种是直接序列化的参数，性能还是不一样吧
David: REST没有说一定要用XML或者一定要用JSON格式，任何基于文本的格式都是允许的。
Allen: 但是肯定不是序列化的
David: 你说的序列化是什么意思呢？
Allen: 我的意思是C#和java通信，走的肯定是语言外的通道，使用rest也是通过语言外的通道传输数据。如果是一个平台，那么就可以走语言内的通道，这个和rest没关系了。
David: 这只是一种猜测。所谓的语言内的通道，对于Java来说，只有RMI，连SOAP都不算。
Allen: 嗯，我也是空想，实际做出来最有说服力。到时候你可以把资讯的经验和我分享一下。
David: RMI是RPC的风格，中间传输二进制数据，性能应该比HTTP的纯文本稍微高一些，但是这样做有很多的代价。
David: 那篇论文将来我们都需要反复多看几次，实际上REST是权衡很多种架构风格之后的结果，已经能够得到最佳的性能了。
David: 性能不单纯取决于传输数据是二进制还是纯文本。我告诉你为什么。
David: 因为二进制数据的语义对于中间组件是不可见的，它就无法做有效的缓存，当然也无法确定此数据是否会对安全构成威胁。
David: REST强调通信语义对于中间组件的可见性，这样可以改善性能和可伸缩性。
David: 所谓的中间组件，浏览器就是一种。浏览器可以根据通信的语义来确定数据有没有发生改变，从而进行有效的缓存。
David: RMI传输数据再有效，它的数据也无法做有效的缓存。因此RMI的性能未必比REST好，况且不能缓存会带来严重的可伸缩性问题。
David: 这些思想其实在论文中都有很详细的描述，你再看一遍就全明白了。
Allen: 这么说也有道理，等有实现rest的经验后，就一切都明白了