RESTful架构是否适合“需授权访问的数据库型企业应用”？

RESTful架构是否适合“需授权访问的数据库型企业应用”？

 

首先，定义一下“需授权访问的数据库型企业应用”：其实也就是大多数（绝大多数？）j2ee开发人员要面对的那种应用，数据存储是一堆业务表，表的域比较多，表之间有关系；业务逻辑比较多，一部分是简单的增删改查，一部分是由简单增删改查组合而成的复杂操作，进入系统之前必须登录，只有授权的用户才允许进行业务操作（包括查看）。

 

REST、RESTful的资料看了一些，总感觉RESTful并不适合这类应用,主要依据是：

 

1、这类应用session（及背后的cookies）是必须的，服务器端多少会有一些会话State（比如"用户名"），肯定要违背REST服务器Stateless 原则。

 

2、这类应用任何Proxy Cache(及其他服务器之外的Cache)都是不允许的，因为非授权用户不可访问任何信息，因此无法利用REST强调的Cacheable优势。

 

3、这类应用面对的“数据对象”和REST中的“Resource”应该是不同的，后者偏向于表达那种无结构的对象（比例文档，图片，音视频），对其进行的操作绝大多数时候针对对象整体(既操作本身不关系对象内部的数据构成)，因此可以用POST/GET/PUT/DELETE(CURD)等四个基本动词来表达；而前者大多数情况下，是复杂的、结构化的对象，对他们的操作除了整体操作，还有很多针对其局部的操作（既操作涉及对象的内部结构），四个基本动词远不够用，在不扩充动词的情况下，只能让一个动词表达多个操作，这种设计并不符合REST简单优美的声誉。

 

4、这类应用的“数据对象”之间很多时候是相关的，对某个对象的CURD操作经常同时需要对其他对象的CURD操作，如果把这些相关操作（2个以上）放在一个HTTP请求中完成，则使用四个基本动词来表达是语义不确切的；如果把这些相关操作分成多个HTTP请求，则相关操作的Transaction是无法保证的。

 

上面四点中，1、2对REST的违背是很明显的，3、4也很容易看出来，我的问题是，难道RESTful架构并不适用主流的企业应用（非企业“级”应用:-)），而只适用于像Javaeye这样的向公众提供信息服务的“资源型”网站？

 

另外还有几个主题之外的RESTful疑问，一并请教：
a、现在很多论坛有一个功能：必须回复才能看到主帖，但看到和看不到时的访问URI是相同的，这种设计是否违背REST？
b、基本上论坛帖子都有访问次数统计，其实就是GET操作的时候改变了服务器State，应该也是违背REST吧？
c、只使用POST/GET是否也能实现RESTful？我看Fielding的论文中并没有提到必须使用PUT/DELETE。
d、在《RESTful Web Services》的序言中，作者写道：

 

In that first version of HTTP, cleverly disguised as a lack of features, we can see addressability and statelessness: the two basic design decisions that made HTTP an improvement on its rivals, and that keep it scalable up to today’s mega-sites. Many of the features lacking in HTTP 0.9 have since turned out to be unnecessary or counterproductive.Adding them back actually cripples the Web. Most of the rest were implemented in the 1.0 and 1.1 revisions of the protocol.
 
HTTP的第一个版本（指0.9），被聪明地伪装成功能简陋，我们可以看到可寻址性和无状态性，这两个基本的设计策略使得HTTP优于它的竞争对手，并使它在可扩展性方面能够适应今天的百万级站点。HTTP0.9中缺少的很多功能，大多数都在1.0和1.1版本中被实现，后来反而成为不必要的或者反生产力的，加上它们实际削弱了Web。

 
作者的意思是不是：POST/PUT/DELETE等其实都不是RESTful的本质，只有 GET+URI 才是RESTful的核心战斗力？

 

最近为了升级7wxAop框架(自用+开源)的后端基础结构，花了很多时间做技术准备，以上是调查REST时的疑问，请这方面有经验的同学参与讨论解惑。

REST话题没有专版，不知道该发何处，先放在人比较多的JAVA版:-)。

评论

83 楼 leebai 2008-05-26  

