REST技术详解

REST和SOAP的“风格”
比较REST和SOAP的“风格”
架构风格：来自Roy Thomas Fielding博士的定义：一种架构风格是一组协作的架构约束，这些约束限制了架构元素的角色和功能，以及在任何一个遵循该风格的架构中允许存在的元素之间的关系。

SOAP：简单对象访问协议，基于XML，是一种应用协议，可以跨多种传输协议来传递消息（比如HTTP、SMTP），Soap是针对RPC的解决方案。

其初衷是作为一种轻量级解决方案出现的，采用xml格式定义过程调用和返回，一个Soap 消息就是一个特定格式和内容的XML文档。

Restful web service：Rest 是针对Web提出的一种架构风格，Restful web service本质上就是Web，任意一个URL地址，一个HTTP网页都可以称作是Restful web service。

Rest把网络上的所有事物抽象为资源，把对资源的操作抽象为CRUD，对应HTTP的PUT，Get，Post，Delete。

注意此处的资源不是静态的数据，而是数据加上状态，是随时间变化的，每个资源有一个唯一的标识，URL。

Rest提出了一些设计概念和准则：
1、网络上的所有事物都被抽象为资源（resource）；
2、每个资源有一个唯一的资源标识（resource identifier）；
3、通过通用的连接器接口（generic connector interface）对资源进行操作；
4、对资源的各种操作不会改变资源标识；
5、所有的操作都是无状态的（stateless）。

REST依赖一套简单的“动词”，把所有的复杂性都转移到了指定资源的“名词”中。

与此不同，SOAP却有一套相当复杂的XML格式化命令和数据传输选项。

在Web服务发展的初期，XML格式化消息的第一个主要用途是，应用于XML-RPC协议，其中RPC代表远程过程调用。

在XML远程过程调用(XML-RPC)中，客户端发送一条特定消息，该消息中必须包括名称、运行服务的程序以及输入参数。

相反， REST风格的请求却不关心正在运行的程序是什么，它仅仅请求命名资源。

XML-RPC只能使用有限的数据类型种类和一些简单的数据结构。

人们认为这个协议还不够强大，于是就出现了SOAP——其最初的定义是简单对象访问协议。

之后，大家逐渐意识到SOAP其实并不简单，而且也不需要必须使用面向对象语言，所以，现在人们只是沿用SOAP这个名称而已。

XML-RPC只有简单的数据类型集，取而代之，SOAP是通过利用XML Schema 的不断发展来定义数据类型的。

同时，SOAP也能够利用XML 命名空间，这是XML-RPC所不需要的。

如此一来，SOAP消息的开头部分就可以是任何类型的XML 命名空间声明，其代价是在系统之间增加了更多的复杂性和不兼容性。

另外，非常重要一点是，REST是需要请求HTTP的，与其相比，SOAP更具优势，SOAP消息可以由所有能够处理Unicode文本的传输方式来传送，很可惜，这一点通常不被人们所认可。

事实是，由于HTTP穿透防火墙的便捷性，以及开发商们对Web非常熟悉，因此，人们还在继续强调着 HTTP传输。

随着计算机行业的觉醒，人们发现了基于XML的Web服务的商业潜力，于是，各家公司开始不断地发掘想法、观点、论据以及标准化尝试。

W3C 曾经设法以“Web服务活动”的名义来组织成果展，其中也包括实际做出SOAP的XML协议工作组(XML Protocol Working Group)。

与Web服务有关的标准化成果——从某种程度上说与SOAP相关或者依赖于SOAP——的数量已经倍增了到了令人惊讶的程度。

最初，SOAP是作为XML-RPC的扩展而发展起来的，它主要强调的是，通过从WSDL文件中所获得的方法和变量名来进行远程过程调用。

现在，通过不断进步，人们发现了更多的使用SOAP的方式，而不仅仅是采用“文件”方式——基本上是使用一个SOAP信封来传送XML格式化文件。

无论如何，要掌握SOAP，了解WSDL所扮演的角色是最根本的。

通过http请求的Accept Header字段来表示。

针对SOAP Web服务的WSDL1.1仅支持HTTP POST方法。

WSDL2.0通过包括对http get绑定的支持对此进行了补充。

另请注意，HTTP delete、put、trace和options方法是用并不频繁，而且经常被防火墙阻止。

Soap与Rest区别：
1．Soap也可以看作是一种风格，面对的应用需求是RPC，而Rest面对的应用需求是分布式超媒体系统（Web）。

