你想要的都在这之RPC/web service/REST/SOA区别联系与对比

关于架构方面有很多名词，有点晕头转向了（集中梳理一下，记录以便查看）：RPC/web service/REST/SOA/SOAP，这篇文章将会做以下几点：

1.归类，从属关系

2.区别与联系

3.应用场景及优缺点

 

-----------------------------------

先对上面的名词做一个概要介绍：

1. RPC ,远程过程调用 (面向方法)，你可以这么理解，就是在另外一台服务器上有一段代码（函数），你可以通过网络远程调用它。用什么协议（http，tcp，udp…），传输什么数据格式（json，xml，二进制…）你都可以自己定义。很简单的概念, 像调用本地服务(方法)一样调用服务器的服务(方法)。
2. SOA ,面向服务的架构(面向消息)，SOA是一种架构方法（SOA不是Web Service，Web Service是目前最适合实现SOA的技术。）
3. REST , Representational state transfer远程过程调用 (面向资源)
4. web service顾名思义这是一种提供service的形式，而且只能通过http（web）来提供service(web service三要素：SOAP、WSDL(WebServicesDescriptionLanguage)、UDDI(UniversalDescriptionDiscovery andIntegration))
5. SOAP,简单对象访问协议,是一种轻量的、简单的、基于XML（标准通用标记语言下的一个子集）的协议，它被设计成在WEB上交换结构化的和固化的信息。
6. SOAP和RPC都是web service的实现方式

RPC与SOA的区别

总的来讲：RPC是一种进程远程调用的方式，更强调的是异构平台之间进程通信的机制。SOA是一种产品架构的理念，以服务为中心，松耦合，通过定义严谨明确的接口进行通信。有比较完善的服务管理机制。

两者并不是一个层面上的概念，可以说RPC是SOA架构的一种实现。

 

RPC与REST的区别

如果你想只记住一点,那么就请记住 RPC是以动词为中心的, REST是以名词为中心的, 此处的 动词指的是一些方法, 名词是指资源.

你会发现,以动词为中心意味着,当你要需要加入新功能时,你必须要添加更多的动词, 这时候服务器端需要实现 相应的动词(方法), 客户端需要知道这个新的动词并进行调用.

而以名词为中心, 假使我请求的是 hostname/friends/, 无论这个URI对应的服务怎么变化,客户端是无需 关注和更新的,而这种变化对客户端也是透明的.

至于其它的区别,如对实现语言的依赖, 耦合性等,这些都是上面提到的这个根本区别所衍生的.

当你每天使用HTTP冲浪时,你都在使用 REST 与远程的服务器进行亲密接触. 当你使用Gtalk和同事朋友沟通时,你则是在享受着 RPC 的便利.

　　场景及选择：

比如公司要做一个社交游戏的项目, 让你去负责整个系统的后端架构和通信等, 我们就有必要去仔细地学习和研究下facebook/人人网/新浪等社交网站（游戏）开放的API, 我们知道facebook使用的是REST 的架构, 所以即使facebook本身是PHP开发的,这也不妨碍我们使用python来开发, 还有更多的PHP, Java, .net, Perl等客户端API封装.这样就能灵活的适配多端的服务了。

于是在想,倘若facebook的架构使用的不是 REST ,会有这样的灵活性吗? 如果使用的是 RPC 可能不会有这么便利。

另外,因为我们的前端使用的是flash, 与后端的python通信采用的是 Django+Flex+AMF , 如果你了解 flash,你会知道AMF是一种二进制的flash数据交互协议, 而 它是基于RPC !

所以，我们需要根据当前需求的情况来选择REST或则RPC

 

 

REST与SOAP的区别

国外很多大网站都发布了自己的开发API，很多都提供了SOAP和REST两种Web Service，根据调查部分网站的REST风格的使用情况要高于SOAP。但是由于REST只是一种基于Http协议实现资源操作的思想，因此各个网站的REST实现都自有一套，在后面会讲诉各个大网站的REST API的风格。也正是因为这种各自实现的情况，在性能和可用性上会大大高于SOAP发布的web service，但统一通用方面远远不及SOAP。由于这些大网站的SP往往专注于此网站的API开发，因此通用性要求不高。 

 

SOAP协议对于消息体和消息头都有定义，同时消息头的可扩展性为各种互联网的标准提供了扩展的基础，WS-*系列就是较为成功的规范。但是也由于SOAP由于各种需求不断扩充其本身协议的内容，导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。 
       REST被人们的重视，其实很大一方面也是因为其高效以及简洁易用的特性。这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，同时也最大限度的利用了Http最初的应用协议设计理念。同时，在我看来REST还有一个很吸引开发者的就是能够很好的融合当前Web2.0的很多前端技术来提高开发效率。例如很多大型网站开放的REST风格的API都会有多种返回形式，除了传统的xml作为数据承载，还有（JSON,RSS,ATOM）等形式，这对很多网站前端开发人员来说就能够很好的mashup各种资源信息。 
       因此在效率和易用性上来说，REST更胜一筹。 

　　REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。 

 

说了这么多，到最后我发现，其实不必要太纠结这些概念，这些概念有些是相互关联的，有些优势包含关系，在实际场景中去使用，去研究。