《 Restful Web Services 》读书笔记 | Chapter Four

《 Restful Web Services 》读书笔记
第四章 The Resource-Oriented Architecture

这一章开始，本书变的精彩了 !
第一章里，我们说过方法信息和作用域信息， 这实际上是REST四个标志的其中两个：

作用域信息是放到URI里的，这是可寻址性（addressability）原则。
方法信息是放在HTTP方法里的， 这是人人都知道的方法，这是统一接口（uniform interface）原则。

这一章里作者引入了一个概念，ROA(Resource-Oriented Architecture)，面向资源架构。这是因为用REST架构这个词，争议太多了。
那么， 这里讲的就是关于ROA的四个概念：
1.资源 2. 资源的名称（URI）3. 资源的表示 4. 资源间的链接
以及四个属性：
1.可寻址性 2. 无状态性 3.连通性 4.统一接口。

一 资源以及资源的名称

任何事物，只要有被引用的必要，它就是一个资源（resource）。它可以是具体实物的表示，也可以是抽象的概念。要想成为一个资源，必须要有一个URI， 它既是资源的名称，又是资源的地址。URI应具有描述性，这一点是最佳实践，并不是REST的必备规则。

一个URI只能标示（designate）一个资源。假如一个URI标示多个资源的话，它就不是统一资源标识符了。不过当你请求一个URI的时候，服务端也会返回多个资源的信息。这里就涉及到一个资源的链接。

二 可寻址性

可以想象得到可寻址性的重要性。假如你的网站没有地址， 你让用户怎么办 ？
可寻址性是Web应用最大的优点。这个属性是不难理解的。
可寻址性要求，服务器所能提供的每一则又价值的信息都应该作为资源来发布，而且每个资源都应该有自己的URI.

三 无状态性

无状态性（statelessness）是指每个HTTP请求都是完全孤立的。服务器不依赖任何之前的请求提供的信息。
无状态性要求， 服务器可能的状态也是资源，也该有自己的URI.
无状态性意味着， 有一种状态，是服务器不应保存的。

到底什么是状态了 ？
状态分为两种，应用状态（application state）和资源状态（resource state）：前者应该保存在客户端的，后者应该保存在服务端。

应用状态：
举例， 当你使用搜索 引擎的时候，你的搜索请求和当前页码就是属于应用状态。这些是因客户端而异的，你在浏览‘51cto’搜索结果的第1页，而我已经看到了第2页。 一个web服务，仅当实际收到请求时候才关心你的应用状态，其他时刻，你的存在对它没有意义。各个客户端应该管理自己的状态。

资源状态：
对于每个客户都是相同的，它应该保存在服务端。你上传了一个图片，拥有了自己的uri，你可以通过http获取它，我也可以。该图片是一个资源状态，它一直保存在服务器上。

刚开始理解起来可能比较费劲。不过等看了后面的实例以后，就没那么难理解了。

四 表示（representations）
我对表示的理解就是：用一个时髦的词来说，那就是‘画皮（painted skin）’。 资源只是表示的来源，你对外的表示好看与否就取决于你用的哪张皮。比如一个新闻网站，可以提供富含广告的格式，也可以提供简单，便于打印的格式，这就是同一资源的不同表示（painted skin）。

如果一个资源有多个表示，那么服务器应该把哪个表示返回给客户端呢 ？最简单以及被推荐的方案就是，为不同的表示指定不同的URI。