2．Rest架构风格更强调数据，请求和响应消息都是数据的封装。

而Soap 风格更强调接口，Soap消息封装的是过程调用。

REST是面向资源的，
而Soap是面向接口的。

3．REST架构下，HTTP是承载协议，也是应用协议，而Soap架构下，HTTP只是承载协议，Soap才是应用协议。

Soap与REST的应用场合：
1．过程调用用soap。

如果服务是作为一种功能提供，客户端调用服务是为了执行一个功能，用Soap，比如常见的认证授权。

而数据服务用REST。

2．可以定义清晰明了的正式接口的情况下，用Soap，比如在企业应用中，系统间的耦合采用面向接口的方式。

3．要更多的考虑非功能需求，比如安全、传输、协作等需求，使用Soap。

4．低带宽，客户端的处理能力受限的场合，比如在PDA，手机上消费服务，用REST。

REST与SOAP之比较——REST篇
REST能够在计算机领域被广泛采用，它走的道路是不同寻常的。

这个术语是由Roy Fielding创造的。

在Web方面，我们必须承认Fielding是非常精通的，他曾经帮助创建HTTP 1.0规范，该规范从1996年开始就为Web提供基本准则。

我有这样一个推断，在计算机世界中，但凡那些让开发人员记住的重要概念，都有一个很酷的名称首字母缩写，否则的话，开发人员很快就会将其抛之脑后。

比如Ajax、SOAP以及REST就证明了这一点。

REST能够在计算机领域被广泛采用，它走的道路是不同寻常的。

这个术语是由Roy Fielding创造的。

Fielding毕业于Irvine市加利福尼亚大学，在他的博士学位论文中第一次提出了REST这个概念。

在Web方面，我们必须承认Fielding是非常精通的，他曾经帮助创建HTTP 1.0规范，该规范从1996年开始就为Web提供基本准则。

他在Web标准方面非常有经验，这为他的这篇博士论文奠定了坚实的基础。

Fielding指出，使用且符合代表性状态传输(REST)设计约束的 Web 上部署的组件，可以充分利用 Web 的有用特性，万维网(World Wide Web)才能够达到最佳的工作效果。

可以这样理解REST——当一个浏览器得到并且显示构成HTML 页面的各个元素时，它正在获取资源的当前状态的表现形式。

在Fielding的博士论文中，他列举了REST风格的设计约束，并且解释了为什么这些约束能够充
分利用Web 的有用特性，使其达到最佳状态，以及这些约束的关键所在。

同时，在论文中，他也包含了一些关于REST和某些目前的Web风格之间“不符合”的讨论，以及这些Web风格是如何导致设计无法利用Web特性的。

Fielding认为，对于使用HTTP承载应用程序协议穿越防火墙，XML-RPC 和SOAP所采用的方式是“从根本上被误导的概念。

”它们所采用的方式违背了设立防火墙的概念，结果是，防火墙厂商为了保护系统需要侦察出所承载的协议。

由于大多数SOAP应用程序使用HTTP都是为了穿越防火墙，因此，你可以发现REST与SOAP之间的冲突是从哪里开始的。

Fielding认为，如果你打算使用HTTP 的话，就应该与充分利用HTTP本身的含义。

REST风格强调，通过有限的操作或者是“动词”以及一个组件之间的标准接口，也就是HTTP协议提供的借口，来提升客户与服务之间的交互。

通过为每一个资源分配其自己的URL，来实现灵活性，REST可以调用包含上百个URI的资源类型的客户，其中的关键是REST能够给你无限多的“名词”。

REST使用HTTP 的动词——简单的良定义操作集:POST, GET, PUT,DELETE进行请求和响应，从而避免了歧义。

举个例子，GET只能够简单地返回资源的表现形式，而不能够创建任何其他的内容。

在Web发展的初期，由于人们都在试验通过收集各种不同来源的元素，从而把Web应用程序融合在一起，有大量这种Web服务的不成熟探索的例子——从HTTP页面中解析信息，用于页面创建者没有计划到的用途。

这种“屏幕抓取”的Web类比表明，REST风格的方法是先于那些更加复杂的Web服务而出现的。

REST是一种风格而不是一个标准
你可能会把软件的架构风格当作对上层设计模式的抽象。

然而，根据Fielding所说，设计模式的堆砌并不等同于架构风格，因为模式是非常接近于特定问题的。