<div class='quote_title'>winterwolf 写道</div>
<div class='quote_div'>
<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>
<p><br/><span style='color: #ff0000;'>RESTful</span>这个词不知道是谁造的（源于&lt;&lt;RESTful Web Services&gt;&gt;？），其中反复强调POST/PUT/DELETE/GET四个基本操作，从这一点看，<span style='color: #ff0000;'>其实RESTful是对FieldingREST的歪曲，有“挂羊头卖狗肉”之嫌，P/P/D/G根本就是FieldingREST光辉躯壳下夹藏的私货</span>。 <br/><br/>回到本帖主题，我认为“企业应用”（本帖定义的）需遵从的FieldingREST的唯一约束是：可扩展性所需的“<span style='color: #ff0000;'>服务器无状态性</span>”（也就是你第1点描述的问题），其他约束对“企业应用”都没有意义。至于RESTful，更像一个概念炒作。</p>
</div>
<p> 服务器无状态对开发分布式应用有好处。 </p>
<p>使用put delete也是有重大意义的 。 </p>
<p>隐含在put delete背后的深意是---- 使用文档保存数据（用xml文件）会更高效更适合web  而不是关系数据库</p>
<p>我认为目前native xmldb是建立rest系统的最佳方案</p>
</div>
<p>我不清楚xmldb，不过xml的Path与REST的资源URI路径确实很吻合，对XML数据块常见操作也不复杂，相信特定场合确实管用。</p>
<p>winterwolf兄做的都是些什么样的项目？ 后台数据存储主要用xmldb？</p>

82 楼 winterwolf 2008-05-25  

<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>
<p><br/><span style='color: #ff0000;'>RESTful</span>这个词不知道是谁造的（源于&lt;&lt;RESTful Web Services&gt;&gt;？），其中反复强调POST/PUT/DELETE/GET四个基本操作，从这一点看，<span style='color: #ff0000;'>其实RESTful是对FieldingREST的歪曲，有“挂羊头卖狗肉”之嫌，P/P/D/G根本就是FieldingREST光辉躯壳下夹藏的私货</span>。 <br/><br/>回到本帖主题，我认为“企业应用”（本帖定义的）需遵从的FieldingREST的唯一约束是：可扩展性所需的“<span style='color: #ff0000;'>服务器无状态性</span>”（也就是你第1点描述的问题），其他约束对“企业应用”都没有意义。至于RESTful，更像一个概念炒作。</p>
</div>
<p> 服务器无状态对开发分布式应用有好处。 </p>
<p>使用put delete也是有重大意义的 。 </p>
<p>隐含在put delete背后的深意是---- 使用文档保存数据（用xml文件）会更高效更适合web  而不是关系数据库</p>
<p>我认为目前native xmldb是建立rest系统的最佳方案</p>

81 楼 leebai 2008-05-24  

<div class='quote_title'>winterwolf 写道</div>
<div class='quote_div'>可能非常适合受权访问的数据库性企业应用 <br/><br/>1 权限其实非常适合用rest方式编辑访问. 不用session和cookies是完全可以的。每个用户在服务器上可以有自己的数据空间用来存放信息 权限 文件.....。 访问这个路径下的信息需要通过http的验证 http://user@password:xmlshop.com/winterwolf/权限.xml <br/><br/>2 sql xquery 都可以直接当做资源来调用 post数据返回结果而已. xslt css javascript也可以作为资源来灵活调用。 <br/><br/>3 同意布老大的观点 rest方式非常适合xmldb. sql数据库虽然也通过接口支持rest方式 但是不是自然的 关系数据库本身反rest <br/></div>
<p><br/><br/><br/>最近仔细阅读了dlee同学热心推荐的REST论文，感觉REST真义（下称<span style='color: #ff0000;'>FieldingREST</span>）我是明白了，有个观点一直没敢亮出来，下面晾晾： <br/><br/><span style='color: #ff0000;'>RESTful</span>这个词不知道是谁造的（源于&lt;&lt;RESTful Web Services&gt;&gt;？），其中反复强调POST/PUT/DELETE/GET四个基本操作，从这一点看，<span style='color: #ff0000;'>其实RESTful是对FieldingREST的歪曲，有“挂羊头卖狗肉”之嫌，P/P/D/G根本就是FieldingREST光辉躯壳下夹藏的私货</span>。 <br/><br/>回到本帖主题，我认为“企业应用”（本帖定义的）需遵从的FieldingREST的唯一约束是：可扩展性所需的“<span style='color: #ff0000;'>服务器无状态性</span>”（也就是你第1点描述的问题），其他约束对“企业应用”都没有意义。至于RESTful，更像一个概念炒作。</p>
<p> </p>