五 链接与连通性
在大多数的REST式服务里，表示都是超媒体（hypermedia），也就是说文档中不仅包含数据，还包含指向其他资源的链接。作者又举了搜索的例子：
当你拜狗狗大神（google）的时候， 你会得到一些搜索结果， 不仅仅是你想要的数据，而且还包含了一组指向其余搜索结果的链接，比如网页快照，分页链接等。Roy Fielding博士说：“将超媒体作为应用状态的引擎”， 意思是：HTTP会话的当前状态不是作为资源状态保存在服务器上的，而是被客户端作为应用状态来跟踪的。客户端应用状态在服务器提供的超媒体（超文本表示里的链接和表单）的指引下发生变迁。
服务器通过超媒体告诉客户端有哪些后续状态可以进入。作者把这种具有链接的特性叫连通性。
值得注意的是，我们一直是在programmable web下面来讨论的。 human web只所以易用，就是因为它在连通性方面做的很好，用户进去一个页面，通过链接，可以方便的到其他页面。 而programmable web也可以这么做了，看个例子：
<?xml version=’1.0’ encoding=’UTF-8’>
<ListAllMyBucketsResult>
...
<Bucket>
<Name>crummy.com</Name>
<URI>https://s3.amazonaws.com/crummy.com</URI>
</Bucket>
...
</ListAllMyBucketsResult>
上面的例子，多了一个URI标签，显示了资源之间的链接，也就是连通性。

六 统一接口
我们第三章已经总结了，就是指HTTP方法。
常见的操作：
获取资源的一个表示 ： HTTP GET
创建一个新资源：向一个新URI发送HTTP PUT, 或向一个已有URI发送HTTP POST
修改已有资源： 向已有URI发送HTTP PUT
删除已有资源： HTTP DELETE

HEAD和OPTIONS

获取一个只包含元数据的表示： HTTP HEAD
查看一个资源支持哪些HTTP方法： HTTP OPTIONS (Allow 报头)

POST
它的目的是允许采用一个统一的方法来作以下的操作：
1. 对现有资源进行注释；
向公告板，新闻组，邮件列表等发布一则消息；
向一个数据加工处理程序提供一个数据块（比如提交表单所产生的）
通过一个添加操作来扩充数据库。
在ROA设计里， POST一般被用来创建从属资源。好像前面是说PUT也可以这么做。有什么区别呢：
假如是客户端负责决定新资源采用什么URI, 那就用PUT; 假如是服务器负责新资源采用什么URI, 那就用POST.

重载的POST
向一个数据加工处理程序提供一个数据块（比如提交表单所产生的）， 这种POST的用法就叫重载的POST，因为这种方式是用一个HTTP方法来表达无数个非HTTP方法，就好像重载操作符一样。 大部分的web应用使用的就是重载POST.这个不符合统一接口。

七 安全性和幂等性
GET和HEAD请求都是安全的。 GET, HEAD,PUT和DELETE请求都是幂等的。

安全性是指，不改变服务器状态。GET, HEAD请求不会给服务器带来任何副作用。

幂等性是指，幂等的操作被运用多少遍，它的结果总是相同的。 比如0乘以多少个其他数，结果都是0。对一个资源，GET请求不管发多少次，得到的结果，还是一样的。PUT请求，创建一个新资源， 如果再发一次同样的PUT请求，结果还是只存在一个新资源。当PUT请求修改一个资源的时候，你发第二次， 那个资源的状态还是你的PUT请求中所指定的那样。DELETE请求删除一个资源的时候，你再发第二次DELETE请求， 结果是那个资源同样不存在。
幂等性就是不允许客户端对资源状态做相对的改动。

安全性和幂等性是重要的，可以让客户端在不可靠的网络上实现可靠的HTTP请求。
POST即不安全又不幂等， 如果你连发两遍POST,可能多了两条一样的资源。
重载POST结果是不可预计的，当然它也是非安全非幂等的。

八 统一接口的重要性

引用文中一段话：
“采用HTTP定义的哪个特定的统一接口并不是REST的要点。REST要求采用统一接口，但它并没有说具体采用哪个统一接口。GET,PUT等并非永远都是最合适的接口。关键在于统一性，即每个服务都以同样的方式使用HTTP接口。”

to be continued ... ...
本文出自 “悟道集” 博客，请务必保留此出处http://blackanger.blog.51cto.com/140924/107287