由于REST是超文本系统的一种风格，而不是Web服务的，因此，本文的标题“REST与SOAP之比较”就有些让人误解。

然而，很多软件设计人员会将其混淆，他们在考虑如何创建Web服务时，会得出这样的结论：SOAP过于复杂，而简单的类似于REST的设计却更加适合。

REST与RPC风格之比较
远程过程调用的架构，是应用在基于XML-RPC或者 RPC风格的SOAP的Web 服务中的，它却有着完全不同的风格。

客户端发出命令，以使服务做出特定的操作。

换句话说，RPC有动词的倾向。

REST强调资源(名词)有统一的接口以此来对它们寻址，而RPC强调过程(动词)有统一的接口来激发它们。

一个基于RPC的架构，动词数量是没有限制的。

REST说，我们使用四个动词——非常熟悉，HTTP标准的GET、POST、PUT以及DELETE——来进行请求和响应，REST使用资源寻址来处理其可变性。

一个简单的REST举例
假设我们希望一个Web服务暴露一部分目录，从这个目录中，用户将能够得到一些描述、图片、安装指令等等。

为了得到数字“n1996-01”的描述，用户需要格式化一个GET请求，类似于下面的这个URL：
/catalog/description/n1996-01
在处理这个请求时，“/catalog”将映射到一个服务中，之后，通过该服务对“description/n1996-01”进行解释，从而定位资源。

在创建响应时，服务需要使用内容类型(Content-Type)的头文件来指定返回格式。

在这种情况下，假定返回格式是HTML或者XML，客户端能够使用它来控制页面的布局。

如果要得到图片，那么这个请求将对“/catalog/picture/n1996-01”进行寻址，返回的响应将是图片内容类型(Content-Type)。

REST的商业应用
最近几年，大多数Web商业企业开始对REST非常感兴趣。

Google Data API(目前还在测试版本)专门使用REST规则来提供简单的协议。

对服务的HTTP GET请求的响应结果是，采用Atom或者是RSS联合格式的XML数据。

Google也使用Atom 以及POST、PUT和DELETE操作来完成公共协议。

eBay服务提供通过使用不同语言工具来访问服务，这些工具包括文档/文字风格的SOAP以及REST风格。

那么，对于XML-RPC和SOAP所具有的RPC风格而言，REST风格是否是一个具有竞争力的替代者呢?当然，我决不这样认为，在下一篇文章中，我将尽量向大家展现SOAP所向无敌的领域。

如今，Web开发者的可选技术相当之多；从简化的数据库访问技术，到易用的中间件服务包装技术，以及各种有趣的客户端软件等等，一应俱全。

所有这些产品和工具，都是为了帮助Web开发者用最快的速度开发出最好的Web应用。

然而，拥有大量可选软件方案以及为Web应用的特定部分选用特定方案，都是具有挑战的事；而且，现在Web开发者必须持续跟踪各种不断变化着的标准与方法。

举个例子，Web服务技术就有SOAP（Simple Object Access Protocol，简单对象访问协议）和REST（Representational State Transfer，表示性状态转移）这两种方案。

它们都是有效的方案，但在具体场合下采用哪种方案好，这要取决于Web开发者。

目前，大部分Web开发者似乎都了解REST——一种采用标准URI进行调用的方案。

REST很容易理解，而且只要是支持HTTP/HTTPS的客户端/服务器就支持它。

你可以用HTTP GET方法来执行命令。

所以，开发者们感受到的REST的优势是：开发简单、只需依托现有Web基础设施、以及学习成本低。

然而，SOAP作为一种古老的Web服务技术，短期内还不会退出历史舞台。

而且，随着SOAP 1.2的出现，SOAP印象中的一些缺点已得到改进，采纳率和易用程度也都得到提高。

另需注意的是，从W3C SOAP 1.2版开始，SOAP这一缩写不再代表Simple Object Access Protocol（简单对象访问协议），而是仅仅作为协议名称而已。

相对REST而言，SOAP 1.2多出一些开销，不过这些开销也带来了一些好处。

首先，SOAP在三个方面离不开XML（Extensible Markup Language，可扩展标记语言）：SOAP信封（envelope）是基于XML的，它定义了消息里有什么以及如何处理它；一套用于数据类型的编码规则；过程调用和响应的规划。

SOAP信封由传输协议（HTTP/HTTPS）发出，RPC（Remote Procedure Call，远程过程调用）得到执行，然后一个XML文档随SOAP信封返回。

需要注意的是，基于“通用”传输协议是SOAP的一个优点。

