从SOA到RPC、SOAP、REST-copy
从SOA说起
SOA是把项目拆成组件,每个组件暴露出服务,强调的是服务的复用。SOA架构实现不依赖于技术,因此能够被各种不同的技术实现。
例如:SOAP, RPC,REST,DCOM,CORBA,OPC-UA,Web services,DDS,Java RMI,WCF (Microsoft's implementation of web services now forms a part of WCF),Apache Thrift,SORCER
web service是SOA最常用的一种实行方式。
WebService的常用的方法
RPC (远程过程调用协议 )所谓的远程过程调用 (面向方法)
SOAP (简单对象访问协议) 所谓的面向服务的架构(面向消息)
REST (表象化状态转变) 所谓的Representational state transfer (面向资源)
RPC
即远程过程调用(Remote rocedure call), 很简单的概念, 像调用本地服务(方法)一样调用服务器的服务(方法)。 透过向装置了这个协定的服务器发出请求。发出请求的用户端一般都是需要向远端系统要求呼叫的软件。
通常的实现有 XML-RPC , JSON-RPC , 通信方式基本相同, 所不同的只是传输数据的格式.
(如果你已经习惯于XML繁重的尖括号,你不妨可以尝试下更加轻型,高效,传输效率高的 JSON .)
一个简单的通信过程通常为:
Request
<?xml version="1.0"?>
<methodCall>
<methodName>member.get_username_by_id</methodName>
<params>
<param>
<value><i4>1</i4></value>
</param>
</params>
</methodCall>
Response
<?xml version="1.0"?>
<methodResponse>
<params>
<param>
<value><string>Zhu Tao</string></value>
</param>
</params>
</methodResponse>
向服务器发送一个过程调用的方法及其参数, 得到服务器返回的方法执行的结果.
在 XML-RPC 之后又有了更加强大的 SOAP , 用于一些比较复杂的系统之上。
(在新的功能不断被引入下,这个标准慢慢演变成为今日的SOAP协定。XML-RPC协定是已登记的专利项目。)
SOAP
SOAP可以看作是XML-PRC的升级版本,它是一种轻量的、简单的基于XML的协议,允许应用程序通过HTTP或其它传输协议来交换信息,SOAP是用于访问Web Service的协议。
一个SOAP客户端像一个桌面应用程序,它和服务端的是紧耦合的。SOAP客户端和服务端之间维护一个共同的严格的契约。当客户端的调用模型变更时,服务端需要变更契约以适应客户端;当服务端的契约变更时,SOAP客户端也必须手动或自动更新其契约,否则客户端和服务端之间将无法通信。
REST
REST(Representational State Transfer) 是一种软件架构风格,REST指的是一组架构约束条件和原则,
主要有以下特点:
(1)每一个URI代表一种资源;
(2)客户端和服务器之间,传递这种资源的某种表现层;
(3)客户端通过四个HTTP动词,对服务器端资源进行操作,实现"表现层状态转化"。
满足REST约束条件和原则的应用程序或设计就是 RESTful,RESTFul相比REST,多了一个ful,就英语层面来说是一个形容词,restful翻译为中文可以理解为:REST式的。
RESTful 风格几乎是为 HTTP 协议量身定做的,在 HTTP 协议中用 URI 来标识唯一的资源,用 GET、PUT、POST、DELETE 等动词来操作资源,HTTP 协议是无状态协议,可以通过 Cache 来提高性能。
因为"资源"表示一种实体,所以应该是名词,URI不应该有动词,动词应该放在HTTP协议中。
举例来说,某个URI是/posts/show/1,其中show是动词,这个URI就设计错了,正确的写法应该是/posts/1,然后用GET方法表示show。
如果某些动作是HTTP动词表示不了的,你就应该把动作做成一种资源。比如网上汇款,从账户1向账户2汇款500元,错误的URI是:
POST /accounts/1/transfer/500/to/2
正确的写法是把动词transfer改成名词transaction,资源不能是动词,但是可以是一种服务:
POST /transaction
HTTP/1.1
Host: 127.0.0.1
from=1&to=2&amount=500.00
RPC vs REST
RPC是以动词(方法)为中心的, REST是以名词(资源)为中心的。
RPC最大的问题是耦合度高
客户端需要知道服务端的方法名称叫什么
你会发现,以动词为中心,意味着,当你要需要加入新功能时,你必须要添加更多的动词, 这时候服务器端需要实现相应的动词(方法), 客户端需要知道这个新的动词并进行调用。
REST具有更高的扩展性和松耦合性
以名词为中心, 假使我请求的是 www.site.com/books/, 无论这个URI对应的服务怎么变化,客户端是无需关注和更新的,而这种变化对客户端也是透明的.
这种低耦合保证了服务端和客户端的持续演化。
SOAP vs REST
SOAP vs. REST是一个伪命题,对它们进行直接比较并不恰当,因为SOAP(简单对象访问协议)是一种协议,而REST(表述性状态转移)是一种架构风格。
协议和架构是两种完全不同层面的东西,协议是计算机网络中信息交换的规则、标准和约定,其偏向于技术细节和底层;架构则是在系统层面的基准规范、通用性和原则,其偏向于抽象和顶层。一种协议可以用在不同的架构中,在架构的建设过程中也可以使用多种协议。但我还是把它们两者拿出来进行比较,因为它们都可以用于构筑Web Service。Web Service的最大作用在于其互操作性,它独立于平台、语言,可以让不同的应用程序互相调用。
通俗地讲,Web Service扫除了远程对象或方法调用的障碍,它是疏通不同应用程序或服务器之间信息沟通的桥梁。
SOAP
SOAP可以看作是XML-PRC的升级版本,它是一种轻量的、简单的基于XML的协议,允许应用程序通过HTTP或其它传输协议来交换信息,SOAP是用于访问Web Service的协议。
REST
REST是一种价格风格,不是一个标准。REST定义了一组体系架构原则,它借助HTTP的标准方法(POST,GET,PUT,DELETE),实现了对资源的CRUD操作。
SOAP vs REST
一个SOAP客户端像一个桌面应用程序,它和服务端的是紧耦合的。SOAP客户端和服务端之间维护一个共同的严格的契约。当客户端的调用模型变更时,服务端需要变更契约以适应客户端;当服务端的契约变更时,SOAP客户端也必须手动或自动更新其契约,否则客户端和服务端之间将无法通信。
一个REST客户端更像一个浏览器应用程序,它和服务端是松耦合的。
————————————————
版权声明:本文为CSDN博主「田攀」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/pan_tian/article/details/80784839