从SOA到RPC、SOAP、REST

版权声明:转载请以链接形式注明出处 https://blog.csdn.net/pan_tian/article/details/80784839

从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的常用的方法
  1. RPC (远程过程调用协议 )所谓的远程过程调用 (面向方法)
  2. SOAP (简单对象访问协议) 所谓的面向服务的架构(面向消息)
  3. 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客户端更像一个浏览器应用程序,它和服务端是松耦合的。


猜你喜欢

转载自blog.csdn.net/pan_tian/article/details/80784839