REST目前基于HTTP/HTTPS；而SOAP可支持任何传输协议，从HTTP /HTTPS到SMTP（Simple Mail Transfer Protocol，简单邮件传送协议），甚至JMS（Java Messaging Service，Java消息传递服务）。

不过，由于XML较为冗长且解析费时，因此采用XML也成为一个弊端。

不过，对Web开发者来说的好消息是，目前上述两种方案都是行之有效的方案。

REST和SOAP都能解决许多Web方面的问题与挑战，而且在许多情况下，它们各自都能满足开发者的要求，也就是说可互换使用。

但很多人不知道，这两种技术可以混合搭配使用。

REST很好理解，且极易上手；不过由于它缺乏标准，因此只被看作是一种架构方法。

与之相比，SOAP是一个工业标准，它具备良好定义的协议，以及一套良好确立的规则，在大型和小型系统中均有采用。

因此，REST的适用场合包括：
∙有限的带宽和资源别忘了返回的结构可以采用（由开发者定义的）任何格式。

另外，由于REST采用标准的GET、PUT、POST和DELETE动词，因此可被任何浏览器
所支持。

除此以外，REST还可以使用为目前大多数浏览器支持的XMLHttpRequest
对象，这为AJAX增色不少。

∙完全无状态的操作对于那些需多步执行的操作，REST并非最佳选择，采用SOAP 更合适。

但是，如果你需要无状态的CRUD（Create/Read/Update/Delete，创建/读取/更新/删除）操作，那么应采用REST。

∙缓存考虑若要利用无状态操作的特性，使得信息可被缓存，那么REST是很好的选择。

以上已经覆盖很多方案了，那么，为什么还要考虑SOAP呢？正如前述，SOAP比较成熟而且是经过良好定义的，具有完整的规范。

而REST只不过是一种方法，对开发未作任何规约；因此，假如你遇到以下场合，那么SOAP是最佳选择：
∙异步处理与调用如果你的应用需要确保可靠性与安全性，那么请采用SOAP。

SOAP
1.2为确保这种操作补充定义了WSRM（WS-Reliable Messaging）等标准。

∙形式化契约若提供者/消费者双方必须就交换格式取得一致，那么采用SOAP更合适。

SOAP 1.2为这种交互提供了严格的规范。

∙有状态的操作如果应用需要上下文信息与对话状态管理，那么应采用SOAP。

SOAP
1.2为此补充定义了WS-Security、WS-Transactions和WS-Coordination等标准。

相
比之下，REST方法要求开发者自己来实现这些框架性工作。

正如你所看到的，REST和SOAP各自有其用武之地。

它们在安全性和传输层等方面有着自己的潜在问题，不过它们都能完成任务，而且在许多情况下，它们都丰富了Web的技术手段。

因此，就这一论题，其实最好的原则就是灵活性原则；因为至少在现今的Web开发中，无论面对何种问题，Web开发者们总有办法运用好这两种技术中的一种。

关于作者
Mike Rozlog是Embarcadero科技公司的高级产品主管。

他的主要工作是确保Embarcadero公司推出开发工具满足全世界开发者们的期望。

他的大部分时间被致力于从技术和业务两个方面来介绍讲解Embarcadero的产品与服务，其听众是遍布全球分析师及其他听众。

Mike曾工作于 CodeGear，一个于2008年被Embarcadero收购的开发工具团队。

之前，他为Borland公司工作了八年，担任过包括首席技术架构师在内的许多职位。

作为一名知名作者，Mike出版了很多书。

他最近的作品《Mastering JBuilder》已由John Wiley & Sons出版。

REST与SOAP之比较——SOAP篇
作者: William Brogden, 出处:TechTarget,责任编辑: 叶江,
2006-12-29 10:00
本文的标题“REST与SOAP之比较”确实有些让人误解。

REST
是代表性状态传输的名称首字母缩写，与其说它是标准，不如说是
一种风格。

然而，在我的前一篇文章中，正如我们所讨论的，众多从
事Web服务的软件设计师们认为SOAP过度复杂，于是，类似eBay
和Google的服务都采用了REST风格的约束来暴露其大量数据。

本文的标题“REST 与SOAP之比较”确实有些让人误解。

REST是代表性状态传输的名称首字母缩写，与其说它是标准，不如说是一种风格。

然而，在我的前一篇文章中，正如我们所讨论的，众多从事Web服务的软件设计师们认为SOAP 过度复杂，于是，类似eBay和Google的服务都采用了REST风格的约束来暴露其大量数据。