80 楼 winterwolf 2008-05-19  

可能非常适合受权访问的数据库性企业应用

1 权限其实非常适合用rest方式编辑访问. 不用session和cookies是完全可以的。每个用户在服务器上可以有自己的数据空间用来存放信息 权限 文件.....。 访问这个路径下的信息需要通过http的验证 http://user@password:xmlshop.com/winterwolf/权限.xml

2 sql xquery 都可以直接当做资源来调用 post数据返回结果而已. xslt css javascript也可以作为资源来灵活调用。

3 同意布老大的观点 rest方式非常适合xmldb. sql数据库虽然也通过接口支持rest方式 但是不是自然的 关系数据库本身反rest 

79 楼 ppig 2008-05-17  

我觉得要看你怎么认识”企业应用“的”资源“了，不同于通常的资源型应用（如javaeye），企业应用的资源应该是流程（那些楼主认为stateful的咚咚）。
应该业是可以作到REST的

78 楼 leebai 2008-05-16  

dlee 写道

hax 写道

不过虽然我赞同transport protocol就是protocol on the transport layer，即点到点的通讯，但是无论如何，传输层协议和传输协议太过混淆。

我建议可考虑 传送 传递 等词。特别是 传递，我觉得比较有中介的概念——比如火炬传递，呵呵。

我也比较倾向于将“transfer”翻译为“传输”之外的某个动词。翻译为“传输”、“超文本传输协议”，我最大的担心就是“传输”这个动词与“传输层”联系过于紧密，存在着误导的可能性，会使得读者将注意力过多地集中于HTTP消息体，而完全忽略了HTTP包头所代表的语义。SOAP在这方面已经犯过一次大错了，其设计者想当然地认为HTTP只是一种能够穿越防火墙的传输协议。Fielding说“HTTP并不是一种传输协议”，很大程度上就是说给SOAP设计者这些曲解HTTP的人听的。《RESTful Web Services中文版》快出来了，在这本书中，大家对SOAP所犯的错误可以看得更清楚。

TCP与HTTP的区别在于：
TCP的使用者并不需要关心TCP包头的语义，TCP包头的语义对使用者来说是完全透明的。使用者需要的仅仅是TCP所提供的透明的点对点传输。
HTTP的使用者需要关心HTTP包头的语义，HTTP包头的语义对于使用者来说并不是透明的。使用者需要的并不仅仅是HTTP所提供的透明的点对点传输。这件事情TCP已经做的非常好了，用HTTP来做这件事情是多余了，而且还增加了HTTP包头额外的负载，从网络效率的角度来看是低效的，不够精益。

我们翻译为“转移”看来还不够好，可以将“转移”改为其他的动词。

单就HTTP来说，使用“传输”之外的词也是可商量的，要考虑的是：

1、中文文档传统习惯问题。如果没有把握扭转所有的应用层“传输协议”的翻译，单改一个HTTP翻译会引起混乱。

2、如何翻译应用层协议RTP(Real-time Transport Protocol)？新的翻译应该做到“自园其说”。

77 楼 dlee 2008-05-13  

hax 写道

不过虽然我赞同transport protocol就是protocol on the transport layer，即点到点的通讯，但是无论如何，传输层协议和传输协议太过混淆。

我建议可考虑 传送 传递 等词。特别是 传递，我觉得比较有中介的概念——比如火炬传递，呵呵。

我也比较倾向于将“transfer”翻译为“传输”之外的某个动词。翻译为“传输”、“超文本传输协议”，我最大的担心就是“传输”这个动词与“传输层”联系过于紧密，存在着误导的可能性，会使得读者将注意力过多地集中于HTTP消息体，而完全忽略了HTTP包头所代表的语义。SOAP在这方面已经犯过一次大错了，其设计者想当然地认为HTTP只是一种能够穿越防火墙的传输协议。Fielding说“HTTP并不是一种传输协议”，很大程度上就是说给SOAP设计者这些曲解HTTP的人听的。《RESTful Web Services中文版》快出来了，在这本书中，大家对SOAP所犯的错误可以看得更清楚。

