理解本真的REST架构风格（转，解释的最清楚）
add by zhj start:
Fielding在批判性继承前⼈研究成果的基础上，建⽴起来⼀整套研究和评价软件架构的⽅法论。这套⽅法论的核⼼是“架构风格”这个概念。架构风格是⼀种研究和评价软件架构设计的⽅法，它是⽐架构更加抽象的概念。⼀种架构风格是由⼀组相互协作的架构约束来定义的。
REST架构风格最重要的架构约束有6个：
客户-服务器（Client-Server）
通信只能由客户端单⽅⾯发起，表现为请求-响应的形式。
⽆状态（Stateless）
通信的会话状态（Session State）应该全部由客户端负责维护。
缓存（Cache）
响应内容可以在通信链的某处被缓存，以改善⽹络效率。
统⼀接⼝（Uniform Interface）
通信链的组件之间通过统⼀的接⼝相互通信，以提⾼交互的可见性。为了使⽤统⼀接⼝，REST⼜使⽤了⼀些约束：⾯向资源，资源有标识符URI，资源表述，⼀组受限且定义良好的资源操作等。
(1)⾯向资源的。从资源的⾓度思考，Web经常被称作是“⾯向资源的”，资源可以是抽象的；
(2)资源标识符。要使⽤⼀个资源，我们需要能够在⽹络上标识它，这就是URI，Uniform Resource Identifier统⼀资源标识符。URI在HTTP 中对应于URL，资源与资源标识符是⼀对多关系
(3)资源表述。即资源的表现⽅式，也称为资源视图，如XML, JSON, HTML, MP3, JPEG等，资源与其表述是⼀对多关系。在HTTP中通过HTTP header Accept, Content-Type指定
(4)资源的操作⽅法。uniform interface，统⼀接⼝包含⼀组受限的定义良好的操作，由它们进⾏资源的访问和操作，统⼀接⼝独⽴于资源的URI。在HTTP协议中即为GET/PUT/POST等method，
这些动词都有⼀定的含义，不应该乱⽤，具体定义见。另外还包括HTTP定义的响应状态集合，如200 OK, 201 Created等，客户端通过HTTP method，对服务器端资源进⾏操作，实现"表现层状态转化"。
REST（Reprentational State Transfer，表述性状态转移）是指：相互链接的资源通过交换代表资源状态的表述来进⾏通信。超链接说⽩了就是URI--统⼀资源标识符
分层系统（Layered System）
通过限制组件的⾏为（即，每个组件只能“看到”与其交互的紧邻层），将架构分解为若⼲等级的层。
按需代码（Code-On-Demand，可选）
⽀持通过下载并执⾏⼀些代码（例如Java Applet、Flash或JavaScript），对客户端的功能进⾏扩展。
最后说⼀下HTTP，及HTTP与REST的关系。HTTP即HyperText Transfer Protocol，翻译成“超⽂本转移协议”更准确。REST是⽤来指导HTTP/1.1协议设计的理论框架（也称为架构风格），后来Roy Fielding对这套理论框架进⾏了更为系统、严谨地阐述。
对于使⽤HTTP的⼈员来说，统⼀接⼝应该是我们理解和实践REST的关键，其它约束其实不必太关⼼
add by zhj end
本⽂是系列深度内容中的第⼆篇，它将带您领略REST架构的起源、与Web的关系、REST架构的本质及特性，以及REST架构与其他架构风格之间的⽐较。
引⼦
在移动互联⽹、云计算迅猛发展的今天，作为⼀名Web开发者，如果您还没听说过“REST”这个buzzword，显然已经落伍了。夸张点说，甚⾄“出了门都不好意思跟别⼈打招呼”。尽管如此，对于REST这个泊来品的理解，⼤多数⼈（包括⼀些资深的架构师）仍然停留在“盲⼈摸象”的阶段。常常听到各种各样关于REST的说法，例如：有⼈说：“我们这套新的API决定不⽤Web Service（SOAP+WSDL），⽽是直接使⽤HTTP+JSON，也就是⽤RESTful的⽅式来开发。” 不⽤SOAP，甚⾄也不⽤XML，就⾃动变成了RESTful了。还有⼈认为：REST与传统的Web Service其实没有本质区别，只是对于URI的构造⽅式提出了更多要求，⽽这些要求Web Service完全都可以实现。潜台词是：既⽣瑜，何⽣亮。Web Service已经⾜够好了，⼲嘛还要再折腾什么REST。这些对于REST的不同说法，果真如此吗？REST究竟是什么？是⼀种新的技术、⼀种新的架构、还是⼀种新的规范？
对于这些问题笔者先不解答，为了深⼊理解REST是什么，我们需要回顾⼀下Web发展的最初年代，从源头上讲讲REST是怎么得来的。
Web技术发展与REST的由来
Web（万维⽹World Wide Web的简称）是个包罗万象的万花筒，不同的⼈从不同的⾓度观察，对于Web究竟是什么会得出⼤不相同的观点。作为Web开发者，我们需要从技术上来理解Web。从技术架构层⾯上看，Web的技术架构包括了四个基⽯：URI
HTTP
HyperText（除了HTML外，也可以是带有超链接的XML或JSON）
MIME
这四个基⽯相互⽀撑，促使Web这座宏伟的⼤厦以⼏何级数的速度发展了起来。在这四个基⽯之上，Web开发技术的发展可以粗略划分成以下⼏个阶段：
1. 静态内容阶段：在这个最初的阶段，使⽤Web的主要是⼀些研究机构。Web由⼤量的静态HTML⽂档组成，其中⼤多是⼀些学术论
⽂。Web服务器可以被看作是⽀持超⽂本的共享⽂件服务器。
2. CGI程序阶段：在这个阶段，Web服务器增加了⼀些编程API。通过这些API编写的应⽤程序，可以向客户端提供⼀些动态变化的内
容。Web服务器与应⽤程序之间的通信，通过CGI（Common Gateway Interface）协议完成，应⽤程序被称作CGI程序。
3. 脚本语⾔阶段：在这个阶段，服务器端出现了ASP、PHP、JSP、ColdFusion等⽀持ssion的脚本语⾔技术，浏览器端出现了Java
Applet、JavaScript等技术。使⽤这些技术，可以提供更加丰富的动态内容。
4. 瘦客户端应⽤阶段：在这个阶段，在服务器端出现了独⽴于Web服务器的应⽤服务器。同时出现了Web MVC开发模式，各种Web
MVC开发框架逐渐流⾏，并且占据了统治地位。基于这些框架开发的Web应⽤，通常都是瘦客户端应⽤，因为它们是在服务器端⽣成全部的动态内容。
5. RIA应⽤阶段：在这个阶段，出现了多种RIA（Rich Internet Application）技术，⼤幅改善了Web应⽤的⽤户体验。应⽤最为⼴泛的
RIA技术是DHTML+Ajax。Ajax技术⽀持在不刷新页⾯的情况下动态更新页⾯中的局部内容。同时诞⽣了⼤量的Web前端DHTML开发库，例如Prototype、Dojo、ExtJS、jQuery/jQuery UI等等，很多开发库都⽀持单页⾯应⽤（Single Page Application）的开发。其他的RIA技术还有Adobe公司的Flex、微软公司的Silverlight、Sun公司的JavaFX（现在为Oracle公司所有）等等。
6. 移动Web应⽤阶段：在这个阶段，出现了⼤量⾯向移动设备的Web应⽤开发技术。除了Android、i
OS、Windows Phone等操作系统平
台原⽣的开发技术之外，基于HTML5的开发技术也变得⾮常流⾏。
从上述Web开发技术的发展过程看，Web从最初其设计者所构思的主要⽀持静态⽂档的阶段，逐渐变得越来越动态化。Web应⽤的交互模式，变得越来越复杂：从静态⽂档发展到以内容为主的门户⽹站、电⼦商务⽹站、搜索引擎、社交⽹站，再到以娱乐为主的⼤型多⼈在线游戏、⼿机游戏。
在互联⽹⾏业，实践总是⾛在理论的前⾯。Web发展到了1995年，在CGI、ASP等技术出现之后，沿⽤了多年、主要⾯向静态⽂档的HTTP/1.0协议已经⽆法满⾜Web应⽤的开发需求，因此需要设计新版本的HTTP协议。在HTTP/1.0协议专家组之中，有⼀位年轻⼈脱颖⽽出，显⽰出了不凡的洞察⼒，后来他成为了HTTP/1.1协议专家组的负责⼈。这位年轻⼈就是Apache HTTP服务器的核⼼开发者Roy Fielding，他还是Apache软件基⾦会的合作创始⼈。
Roy Fielding和他的同事们在HTTP/1.1协议的设计⼯作中，对于Web之所以取得巨⼤成功，在技术架构⽅⾯的因素做了⼀番深⼊的总结。Fielding将这些总结纳⼊到了⼀套理论框架之中，然后使⽤这套理论框架中的指导原则，来指导HTTP/1.1协议的设计⽅向。HTTP/1.1协议的第⼀个草稿是在1996年1⽉发布的，经过了三年多时间的修订，于1999年6⽉成为了IETF的正式规范（包括了RFC 2616以及⽤于对客户端做⾝份认证的RFC 2617）。HTTP/1.1协议设计的极为成功，以⾄于发布之后整整10年时间
⾥，都没有多少⼈认为有修订的必要。⽤来指导HTTP/1.1协议设计的这套理论框架，最初是以备忘录的形式在专家组成员之间交流，除了IETF/W3C的专家圈⼦，并没有在外界⼴泛流传。Fielding在完成HTTP/1.1协议的设计⼯作之后，回到了加州⼤学欧⽂分校继续攻读⾃⼰的博⼠学位。第⼆年（2000年）在他的博⼠学位论⽂Architectural Styles and the Design of Network-bad Software Architectures中，Fielding更为系统、严谨地阐述了这套理论框架，并且使⽤这套理论框架推导出了⼀种新的架构风格，并且为这种架构风格取了⼀个令⼈轻松愉快的名字“REST”——Reprentational State Transfer（表述性状态转移）的缩写。
在笔者看来，Fielding这篇博⼠论⽂在Web发展史上的价值，不亚于Web之⽗Tim Berners-Lee关于超⽂本的那篇经典论⽂。然⽽遗憾的是，这篇博⼠论⽂在诞⽣之后的将近5年时间⾥，⼀直没有得到⾜够的重视。例如Web Service相关规范SOAP/WSDL的设计者们，显然不⼤理解REST是什么，HTTP/1.1究竟是⼀个什么样的协议、为何要设计成这个样⼦。
这种情况在2005年之后有了很⼤的改善，随着Ajax、Ruby on Rails等新的Web开发技术的兴起，在Web开发技术社区掀起了⼀场重归Web 架构设计本源的运动，REST架构风格得到了越来越多的关注。在2007年1⽉，⽀持REST开发的Ruby on Rails 1.2版正式发布，并且将⽀持REST开发作为Rails未来发展中的优先内容。Ruby on Rails的创始⼈DHH做了⼀个名为“World of Resources”的精彩演讲，DHH在Web开发技术社区中的强⼤影响⼒，使得REST⼀下⼦处在Web开发技术舞台的聚光灯之
下。
今天，各种流⾏的Web开发框架，⼏乎没有不⽀持REST开发的了。⼤多数Web开发者都是通过阅读某种REST开发框架的⽂档，以及通过⼀些例⼦代码来学习REST开发的。然⽽，通过例⼦代码来学习REST有⾮常⼤的局限性。因为REST并不是⼀种具体的技术，也不是⼀种具体的规范，REST其实是⼀种内涵⾮常丰富的架构风格。通过例⼦代码来学习REST，除了学习到⼀种有趣的Web开发技术之外，并不能全⾯深⼊的理解REST究竟是什么。甚⾄还会误以为这些简单的例⼦代码就是REST本⾝，REST不过是⼀种简单的Web开发技术⽽已。就像盲⼈摸象⼀样，有的⼈摸到了象⿐⼦、有的⼈摸到了象⽿朵、有的⼈摸到了象腿、有的⼈摸到了象尾巴。他们都坚信⾃⼰感觉到的⼤象，才是最真实的⼤象，⽽其他⼈的感觉都是错误的。
对于不理解REST的Web开发者，⼈们习惯于展⽰⼀些例⼦代码来让他们理解REST，笔者不赞同上述做法。如果Web开发者想要深⼊理解REST是什么，就很难避开Fielding的这篇博⼠论⽂。笔者在本⽂中对于REST是什么的介绍，也是基于Fielding的博⼠论⽂的。尽管如此，笔者强烈建议本⽂的读者亲⾃去通读⼀下Fielding的博⼠论⽂，就像想要了解孔⼦的思想应该直接去读《论语》等著作，⽽不是⾸先去读其他⼈的转述⼀样。笔者在本⽂中也仅仅是努⼒不做⼀个把经书念错了的歪嘴和尚⽽已。那么，下⾯我们⾔归正传。
在Fielding的这篇名为Architectural Styles and the Design of Network-bad Software Architectures的博⼠论⽂（中⽂版名为《架构风格与基于⽹络的软件架构设计》）中，提出了⼀整套基于⽹络的软件（即所谓的“分布式应⽤”）的设计⽅法，值得所有分布式应⽤的开发者仔细阅读、深⼊体会。
在论⽂的前三章中，Fielding在批判性继承前⼈研究成果的基础上，建⽴起来⼀整套研究和评价软件架构的⽅法论。这套⽅法论的核⼼是“架构风格”这个概念。架构风格是⼀种研究和评价软件架构设计的⽅法，它是⽐架构更加抽象的概念。⼀种架构风格是由⼀组相互协作的架构约束来定义的。架构约束是指软件的运⾏环境施加在架构设计之上的约束。
在论⽂的第四章中，Fielding研究了Web这样⼀个分布式系统对于软件架构设计提出了哪些需求。在第五章中，Fielding将第四章Web提出的需求具体化为⼀些架构约束，通过逐步添加各种架构约束，推导出来了REST这种新的架构风格。
REST架构风格的推导过程如下图所⽰：
图1：REST所继承的架构风格约束（）
在图1中，每⼀个椭圆形⾥⾯的缩写词代表了⼀种架构风格，⽽每⼀个箭头边的单词代表了⼀种架构约束。
因人而异是什么意思
REST架构风格最重要的架构约束有6个：
客户-服务器（Client-Server）
通信只能由客户端单⽅⾯发起，表现为请求-响应的形式。
⽆状态（Stateless）
通信的会话状态（Session State）应该全部由客户端负责维护。
缓存（Cache）
响应内容可以在通信链的某处被缓存，以改善⽹络效率。
统⼀接⼝（Uniform Interface）
通信链的组件之间通过统⼀的接⼝相互通信，以提⾼交互的可见性。
分层系统（Layered System）
通过限制组件的⾏为（即，每个组件只能“看到”与其交互的紧邻层），将架构分解为若⼲等级的层。
按需代码（Code-On-Demand，可选）
⽀持通过下载并执⾏⼀些代码（例如Java Applet、Flash或JavaScript），对客户端的功能进⾏扩展。
adsl拨号在论⽂中推导出的REST架构风格如下图所⽰：
图2：REST架构风格（）
⽽HTTP/1.1协议作为⼀种REST架构风格的架构实例，其架构如下图所⽰：
图3：⼀个基于REST的架构的过程视图（）乘坐电梯安全须知
⽤户代理处在三个并⾏交互（a、b和c）的中间。⽤户代理的客户端连接器缓存⽆法满⾜请求，因此它根据每个资源标识符的属性和客户端连接器的配置，将每个请求路由到资源的来源。请求（a）被发送到⼀个本地代理，代理随后访问⼀个通过DNS查找发现的缓存⽹关，该⽹关将这个请求转发到⼀个能够满⾜该请求的来源服务器，服务器的内部资源由⼀个封装过的对象请求代理（object request broker）架构来定义。请求（b）直接发送到⼀个来源服务器，它能够通过⾃⼰的缓存来满⾜这个请求。请求（c）被发送到⼀个代理，它能够直接访问WAIS（⼀种与Web架构分离的信息服务），并将WAIS的响应翻译为⼀种通⽤的连接器接⼝能够识别的格式。每⼀个组件只知道与它们⾃⼰的客户端或服务器连接器的交互；整个过程拓扑是我们的视图的产物。
通过⽐较图2和图3，读者不难发现这两张图中的架构是⾼度⼀致的。对于HTTP/1.1协议为何要设计成这个样⼦，读者想必已经有所领悟。
在论⽂的第六章中，Fielding对于到2000年为⽌在Web基础架构协议的设计和开发⽅⾯的⼀些经验教训进⾏了深⼊的分析。其中，“HTTP不是RPC”、“HTTP不是⼀种传输协议”两部分值得读者反复阅读。时⾄13年之后的今⽇，对于HTTP协议的误解仍然⼴泛存在。
以上简要介绍了Fielding博⼠论⽂中的内容。为了帮助读者仔细阅读Fielding的博⼠论⽂，笔者整理了⼀套Fielding博⼠论⽂的导读，将在后续⽂章中载出。
REST详解
REST究竟是什么？因为REST的内涵⾮常丰富，所以很难⽤⼀两句话解释清楚这个问题。
⾸先，REST是Web⾃⾝的架构风格。REST也是Web之所以取得成功的技术架构⽅⾯因素的总结。REST是世界上最成功的分布式应⽤架构风格（成功案例：Web，还不够吗？）。它是为运⾏在互联⽹环境的分布式超媒体系统量⾝定制的。互联⽹环境与企业内⽹环境有⾮常⼤的差别，最主要的差别是两个⽅⾯：说服英文
可伸缩性需求⽆法控制：并发访问量可能会暴涨，也可能会暴跌。
属鸡的哪年出生
安全性需求⽆法控制：⽆法控制客户端发来的请求的格式，很可能会是恶意的请求。
⽽所谓的“超媒体系统”，即，使⽤了超⽂本的系统。可以把“超媒体”理解为超⽂本+媒体内容。
REST是HTTP/1.1协议等Web规范的设计指导原则，HTTP/1.1协议正是为实现REST风格的架构⽽设计的。新的Web规范，其设计必须符合REST的要求，否则整个Web的体系架构会因为引⼊严重⽭盾⽽崩溃。这句话不是危⾔耸听，做个类⽐，假如苏州市政府同意在市区著名园林的附近⼤型⼟⽊，建造⼤量具有后现代风格的摩天⼤楼，那么不久之后世界闻名的苏州园林美景将不复存在。
上述这些关于“REST是什么”的描述，可以总结为⼀句话：REST是所有Web应⽤都应该遵守的架构设计指导原则。当然，REST并不是法律，违反了REST的指导原则，仍然能够实现应⽤的功能。但是违反了REST的指导原则，会付出很多代价，特别是对于⼤流量的⽹站⽽⾔。
要深⼊理解REST，需要理解REST的五个关键词：
1. 资源（Resource）
2. 资源的表述（Reprentation）
3. 状态转移（State Transfer）
4. 统⼀接⼝（Uniform Interface）
5. 超⽂本驱动（Hypertext Driven）
什么是资源？
资源是⼀种看待服务器的⽅式，即，将服务器看作是由很多离散的资源组成。每个资源是服务器上⼀个可命名的抽象概念。因为资源是⼀个抽象的概念，所以它不仅仅能代表服务器⽂件系统中的⼀个⽂件、数据库中的⼀张表等等具体的东西，可以将资源设计的要多抽象有多抽象，只要想象⼒允许⽽且客户端应⽤开发者能够理解。与⾯向对象设计类似，资源是以名词为核⼼来组织的，⾸先关注的是名词。⼀个资源可以由⼀个或多个URI来标识。URI既是资源的名称，也是资源在Web上的地址。对某个资源感兴趣的客户端应⽤，可以通过资源的URI与其进⾏交互。
什么是资源的表述？
资源的表述是⼀段对于资源在某个特定时刻的状态的描述。可以在客户端-服务器端之间转移（交换）。资源的表述可以有多种格式，例如HTML/XML/JSON/纯⽂本/图⽚/视频/⾳频等等。资源的表述格式可以通过协商机制来确定。请求-响应⽅向的表述通常使⽤不同的格式。
什么是状态转移？
状态转移（state transfer）与状态机中的状态迁移（state transition）的含义是不同的。状态转移说的是：在客户端和服务器端之间转移（transfer）代表资源状态的表述。通过转移和操作资源的表述，来间接实现操作资源的⽬的。
什么是统⼀接⼝？
REST要求，必须通过统⼀的接⼝来对资源执⾏各种操作。对于每个资源只能执⾏⼀组有限的操作。以HTTP/1.1协议为例，HTTP/1.1协议定义了⼀个操作资源的统⼀接⼝，主要包括以下内容：
7个HTTP⽅法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS
HTTP头信息（可⾃定义）
HTTP响应状态代码（可⾃定义）
⼀套标准的内容协商机制
⼀套标准的缓存机制
⼀套标准的客户端⾝份认证机制
REST还要求，对于资源执⾏的操作，其操作语义必须由HTTP消息体之前的部分完全表达，不能将操作语义封装在HTTP消息体内部。这样做是为了提⾼交互的可见性，以便于通信链的中间组件实现缓存、安全审计等等功能。
什么是超⽂本驱动？
“超⽂本驱动”⼜名“将超媒体作为应⽤状态的引擎”（Hypermedia As The Engine Of Application State，来⾃Fielding博⼠论⽂中的⼀句话，缩写为HATEOAS）。将Web应⽤看作是⼀个由很多状态（应⽤状态）组成的有限状态机。资源之间通过超链接相互关联，超链接既代表资源之间的关系，也代表可执⾏的状态迁移。在超媒体之中不仅仅包含数据，还包含了状态迁移的语义。以超媒体作为引擎，驱动Web应⽤的状
态迁移。通过超媒体暴露出服务器所提供的资源，服务器提供了哪些资源是在运⾏时通过解析超媒体发现的，⽽不是事先定义的。从⾯向服务的⾓度看，超媒体定义了服务器所提供服务的协议。客户端应该依赖的是超媒体的状态迁移语义，⽽不应该对于是否存在某个URI或URI 的某种特殊构造⽅式作出假设。⼀切都有可能变化，只有超媒体的状态迁移语义能够长期保持稳定。
⼀旦读者理解了上述REST的五个关键词，就很容易理解REST风格的架构所具有的6个的主要特征：
⾯向资源（Resource Oriented）
薏米粥的做法可寻址（Addressability）
连通性（Connectedness）
⽆状态（Statelessness）
统⼀接⼝（Uniform Interface）
超⽂本驱动（Hypertext Driven）
这6个特征是REST架构设计优秀程度的判断标准。其中，⾯向资源是REST最明显的特征，即，REST架构设计是以资源抽象为核⼼展开的。可寻址说的是：每⼀个资源在Web之上都有⾃⼰的地址。连通性说的是：应该尽量避免设计孤⽴的资源，除了设计资源本⾝，还需要设计资源之间的关联关系，并且通过超链接将资源关联起来。⽆状态、统⼀接⼝是REST的两种架构约束，超⽂本驱动是REST的⼀个关键词，在前⾯都已经解释过，就不再赘述了。
从架构风格的抽象⾼度来看，常见的分布式应⽤架构风格有三种：
分布式对象（Distributed Objects，简称DO）
架构实例有CORBA/RMI/EJB/DCOM/ Remoting等等
短裤的英语
远程过程调⽤（Remote Procedure Call，简称RPC）
架构实例有SOAP/XML-RPC/Hessian/Flash AMF/DWR等等
表述性状态转移（Reprentational State Transfer，简称REST）
架构实例有HTTP/WebDAV
DO和RPC这两种架构风格在企业应⽤中⾮常普遍，⽽REST则是Web应⽤的架构风格，它们之间有⾮常⼤的差别。
REST与DO的差别在于：
REST⽀持抽象（即建模）的⼯具是资源，DO⽀持抽象的⼯具是对象。在不同的编程语⾔中，对象的定义有很⼤差别，所以DO风格的架构通常都是与某种编程语⾔绑定的。跨语⾔交互即使能实现，实现起来也会⾮常复杂。⽽REST中的资源，则完全中⽴于开发平台和编程语⾔，可以使⽤任何编程语⾔来实现。
DO中没有统⼀接⼝的概念。不同的API，接⼝设计风格可以完全不同。DO也不⽀持操作语义对于中间组件的可见性。
DO中没有使⽤超⽂本，响应的内容中只包含对象本⾝。REST使⽤了超⽂本，可以实现更⼤粒度的交互，交互的效率⽐DO更⾼。
REST⽀持数据流和管道，DO不⽀持数据流和管道。
DO风格通常会带来客户端与服务器端的紧耦合。在三种架构风格之中，DO风格的耦合度是最⼤的，⽽REST的风格耦合度是最⼩的。
REST松耦合的源泉来⾃于统⼀接⼝+超⽂本驱动。
REST与RPC的差别在于：
REST⽀持抽象的⼯具是资源，RPC⽀持抽象的⼯具是过程。REST风格的架构建模是以名词为核⼼的，RPC风格的架构建模是以动词为核⼼的。简单类⽐⼀下，REST是⾯向对象编程，RPC则是⾯向过程编程。
RPC中没有统⼀接⼝的概念。不同的API，接⼝设计风格可以完全不同。RPC也不⽀持操作语义对于中间组件的可见性。
RPC中没有使⽤超⽂本，响应的内容中只包含消息本⾝。REST使⽤了超⽂本，可以实现更⼤粒度的交互，交互的效率⽐RPC更⾼。
REST⽀持数据流和管道，RPC不⽀持数据流和管道。
因为使⽤了平台中⽴的消息，RPC风格的耦合度⽐DO风格要⼩⼀些，但是RPC风格也常常会带来客户端与服务器端的紧耦合。⽀持统⼀接⼝+超⽂本驱动的REST风格，可以达到最⼩的耦合度。江苏公务员考试时间
⽐较了三种架构风格之间的差别之后，从⾯向实⽤的⾓度来看，REST架构风格可以为Web开发者带来三⽅⾯的利益：
简单性
采⽤REST架构风格，对于开发、测试、运维⼈员来说，都会更简单。可以充分利⽤⼤量HTTP服务器端和客户端开发库、Web功能测试/性能测试⼯具、HTTP缓存、HTTP代理服务器、防⽕墙。这些开发库和基础设施早已成为了⽇常⽤品，不需要什么⽕箭科技（例如神奇昂贵的应⽤服务器、中间件）就能解决⼤多数可伸缩性⽅⾯的问题。