查看第一部分
比较REST和SOAP的“风格”
REST依赖一套简单的“动词”，把所有的复杂性都转移到了指定资源的“名词”中。

与此不同，SOAP却有一套相当复杂的XML格式化命令和数据传输选项。

在Web服务发展的初期，XML格式化消息的第一个主要用途是，应用于XML-RPC协议，其中RPC代表远程过程调用。

在XML远程过程调用 (XML-RPC)中，客户端发送一条特定消息，该消息中必须包括名称、运行服务的程序以及输入参数。

相反， REST风格的请求却不关心正在运行的程序是什么，它仅仅请求命名资源。

XML-RPC只能使用有限的数据类型种类和一些简单的数据结构。

人们认为这个协议还不够强大，于是就出现了SOAP——其最初的定义是简单对象访问协议。

之后，大家逐渐意识到SOAP其实并不简单，而且也不需要必须使用面向对象语言，所以，现在人们只是沿用SOAP这个名称而已。

XML-RPC只有简单的数据类型集，取而代之，SOAP是通过利用XML Schema 的不断发展来定义数据类型的。

同时，SOAP也能够利用XML 命名空间，这是XML-RPC所不需要的。

如此一来，SOAP消息的开头部分就可以是任何类型的XML 命名空间声明，其代价是在系统之间增加了更多的复杂性和不兼容性。

另外，非常重要一点是，REST是需要请求HTTP的，与其相比，SOAP更具优势，SOAP消息可以由所有能够处理Unicode文本的传输方式来传送，很可惜，这一点通常不被人们所认可。

事实是，由于HTTP穿透防火墙的便捷性，以及开发商们对Web非常熟悉，因此，人们还在继续强调着 HTTP传输。

随着计算机行业的觉醒，人们发现了基于XML的Web服务的商业潜力，于是，各家公司开始不断地发掘想法、观点、论据以及标准化尝试。

W3C曾经设法以“Web服务活动”的名义来组织成果展，其中也包括实际做出SOAP的XML协议工作组(XML Protocol Working Group)。

与Web服务有关的标准化成果——从某种程度上说与SOAP相关或者依赖于SOAP——的数量已经倍增了到了令人惊讶的程度。

最初，SOAP是作为XML-RPC的扩展而发展起来的，它主要强调的是，通过从WSDL文件中所获得的方法和变量名来进行远程过程调用。

现在，通过不断进步，人们发现了更多的使用SOAP的方式，而不仅仅是采用“文件”方式——基本上是使用一个SOAP信封来传送XML格式化文件。

无论如何，要掌握SOAP，了解WSDL所扮演的角色是最根本的。

Web服务描述语言或WSDL
为了创建一个用于描述Web服务的XML格式化文件，Web服务描述语言(WSDL)标准提供了足够多的细节，以便能够构建出客户端代码，从而访问服务或者服务器端代码以提供服务。

一个服务的WSDL文件将会为你提供以下几个方面的内容：
∙用于访问服务的地址信息
∙用于传送信息的传输协议(例如，通道数)
∙用于所有可使用功能的名称和接口使用方法
∙在所有的请求和响应中所使用的数据类型
2001年3月，W3C推出了WSDL 1.1版本用于讨论，这并不是最终确定的规范。

W3C Web服务描述工作组目前正在开发该规范的2.0版本，基本上已经到了尾声。

虽然，WSDL通常是用于特定的SOAP服务，但是，从理论说，它是完全可以用于特定的REST风格的GET或者POST操作的。

能够根据服务的WSDL描述来自动创建客户端和服务器端代码，支持这一功能的开发环境目前使用得很广泛，以便能够适用于Web服务器和Web服务客户端的不同程序设计语言。

如果你使用Google搜索“SOAP IDE”的话，大概会出现上百万条相关信息。

也有这样的工具，根据Java或C#对象来生成相应的WSDL 和代码。

自动生成代码也许能够使你的开发效率更高，但是离优化却是越来越远。

安全与SOAP
如果企业使用SOAP来传送有价值的信息的话，那么，安全就是最重要的问题。

由OASIS组织发起，计算机行业的领导者们已经联合开发了一套标准，称为WS-Security。

这个标准对基本的SOAP通信做出了改善，以便能够处理以下几个问题：
消息机密性——由于拦截HTTP消息的方式非常多，因此，在请求和响应过程中，必须能够对所有重要信息加密。