TCP与HTTP的区别在于：
TCP的使用者并不需要关心TCP包头的语义，TCP包头的语义对使用者来说是完全透明的。使用者需要的仅仅是TCP所提供的透明的点对点传输。
HTTP的使用者需要关心HTTP包头的语义，HTTP包头的语义对于使用者来说并不是透明的。使用者需要的并不仅仅是HTTP所提供的透明的点对点传输。这件事情TCP已经做的非常好了，用HTTP来做这件事情是多余了，而且还增加了HTTP包头额外的负载，从网络效率的角度来看是低效的，不够精益。

我们翻译为“转移”看来还不够好，可以将“转移”改为其他的动词。

76 楼 hax 2008-05-12  

不过虽然我赞同transport protocol就是protocol on the transport layer，即点到点的通讯，但是无论如何，传输层协议和传输协议太过混淆。

我建议可考虑 传送 传递 等词。特别是 传递，我觉得比较有中介的概念——比如火炬传递，呵呵。

75 楼 hax 2008-05-12  

我来说两句。

首先，从google搜索的结果来看，老外对于transfer和transport也分得不是很清楚，比如这里：http://support.microsoft.com/kb/218155。不要怪M$，这样的例子其实还有很多。比如http://www.w3.org/Talks/9608HTTP/sld001.htm，特别注意这个1996年的演讲稿的作者其实也是HTTP协议的作者之一！！

我并不是说transfer/transport就没有语义上的区别，但是至少不是那么显著。个人理解transport偏向运输、运载、交通的含义。而transfer的含义更广泛一些。

其次，来看transport protocol，wikipedia在transport layer词条中有如下：

引用

A transport protocol is a protocol on the transport layer. The two most widely used transport protocols on the Internet are the connection oriented TCP (Transmission Control Protocol), and connectionless UDP (User Datagram Protocol).

这段话是针对TCP/IP的四层或五层模型来说的。而针对OSI的七层模型，则有Transport Protocol Class 0（TP0）到Transport Protocol Class 4（TP4）。

无论哪一种，都可以认为transport protocol其实就是protocol on the transport layer，也就是“传输层协议”。联系Fielding说HTTP不是transport layer的语境，或许可以认为Fielding的意思就是说HTTP不是传输层协议（而是应用层协议）。

74 楼 leebai 2008-05-09  

dlee 写道

to leebai：

我觉得不是什么大问题吧，大家投一下票，投票的人多了，改一下也是可以的。

不过“transfer”和“transport”全部都按照你的意思改为“传输”，后面Fielding又说“HTTP不是一种传输协议”，引起的歧义和混乱也会很大，所以这样改还是要慎重一些。

我不是跟你说了吗？这样翻译随便找个中国人都会，我们最初也确实是按照你说的做法翻译的，但是后来发现这样翻译问题很大才改过来的。你没有做过多少翻译，不是很清楚这里的两难局面。

你来提个修改方案，然后大家投票是否应该修改，按照票数多的来做。

我没用过JE的投票，没找到链接。

我的修改方案前面提到过：把transfer全翻译成“传输”，6.5.3标题翻译成“HTTP不是一种传输层协议”（加一个译注）

效果如下：

原译：

引用

6.3.2.2
....
REST确实识别出了另外一层编码的需求：将那些编码通过一个连接器添加到一个消息
上，从而改善了消息在网络上的可转移性（transferability）。这个新的层叫做一个转移编码
（transfer-encoding，引用在MIME中一个类似的概念），允许为转移而对消息进行编码，
而不是意味着表述生来就是已编码的。转移编码能够被转移代理（transfer agents）因为某种
原因添加或者移除，而不会改变表述的语义。

改译：

引用

6.3.2.2
....
REST确实识别出了另外一层编码的需求：将那些编码通过一个连接器添加到一个消息
上，从而改善了消息在网络上的可传输性（transferability）。这个新的层叫做一个传输编码
（transfer-encoding，引用在MIME中一个类似的概念），允许为传输而对消息进行编码，
而不是意味着表述生来就是已编码的。传输编码能够被传输代理（transfer agents）因为某种
原因添加或者移除，而不会改变表述的语义。

原译：

引用

6.5.3 HTTP并不是一种传输协议
HTTP并不是被设计为一种传输协议（transport protocol），它是一种转移协议（transfer
protocol）...

