从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