很幸运，现在的加密技术非常先进，我们能够对消息内容进行加密，以保证消息不被修改。

客户和服务身份——必须能够核实SOAP请求来源的身份。

结论
在开发人员的意识里，对于Web服务的开发而言，REST和SOAP风格各有千秋。

SOAP拥有更为详尽的标准化成果和开源工具。

除此之外，现在，有许多集成开发环境能够在现有代码的基础上，依据接口方法自动生成SOAP。

如果你需要使用WSDL来发布你的服务，或者你需要一些安全功能如消息签名和加密，那么，SOAP能够确保消息的安全性。

另一方面，如果你希望使用简单接口来公布一些信息，而不需要繁琐的处理过程，那么，REST也许是最佳选择。

REST(Representational State Transfer)是HTTP协议的作者Roy Fielding 博士在其博士论文中提出的一种互联网应用构架风格。

与以远程对象为核心的ORB和以服务为核心的SOA相比，以资源为核心的REST让我们从崭新的视角审视互联网应用。

REST为互联网应用量身定做的简洁模型、与HTTP协议的完美结合、构架的高扩展性，为互联网应用构架设计和异构系统集成设计带来了一股清新的空气。

语言生态环境
计算机发展至今，产生了许许多多不同的语言，每种语言都定义了自己独特的生态环境。

在这个生态环境内的程序共享相同的类型系统、运行时环境、并发模型等。

虽然所有程序的本质是相同的：从问题领域到机器领域的映射，但无法回避的是不同生态环境的程序很难跨越彼此的边界。

同样是int，在A和B语言通常截然不同（CLR和JVM能部分解决类型共享问题），更不用说A语言具有但B语言不具有的某些语言特性(CLR和JVM没法解决)。

当系统可以在单一的生态环境中自给自足时，跨越生态环境的问题并不存在；但在多数互联网应用中，系统的各个部分通常既是生产者又是消费者，必须要打破生态环境的界限才能相互协作。

比如，A公司的Service A，需要对外提供服务，而Service A又依赖于B公司的Service B和C公司的Service C；由于无法保证不同公司都采用同样的语言，因此各服务的接口必须保证语言无关性。

在我所了解的范围内，有3种跨域生态环境的方式：
1.
ORB(Object Request Broker)
以CORBA为代表，其核心概念是远程对象（remote object）。

熟悉.Net Remoting 的朋友应该能体会其风格（需要说明的是.Net Remoting只跨越微软的生态环境）。

不同生态环境的程序可以像调用本地对象一样调用远程对象代理的方法，ORB会负责连接到远程的对象，并处理数据的序列化与反序列化。

2.
SOA
其核心概念是服务(Service)。

比如：我们要提供整数加法Web服务，我们会很自然地想到通过类似下面的url来表达服务接口：
/add?a=1&b=2
并通过xml结构表达结果：
3.
REST
其核心概念是资源(Resource)。

在REST的世界中，没有服务的概念，同样是上面的例子，在REST的世界中，/add?a=1&b=2是一个xml 网页资源的id，而非服务的接口。

所以，REST让我们从资源的角度来审视互联网应用并指导我们的设计，这是它与ORB和SOA最本质的区别。

下面我们将更详细的介绍，REST以资源为核心的模型和相应的设计风格。

状态表述转移
在REST的世界中，资源即状态，而互联网就是一个巨大的状态机：每个网页是其一个状态；url是状态的表述；REST风格的应用则是从一个状态迁移到下一个状态的状态转移过程。

早期互联网只有静态页面的时候，通过超链接在静态网页间浏览跳转的page->link->page->link…模式就是一种典型的状态转移过程。

无状态服务器
REST风格应用可以实现交互，但它却天然地具有服务器无状态的特征。

在状态迁移的过程中，服务器不需要记录任何Session，所有的状态都通过url的形式记录在了客户端。

PS:更准确地说，这里的无状态服务器，是指服务器不保存会话状态(Session)；而资源本身则是天然的状态，通常是需要被保存的；本文提到的无状态服务器均指无会话状态服务器。

举个例子：一个心理测试的应用，需要用户做2次选择题，每次可选A、B两种答案，2次选择完毕之后将告知用户属于何种心理类型。

如果按ORB或SOA的服务思维，很容易想到在服务器端保存Session，每次选择以后修改Session，根据Session产生结果。

但如果以REST的状态表述转移模型为指导，我们会自然地得出这样设计：。