改译：

引用

6.5.3 HTTP并不是一种传输层协议
HTTP并不是被设计为一个传输层协议（译著：原文为transport protocol，按下文意思，这里专指transport layer protocol），它是一种传输协议（transfer
protocol）...

73 楼 dlee 2008-05-09  

to leebai：

我觉得不是什么大问题吧，大家投一下票，投票的人多了，改一下也是可以的。

不过“transfer”和“transport”全部都按照你的意思改为“传输”，后面Fielding又说“HTTP不是一种传输协议”，引起的歧义和混乱也会很大，所以这样改还是要慎重一些。

我不是跟你说了吗？这样翻译随便找个中国人都会，我们最初也确实是按照你说的做法翻译的，但是后来发现这样翻译问题很大才改过来的。你没有做过多少翻译，不是很清楚这里的两难局面。

你来提个修改方案，然后大家投票是否应该修改，按照票数多的来做。

72 楼 leebai 2008-05-09  

dlee 写道

leebai 写道

不是说“transfer”只能译为“传输”。http的transfer你译成“转移”语义上也没错，只是“数据在线路上的移动”这个“事”，大家已经习惯用“传输”来表达了（不单在transport layer，即使是两个网卡之间，双绞线上，硬盘连接线上，cpu与内存之间。。。），你那样写会增加读者的阅读困难。

“数据在线路上的移动”思考的层次还是太低了，基本上还是传输层的思维。“线路”这个概念在应用层已经不需要考虑了，应用层只需要确信底层协议能够提供可靠的“点对点通信”的支持，而不需要去关心通信的“线路”。

“数据的转移”意思是将应用层的多个通信参与者看作好像是具有高度智能的人，数据在他们之间转移，通信的参与者还会对数据做一些转换，执行一些操作。因为这个过程具有高度的智能，所以这个过程已经不能简单地以“透明的传输”过程来描述清楚了。

传输  ！＝ 透明的传输 ，传输就是传输，这个词和透明不透明没有关系（我前面的帖子也反复说过作者很强调Tranfer的“过程”及“中间组件”，因此认为它们是REST的“中心思想”）。就像你的“转移”，既看不出它表示透明，也看不出它不透明。

“数据传输”是被广泛接受的说法，在你们的译文中，为了回避传输这个词，把“传输编码”、“传输速率”。。。等常用词汇全变成了"转移编码"、“转移速率”、、、，所有的数据传递概念都用“转移”字眼，读起来真的很费尽。

此前没有人和你们反应过这些翻译问题吗？

71 楼 dlee 2008-05-09  

leebai 写道

不是说“transfer”只能译为“传输”。http的transfer你译成“转移”语义上也没错，只是“数据在线路上的移动”这个“事”，大家已经习惯用“传输”来表达了（不单在transport layer，即使是两个网卡之间，双绞线上，硬盘连接线上，cpu与内存之间。。。），你那样写会增加读者的阅读困难。

“数据在线路上的移动”思考的层次还是太低了，基本上还是传输层的思维。“线路”这个概念在应用层已经不需要考虑了，应用层只需要确信底层协议能够提供可靠的“点对点通信”的支持，而不需要去关心通信的“线路”。

“数据的转移”意思是将应用层的多个通信参与者看作好像是具有高度智能的人，数据在他们之间转移，通信的参与者还会对数据做一些转换，执行一些操作。因为这个过程具有高度的智能，所以这个过程已经不能简单地以“透明的传输”过程来描述清楚了。

70 楼 leebai 2008-05-09  

dlee 写道

to leebai：

好吧，这次算你说的对。

不过在这个论文中，至少有一个地方，你是说不通的：
6.4 Technology Transfer
难道翻译为“技术传输”？

反正我是不会把“transfer”全部翻译为“传输”的，翻译为“转移”就是为了显示出与“传输层协议”的区别。

啥这次，Transfer/Transition之异我前面的帖子也说过，你没仔细看。

6.4 Technology Transfer 翻译为“技术迁移”我不反对，但从正文三个小节的内容看，意译成“技术演化”是不是更好？


不是说“transfer”只能译为“传输”。http的transfer你译成“转移”语义上也没错，只是“数据在线路上的移动”这个“事”，大家已经习惯用“传输”来表达了（不单在transport layer，即使是两个网卡之间，双绞线上，硬盘连接线上，cpu与内存之间。。。），你那样写会增加读者的阅读困难。

