webservice restful rpc

webservice:

上世纪90年代流行的分布式技术，如DCOM,CORBA,RMI，范式是RPC，但各系统数据类型不一致，实现/调用机制不一样，各系统间互通不可能。XML的出现，让数据类型一致了，SOAP的出现，让各系统能够相互调用了。Simple Object Access Protocol的原意是XML-RPC，但人们很快就发现方法调用太狭隘，而消息传递更加通用。WSDL即支持rpc/encoded也支持document/literal，但前者已成为历史遗留。 webservices是soa的道成肉身，rpc方式的webservices是历史遗留。 rest是roa的道成肉身。（这方面我不熟悉） RMI CORBA DCOM XML-rpc soap wsdl 微软的DCOM，sun的RMI、JMS，和OMG的CORBA RMI：Romote Method  Invocation，远程方法调用。基于java远程消息交换协议JRMP通讯；JRMP是专为java远程对象制定的协议。是分布式应用程序的100%java解决方法。RMI对非java语言应用程序支持不足，不能实现互通。 RMI是面向对象的编程模型。普遍应用与EJB架构系统中。 RMI基于调用的模式，调用过程以下：客户端程序调用服务对象的客户端代理，代理负责打包参数并经过JRMP协议发送到服务端，服务端使用一样协议解析，执行业务逻辑处理，用一样方法返回结果给客户端。 RPC：RPC算是这几类的统称（这样说有点不许确，但也能够这么理解）。  RPC（Remote Procedure Call）远程过程调用，是实现分布式计算的一种技术。在某种传输协议（TCP\HTTP等)上携带信息数据，经过网络从远程计算机程序上请求服务。在OSI模型中，RPC跨越了传输层和应用层，使开发网络分布式应用程序变得容易。客户端代码像调用本地方法同样调用远程方法。 RPC基于请求应答模式，客户端发送调用信息（将远程方法名、参数打包进请求信息）到服务端，服务端解析到要调用的对象和方法执行后返回应答信息；客户端接受相应获取应答信息。         RPC是跨语言的通讯标准，sun和微软都有其实现,微软的DCOM就是创建在ORPC协议之上。 RPC是面向过程的编程模型。 XML-RPC:XML Remote Procedure Call，即XML远程方法调用,利用http+xml封装进行RPC调用。基于http协议传输、XML做为信息编码格式。一个xml-rpc消息就是一个请求体为xml的http-post请求，服务端执行后也以xml格式编码返回。这个标准面前已经演变为下面的SOAP协议。能够理解SOAP是XML-RPC的高级版本。 SOAP:Simple Object Access Protocol ,简单对象访问协议，是一种轻量的、简单的、基于xml的远程访问协议。能够与现有的多种传输层或应用层协议结合使用，如TCP、HTTP、SMTP等。SOAP普遍使用的是基于HTTP和xml协议的实现（SOAP=RPC+HTTP+XML），也就是你们常提的Web Service使用的通讯协议。一个SOAP方法能够简单地看做遵循SOAP编码规则的HTTP请求和响应。 比较：XML－RPC是启动web服务最容易的方法，在不少方面比SOAP更简单易用，但不一样于SOAP的是，XML－RPC没有相应的服务描述语法，这妨碍了XML－RPC服务的自动调用。 JSON-RPC:JSON Remote Procedure Call，即JSON远程方法调用 。相似于XML-RPC，不一样之处是使用JSON做为信息交换格式。 REST: Some ‘RESTful’ APIs are really just RPC over HTTP The REST architecture reuses the world wide web infrustructure where possible XML JSON: JavaScript Object Notation Ajax: HTTP:GET, POST, PUT, DELETE URL: XML-RPC: XML Remote Procedure Call 这种远程过程调用使用http做为传输协议，XML做为传送信息的编码格式。Xml-Rpc的定义尽量的保持了简单，但同时可以传送、处理、返回复杂的数据结构。 XML-RPC是工做在Internet上的远程过程调用协议。一个XML-RPC消息就是一个请求体为xml的http-post请求，被调用的方法在服务器端执行并将执行结果以xml格式编码后返回。 在RMI和RPC之间最主要的区别在于方法是如何被调用的。在RMI中，远程接口使每一个远程方法都具备方法签名。若是一个方法在服务器上执行，可是没有相匹配的签名被添加到这个远程接口上，那么这个新方法就不能被RMI客户方所调用。 简单描述: rpcclient的工做原理:rpcclient根据URL找到rpcserver -> 构造命令包，调用rpcserver上的某个服务的某个方法 -> 接收到rpcserver的返回,解析响应包，拿出调用的返回结果。 rpcserver的工做原理:启动一个webserver(在使用内置的webserver的状况下) -> 注册每一个能提供的服务，每一个服务对应一个Handler类 ->进入服务监听状态。 1. 历史 第一轮：HTTP，带来了Internet与电子商务 第二轮：Java，cross-platform，最先的RMI 第三轮：XML，标准的数据封装技术，各类App之间交换数据再也不是难事。 第四轮：RPC，Webservice、REST、高性能通讯协议 2. What is RPC？ 简单理解: 可互操做的Web服务 RPC（Remote Procedure Call） –    在某种传输协议（TCP\HTTP等)上携带信息数据，经过网络从远程计算机程序上请求服务 –    在OSI模型中，RPC跨越了传输层和应用层 –    基于请求应答模式 –    跨语言的通讯标准 任何一个RPC规范和实现都包含: –    服务层（service）：RPC接口定义与实现 –    协议层（protocol）：RPC报文格式和数据编码格式 –    传输层（transport）：实现底层的通讯（如 socket） 应用程序通讯性能比较：ipc<tcp<http<soap 3. RPC 以XML-RPC为表明介绍 XML-RPC（XML Remote Procedure Call）     – 协议层：XML     – 传输层：HTTP（许多防火墙也配置为只容许HTTP链接） 一个XML-RPC消息就是一个请求体为xml的http-post请求，服务端执行后也以xml格式编码返回。 4. webservice Webservice平台是一套标准，它定义了应用程序如何在Web上实现互操做性。标准包括：     – 描述数据的方法：XML     – 信息交换的协议：SOAP     – 传输协议：HTTP     – Web服务描述语言：WSDL     – 发布注册：UDDI     – 服务具体的实现技术：Java，C，Ptyhon… SOAP介绍 –    能够看作是XML-RPC的高级版本 –    SOAP是一种轻量的、简单的、基于XML的协议，容许应用程序经过HTTP来交换信息。或者更简单地讲，SOAP是用于访问Web服务的协议。 –    一个SOAP请求实际上也是一个http-post请求 更多了解参考"Webservice/SOAP/WSDL释疑篇" 5. REST REST介绍 –    具象状态传输（Representational State Transfer） –    业界开放服务新标准 –    面向资源开开发 –    公开目录结构式的 URI（http://twitter.com/statuses/user/zhangxu） –    回归HTTP协议本性（GET、POST、PUT、DELETE） 6. 高性能应用程序通讯协议 传统的RPC     – 无论是json仍是xml传输数据，效率很低 RMI     – 效率高，仅适用于Java 直接socket链接     – 须要开发本身的协议，成本高 所以须要经过二进制HTTP传输的高性能通讯中间件，其中高性能能够理解为： –    对象的序列化、反序列化高性能 –    压缩算法高性能 –    传输高性能 经常使用于企业内部系统间的交互 经常使用技术 –    hessian、thrift、protocol buffer 6.1 Hessian Hessian 是开源的远程通信协议。 Hessian 采用二进制 RPC 协议，基于 HTTP 传输，服务器端不用开放防火墙端口。 Hessian 协议的规范是公开的，能够用于任意语言。 Hessian一般经过Web应用来提供服务，所以很是相似于WebService。它不使用SOAP协议，而且按照二进制传输。 一次调用的流程：     客户端——>序列化写到输出流——>远程方法（服务器端）——>序列化写到输出流 ——>客户端读取输入流——>输出结果 6.2 Thrift 参考文章“跨平台通讯中间件thrift学习【Java版本】” 6.3 protobuf protocol buffer 是 google 的一种数据交换的格式，它独立于语言，独立于平台。google 提供了多种语言的实现：java、c++ 和 python等，每一种实现都包含了相应语言的编译器以及库文件。因为它是一种二进制的格式，比使用 xml 进行数据交换快许多。能够把它用于分布式应用之间的数据通讯或者异构环境下的数据交换。 Protobuf只有一种序列化和反序列化的手段，并不涉及传输层 Protobuf序列化效率业界最高！ 什么是Rest？      rest，即REST(Representational State Transfer 表述性状态转移)是一种针对网络应用的设计和开发方式，能够下降开发的复杂性，提升系统的可伸缩性。      REST特色：      1. Rest是一种设计风格，不是一个标准。      2. Rest一般使用HTTP,URI，XML，HTML等流行的协议和标准      3. Rest是从资源的角度来观察网络的，而资源是由URI来指定的。      4. Rest对资源的操做类型一般包括：获取，建立，删除和修改，这四种操做分别对应着HTTP协议请求的GET,POST,DELETE和PUT方法。      5. 资源的表现形式能够为:XML,HTML,JSON的文本。      6. Rest是服务端-客户端结构中的一种应用方法。      7. Rest使用的是HTTP协议，所以是无状态的。      接下来，咱们来了解下为何要Rest？要弄清楚这个问题首先要了解一下计算机软件之间通信技术的发展历程。在计算机通信中，TCP/IP协议是最为通用的标准协议，TCP是传输控制协议，IP是网际协议，但这两种协议都是很是原始的（RAW）,TCP协议是传输层协议，而IP是网络层协议。经过TCP/IP的确能胜任将信息从一个计算机传递给另一台。但你们都知道比较底层的东西，每每比较难于理解。所以一些应用层协议营运而生，最初的应用层协议有SMTP,POP3,FTP,HTTP等，时至今日，你们天天使用最多的仍然是这些老牌应用协议。但这些协议同时都是有应用条件的。 RMI(remote method invocation，面向对象的远程方法调用) RPC（remote procedure call，远程过程调用） SOAP(simple object access protoal，简单对象访问协议) REST(representational state transfer，表达性状态转移) 以上都理解为调用远程方法的一些通讯技术“风格”。 1.Tcp/Ip （socket，RMI）      早些时候，程序员们为了让两个应用程序之间可以通信，一般采用的是使用Socket的开发的TCP/IP通信程序，而且都是本身定义数据格式规范，这种模式的优势是个性化，一般效率较高，但同时由于都各自为政，每每是开发了好多种程序，但每种都不同，这对于爱偷懒的程序员来说，真是杯具了呀！      RMI就比如它是本地工做，采用tcp/ip协议，客户端直接调用服务端上的一些方法。优势是强类型，编译期可检查错误，缺点是只能基于JAVA语言，客户机与服务器紧耦合。 2.RPC      一些程序员开始想到，若是调用远程的一个方法可以像调用本地方法同样，那就简化多了，因而RPC模式的通信产生了. RPC使用C/S方式，采用http协议，发送请求到服务器，等待服务器返回结果。这个请求包括一个参数集和一个文本集，一般造成“classname.methodname”形式。优势是跨语言跨平台，C端、S端有更大的独立性，缺点是不支持对象，没法在编译器检查错误，只能在运行期检查。 3.SOAP      以后为了标准化，跨平台又产生了基于SOAP协议的消息通信模型。SOAP是在XML-RPC基础上，使用标准的XML描述了RPC的请求信息（URI/类/方法/参数/返回值）。由于XML-RPC只能使用有限的数据类型种类和一些简单的数据结构，SOAP能支持更多的类型和数据结构。优势是跨语言，很是适合异步通讯和针对松耦合的C/S，缺点是必须作不少运行时检查。 4.REST      但随着时间的推移和SOAP的推广状况，你们很快发现，其实世界上已经存在了一个最为开放，最为通用的应用协议，那就是HTTP，使用SOAP的确让进程间通信变得简单易用，但并非每一个厂商都愿意将本身的老系统再升级为支持SOAP，并且SOAP的解析也并非每种语言都内置支持，好比JS.而HTTP正好完美了解决了这个问题，那好吧，咱们就设计一种使用HTTP协议来完成服务端-客户端通信的方法吧，Rest应运而生。      REST通常用来和SOAP作比较，它采用简单的URL方式来代替一个对象，优势是轻量，可读性较好，不须要其余类库支持，缺点是URL可能会很长，不容易解析。 总结来讲，计算机通信的历程能够用下图来阐述： REST与RPC风格之比较      RPC(远程过程调用)的架构，是应用在基于XML-RPC(或者 RPC风格)的SOAP的Web服务中的。客户端发出命令，以使服务作出特定的操做。换句话说，RPC有动词的倾向。      REST强调资源(名词)有统一的接口以此来对它们寻址，而RPC强调过程(动词)有统一的接口来激发它们。一个基于RPC的架构，动词数量是没有限制的。REST说，咱们使用四个动词——很是熟悉，HTTP标准的GET、POST、PUT以及DELETE——来进行请求和响应，REST使用资源寻址来处理其可变性。 REST和SOAP风格之比较      REST风格的Web服务依赖一套简单的“动词”，HTTP标准的GET、POST、PUT以及DELETE，把全部的复杂性都转移到了指定资源的“名词”中。与 REST 架构相比，SOAP 架构图明显不一样的是：全部的 SOAP 消息发送都使用 HTTP POST 方法，而且全部 SOAP 消息的 URI 都是同样的，这是基于 SOAP 的 Web 服务的基本实践特征。      在Web服务发展的初期，XML格式化消息的第一个主要用途是，应用于XML-RPC协议，其中RPC表明远程过程调用。在XML远程过程调用(XML-RPC)中，客户端发送一条特定消息，该消息中必须包括名称、运行服务的程序以及输入参数。相反， REST风格的请求却不关心正在运行的程序是什么，它仅仅请求命名资源。      XML-RPC只能使用有限的数据类型种类和一些简单的数据结构。人们认为这个协议还不够强大，因而就出现了SOAP——其最初的定义是简单对象访问协议。以后，你们逐渐意识到SOAP其实并不简单，并且也不须要必须使用面向对象语言，因此，如今人们只是沿用SOAP这个名称而已。      XML-RPC只有简单的数据类型集，取而代之，SOAP是经过利用XML Schema的不断发展来定义数据类型的。同时，SOAP也可以利用XML 命名空间，这是XML-RPC所不须要的。如此一来，SOAP消息的开头部分就能够是任何类型的XML命名空间声明，其代价是在系统之间增长了更多的复杂性和不兼容性。      另外，很是重要一点是，REST是须要请求HTTP的，与其相比，SOAP更具优点，SOAP消息能够由全部可以处理Unicode文本的传输方式来传送，很惋惜，这一点一般不被人们所承认。事实是，因为HTTP穿透防火墙的便捷性，以及开发商们对Web很是熟悉，所以，人们还在继续强调着HTTP传输。      随着计算机行业的觉醒，人们发现了基于XML的Web服务的商业潜力，因而，各家公司开始不断地发掘想法、观点、论据以及标准化尝试。W3C曾经设法以“Web服务活动”的名义来组织成果展，其中也包括实际作出SOAP的XML协议工做组(XML Protocol Working Group)。与Web服务有关的标准化成果——从某种程度上说与SOAP相关或者依赖于SOAP——的数量已经倍增了到了使人惊讶的程度。 一个简单的REST举例      假设咱们但愿一个Web服务暴露一部分目录，从这个目录中，用户将可以获得一些描述、图片、安装指令等等。为了获得数字“n1996-01”的描述，用户须要格式化一个GET请求，相似于下面的这个URL：      http://company.com/catalog/description/n1996-01      在处理这个请求时，“/catalog”将映射到一个服务中，以后，经过该服务对“description/n1996-01”进行解释，从而定位资源。在建立响应时，服务须要使用内容类型(Content-Type)的头文件来指定返回格式。在这种状况下，假定返回格式是HTML或者XML，客户端可以使用它来控制页面的布局。若是要获得图片，那么这个请求将对“/catalog/picture/n1996-01”进行寻址，返回的响应将是图片内容类型(Content-Type)。 REST风格web service和SOAPweb service的选择 如下从成熟度，效率和易用性，安全性三方面讲如何选择使用这两种风格：      成熟度(总的来讲SOAP在成熟度上优于REST)      SOAP虽然发展到如今已经脱离了初衷，可是对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的状况。不一样平台，开发语言之间经过SOAP来交互的web service都可以较好的互通（在部分复杂和特殊的参数和返回对象解析上，协议没有做很细致的规定，致使仍是须要做部分修正）      REST国外不少大网站都发布了本身的开发API，不少都提供了SOAP和REST两种Web Service，根据调查部分网站的REST风格的使用状况要高于SOAP。可是因为REST只是一种基于Http协议实现资源操做的思想，所以各个网站的REST实现都自有一套，在后面会讲诉各个大网站的REST API的风格。也正是由于这种各自实现的状况，在性能和可用性上会大大高于SOAP发布的web service，但统一通用方面远远不及SOAP。因为这些大网站的SP每每专一于此网站的API开发，所以通用性要求不高。      因为没有相似于SOAP的权威性协议做为规范，REST实现的各类协议仅仅只能算是私有协议，固然须要遵循REST的思想，可是这样细节方面有太多没有约束的地方。REST往后的发展所走向规范也会直接影响到这部分的设计是否可以有很好的生命力。      效率和易用性(REST更胜一筹)      SOAP协议对于消息体和消息头都有定义，同时消息头的可扩展性为各类互联网的标准提供了扩展的基础，WS-*系列就是较为成功的规范。可是也因为SOAP因为各类需求不断扩充其自己协议的内容，致使在SOAP处理方面的性能有所降低。同时在易用性方面以及学习成本上也有所增长。      REST被人们的重视，其实很大一方面也是由于其高效以及简洁易用的特性。这种高效一方面源于其面向资源接口设计以及操做抽象简化了开发者的不良设计，同时也最大限度的利用了Http最初的应用协议设计理念。同时，在我看来REST还有一个很吸引开发者的就是可以很好的融合当前Web2.0的不少前端技术来提升开发效率。例如不少大型网站开放的REST风格的API都会有多种返回形式，除了传统的xml做为数据承载，还有（JSON,RSS,ATOM）等形式，这对不少网站前端开发人员来讲就可以很好的mashup各类资源信息。      安全性：      这点其实能够放入到成熟度中，不过在当前的互联网应用和平台开发设计过程当中，安全已经被提到了很高的高度，特别是做为外部接口给第三方调用，安全性可能会高过业务逻辑自己。      SOAP在安全方面是经过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的，当前已经获得了各个厂商的支持，.net ，php ，java 都已经对其有了很好的支持（虽然在一些细节上仍是有不兼容的问题，可是互通基本上是能够的）。      REST没有任何规范对于安全方面做说明，同时如今开放REST风格API的网站主要分红两种，一种是自定义了安全信息封装在消息中（其实这和SOAP没有什么区别），另一种就是靠硬件SSL来保障,可是这只可以保证点到点的安全，若是是须要多点传输的话SSL就无能为力了。安全这块其实也是一个很大的问题，今年在BEA峰会上看到有演示采用SAML2实现的网站间SSO，实际上是直接采用了XML-Security和XML-Signature，效率看起来也不是很高。将来REST规范化和通用化过程当中的安全是否也会采用这两种规范，是未知的，可是加入的越多，REST失去它高效性的优点越多。      具体选择举例：      在开发人员的意识里，对于Web服务的开发而言，REST和SOAP风格各有千秋。SOAP拥有更为详尽的标准化成果和开源工具。除此以外，如今，有许多集成开发环境可以在现有代码的基础上，依据接口方法自动生成SOAP。若是你须要使用WSDL来发布你的服务，或者你须要一些安全功能如消息签名和加密，那么，SOAP可以确保消息的安全性。另外一方面，若是你但愿使用简单接口来公布一些信息，而不须要繁琐的处理过程，那么，REST也许是最佳选择。      假如咱们要通信的两个应用程序都是同一个架构的，好比都是.Net Application，或者都是Java Application，或者两者是其余对SOAP支持较好的程序，那么建议使用Soap形式来实现通信，但若是服务的客户有使用浏览器调用服务，有使用js调用服务的需求，那么最好服务最好仍是设计成Rest风格的。也就是说现阶段其实Rest的开放性，通用性都要优于SOAP.