从SOA说起 SOA是把项目拆成组件，每个组件暴露出服务，强调的是服务的复用。SOA架构实现不依赖于技术，因此能够被各种不同的技术实现。 例如： SOAP, RPC，REST，DCOM，CORBA，OPC-UA，We
从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最大的问题是耦合度高
- 客户端需要知道服务端的方法名称叫什么
- 你会发现,以动词为中心,意味着,当你要需要加入新功能时,你必须要添加更多的动词, 这时候服务器端需要实现相应的动词(方法), 客户端需要知道这个新的动词并进行调用。
这种低耦合保证了服务端和客户端的持续演化。
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客户端更像一个浏览器应用程序，它和服务端是松耦合的。