69 楼 dlee 2008-05-09  

to leebai：

好吧，这次算你说的对。

不过在这个论文中，至少有一个地方，你是说不通的：
6.4 Technology Transfer
难道翻译为“技术传输”？

反正我是不会把“transfer”全部翻译为“传输”的，翻译为“转移”就是为了显示出与“传输层协议”的区别。

68 楼 leebai 2008-05-09  

dlee 写道

leebai 写道

想了想，应该把整个request-response周期看作一次Transfer。

从这个角度思考，确实和服务器端资源状态之间的transfer更接近了。

你，你，你....水又要搞浑:

something move from A to B 才叫Transfer,东西还是那个东西只是位置变了. 
服务器state A replaced by state B  ,只能叫Transition，原来的东西已经没有了。Transfer没有这样用的。

67 楼 dlee 2008-05-09  

leebai 写道

想了想，应该把整个request-response周期看作一次Transfer。

从这个角度思考，确实和服务器端资源状态之间的transfer更接近了。

66 楼 leebai 2008-05-09  

clia 写道

leebai 写道

模糊处理：把整个HTTP 消息看作Representational state 应该差不多。

还有个问题：普通GET request 消息算不算Representational state？ （它其实没什么state）。

我理解的Representational state 应该跟 representation是一个意思的，都是带资源状态的，都是用来在各components之间进行传送的。但直接叫“Representation Transfer”不太好，看不明白，而且没表示出状态。

GET应该是不带representation的吧，或者叫空的representation？

想了想，应该把整个request-response周期看作一次Transfer。

65 楼 clia 2008-05-08  

leebai 写道

模糊处理：把整个HTTP 消息看作Representational state 应该差不多。

还有个问题：普通GET request 消息算不算Representational state？ （它其实没什么state）。

我理解的Representational state 应该跟 representation是一个意思的，都是带资源状态的，都是用来在各components之间进行传送的。但直接叫“Representation Transfer”不太好，看不明白，而且没表示出状态。

GET应该是不带representation的吧，或者叫空的representation？

64 楼 leebai 2008-05-08  

<div class='quote_title'>clia 写道</div>
<div class='quote_div'>
<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>你的“表形性状态”我基本赞同，还有“最后一片乌云”是：<br/><br/>Representational 除了表示“形”，是不是还表示Header！、Method、URI、reponse code 等“型”的信息？</div>
<p><br/>又翻了一下论文，为追求真义，还下了英文原文来看了一下，发现论文中最难翻的就是这个“representation”了。<br/>如果“representational”可以翻成“表形性”的话，那“representation”又该如何翻？<br/>资源的：“形象”？“外形”？“表现形式”？“表形”？“表示”？</p>
<div class='quote_title'>Fielding 写道</div>
<div class='quote_div'>5.2.1.2 Representations<br/>REST components perform actions on a resource by using a representation to capture the<br/>current or intended state of that resource and transferring that representation between<br/>components.</div>
<p><br/>从“transferring that representation”来看，还是翻成“表示”更合适，但“表示性状态”又会使人犯迷糊，真是难两全啊！<br/><br/>之前想不明白，除了HTML、JPEG等以外，XML、JSON这些不具“形”的东西（不是给人看，而是给机器处理），会不会算是作者所指的“representation”呢？可能是我理解错了，作者所指的representation并没有说一定要具“形”，被之前的“表示层”这样的概念误导了，以为“representational”都是要给人看的。<br/><br/>leebai的问题，Header！、Method、URI、reponse code 等应该是属于REST里的其他数据元素，如下表：<br/><br/>                 Table 5-1. REST Data Elements<br/>         Data Element                      Modern Web Examples<br/>resource                           the intended conceptual target of a hypertext reference<br/>resource identifier              URL, URN<br/>representation                   HTML document, JPEG image<br/>representation metadata     media type, last-modified time<br/>resource metadata             source link, alternates, vary<br/>control data                      if-modified-since, cache-control</p>
<p> </p>
</div>
<p>模糊处理：把整个HTTP 消息看作Representational state 应该差不多。</p>
<p>还有个问题：普通GET request 消息算不算Representational state？ （它其实没什么state）。</p>