所有的美好和罪恶开始于分布式系统架构的研究，因为我们发现在分布式系统中，面向对象让很多事情变得捉襟见肘，这可能是还没有真正诞生一个好的面向对象的分布式架构体系。在2001年微软推出.NET之后，开始鼓吹基于SOAP的Web Service，整个业界似乎也一下子都在讨论Web Service。不过在一开始，这些概念都没有转化成为具有实际意义的应用。后来，真正把这种概念推向顶峰的原因是IBM和BEA对SOA的炒作。对于现在每个热衷于SOA的人来说，都必须承认一个历史问题，那就是SOA并不是什么非常高深或具有难度的东西，这数年来，它更多的是一个被炒作太多的概念。

是的，经历过EJB2那种惨痛的教训之后，使用SOAP为数据交换标准的Web Service确实简化了不少东西。至少大部分时候其跨平台和通过RPC进行远程调用的便利性已经足够应付应用开发的需要。不去讨论Web Service究竟有哪些利弊，实际上利弊都很明显。REST也是一种分布式系统架构设计的思路，不过它有一些独具特色，很好玩的地方。

REST与HTTP协议密不可分。CRUD的基本操作都是充分利用了HTTP协议的动词，所以对于RESTful Web Service而言，暴露的不是方法，而是资源。所有的资源通过一组精心设计的URL来组织。最典型的例子其实就是Amazon S3。对比一下使用SOAP的Web Service就可以发现，最大的区别就在于SOAP并不依赖于HTTP协议，但REST通过充分利用HTTP协议使得解藕变得更加容易。因为很明显，公开的是资源，而再也不需要公开方法名。这给了使用Web Service的客户端更大的自由。

REST的简单也同样是它的一个软肋，因为在构建一套应用的时候，会发现通过面向对象去设计和通过面向资源去设计是非常不同的设计思路。对于一些复杂的应用需求，使用面向资源的概念仍然没有太多成熟的设计案例，但这并不代表今后的情况也会是这样。事实上使REST成为标准一点都不难，因为它本身已经足够简单，再配合上一些设计的常规指导，没有人会觉得有必要再去实现一个SOAP的接口。很明显的事实是，基于SOAP的Web Service目前也没有什么更大的作为，所有这些Web Service几乎都可以使用REST去做。

所以从比较广泛的范围来看，如果我们仍会大量的使用Web Service来构建分布式系统，那么REST很有可能做成SOAP做了快七年都没有做成的事情。但并不是所有Web应用程序都会使用这种设计思路，比如Internet Banking，Google地图等许多应用也并不是REST的。但它们一样很好用，也具有很好的伸缩性。REST并不是什么绝对好的方式，也只是设计思路中的一种。从一个具体的应用着手，会发现仍然有许多技术细节值得去探究，这也许该另起一篇。