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

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