REST 与 CRUD 数据服务无关。是的，您可以使用 REST 来执行类似 CRUD 的服务，但这就像说正则表达式用于解析电子邮件地址一样。
Here http://www.slideshare.net/trilancer/restful-user-experience-1421793这是迄今为止我所见过的有关 REST 与 SOAP/RPC 辩论的最佳演示。
REST 更注重解决分布式客户端/服务器交互，而不是处理服务器到服务器交互。 REST 是将内容呈现在用户面前，以便他们可以选择如何处理它。 REST 并不是要创建基于 Http 的数据访问层来将应用程序逻辑与其数据存储分离。
Atom Pub 是一个很好的 REST 实现。 Netflix API 是最好的商业 REST API 之一。 Twitter API 不符合大多数 RESTful 约束。
如果您想了解有关 REST 的准确信息，请访问以下位置：
- http://roy.gbiv.com/untangled/ http://roy.gbiv.com/untangled/
- http://tech.groups.yahoo.com/group/rest-discuss/ http://tech.groups.yahoo.com/group/rest-discuss/
- http://www.innoq.com/blog/st/ http://www.innoq.com/blog/st/
- http://www.infoq.com/ http://www.infoq.com/
不要听大供应商在这个问题上的说法，他们更感兴趣的是使他们现有的产品符合流行语。
跟进：
我认为 REST 接口比服务器到服务器交互更适合客户端/服务器交互，有几个原因。这只是我的观点，我并不是想声称除了我之外的任何人都持有这种观点！
多对一的比例
当您支持许多客户端访问单个服务器时，缓存和无状态服务器的好处变得更加明显。服务器与服务器之间的通信通常是 1-1 的，很少有大量服务器与单个服务器进行通信。
松耦合
REST 就是松散耦合。这个想法是您可以继续发展服务器而无需更新客户端。如果您正在考虑在服务器 A 上实现 REST 服务，而该服务将由位于同一房间的服务器 B 调用，那么松散耦合的好处就会减弱。在两台机器上更新一个软件不会让你丧命。
超媒体
超媒体约束是根据当前应用程序状态为用户提供选择。 REST 接口支持对超链接系统的临时探索。服务器与服务器之间的通信往往侧重于实现特定任务。例如处理这批数据。根据时间表触发这些事件。本质上，没有用户坐在那里决定要遵循哪条路径。该路径已根据参数和条件预先确定。
表现
在服务器到服务器通信场景中，实现最大吞吐量可能至关重要。二进制协议可能比 Http 更合适。在服务器到服务器类型的通信中，延迟可能很关键。在一端由人类驱动的客户端-服务器环境中，性能要求有很大不同，我相信 REST 约束更适合这种类型的交互。
互操作性
REST 建议使用标准媒体类型作为 HTTP 负载。这鼓励偶然地重用所提供的服务。我认为，与针对其他服务器的服务相比，重用供客户端应用程序使用的服务的机会要多得多。
在设计 REST 接口时，我喜欢认为服务的使用者是一个受最终用户直接控制的软件。 Web 浏览器被称为用户代理并非巧合。
