REST相关文章笔记

（1）http://www.infoq.com/cn/articles/roa-rest-of-rest

REST牵涉到使用几个动词通过URL来请求和提供信息资源的应用信息。
1.URL发起GET请求来抽取信息
2.你通过POST和PUT来创建和更新
3.而DELETE请求用于移除信息。

REST包括以下主题：
1)URL作为标识符
例子:
http://someserver.com/cgi-bin/foo/bar.pl
http://someserver.com/ActionServlet?blah=blah
http://someserver.com/foo/bar.php
以上是不好形式的url，应该关注于信息，而不是技术实现

2)自由的形式
http://company1.com/report/sales/2009/qtr/3/report.html
http://company1.com/report/sales/2009/qtr/3/report.xml
http://company1.com/report/sales/2009/qtr/3/report.xls
以上是不好形式的url，因为每个url体现了展现形式
每个url应类似于http://company1.com/report/sales/2009/qtr/3的形式，而内容的展现形式由http请求Accept来体现

3)逻辑连接的延迟绑定系统
依赖于逻辑关系能够保护客户不受实现变更的影响

4)超文本作为状态转移的引擎（HATEOS）
以一个已知或者已发现的点作为开始，就像你浏览web一样来浏览信息。

REST客户端
1.RESTful客户端只需要取回资源，调查返回的MIME类型，触发合适的分析器，并分析结果。这样一来，客户端就知道如何分析返回的类型了。
2.客户端不应当被要求了解如何去分析一个URL或是对于一个层次相对另一层次而言意味着什么有详细的认识。

=====================================================================

（2）http://www.infoq.com/cn/articles/rest-introduction

REST五条关键原则：
1)为所有“事物”定义ID
使用URI标识所有值得标识的事物，特别是应用中提供的所有“高级”资源，无论这些资源代表单一数据项、数据项集合、虚拟亦或实际的对象

还是计算结果等。
2)将所有事物链接在一起
任何可能的情况下，使用链接指引可以被标识的事物（资源）。
3)使用标准方法
为使客户端程序能与你的资源相互协作，资源应该正确地实现默认的应用协议（HTTP），也就是使用标准的GET、PUT、POST和DELETE方法。
4)资源多重表述
针对不同的需求提供资源多重表述。
5)无状态通信
无状态约束使服务器的变化对客户端是不可见的

REST在本质上是一个可以被许多不同技术实现的高层次的风格，而且可以被实例化
REST风格的一个“化身”便是HTTP
===================================================================

（3）http://www.infoq.com/cn/articles/tilkov-rest-doubts

1.REST也许适用于CRUD，但并不适用于“真实的”业务逻辑
首先，HTTP动词（verbs）——GET、PUT、POST和DELETE——跟数据库的CRUD操作并不是一一对应的。
通过POST请求向服务器提供输入数据、以便服务器新建一个资源”是更合适的做法。服务器在响应该POST请求时，可以给出结果的URI （而且有可能发起一个重定向把你转向过去）。这个结果接下来便可被重用、被加入书签、在获取时被缓存等等。你基本上可以将这一模型推广应用到任何产生结果的操作——这涵盖几乎你所能想到的所有操作。

2.没有正式的契约与描述语言
对于REST的统一接口（uniform interface）来说，描述这些是颇为无趣的，因为GET、PUT、POST和DELETE就是你所能使用的全部操作了。
即便你依赖于一个REST式接口，你仍旧可使用你所偏爱的数据绑定工具
你只要在浏览器中对一个资源做 HTTP GET请求，就可以得到一个HTML文档，其中不但包含数据，还包含你可以对它执行的操作（HTTP动词）的列表以及它接受和返回的内容类型（content types）。

3.谁真会把他们应用中如此多的实现细节暴露出来？
你采用以数据为中心的（data-centric）方式、而不是以操作为中心的（operation-centric）方式把业务逻辑暴露出来。

4.REST只能配合HTTP使用，它不是传输协议无关的
仅将HTTP作为传输，是不恰当的

5.没有实际的、明确且一致的指南教你如何设计REST式应用

6.REST不支持事务
很大程度上，在SOA或REST环境中需要ACID事务，其实是一种设计异味（design smell）——你很可能已经为你的服务或资源采用了错误的模型。

7.REST是不可靠的
确保请求消息抵达另一端的最简单的做法，就是把消息重发一遍
HTTP确保GET、PUT和DELETE是幂等的（idempotent ）——如果你的应用实现得当的话，那么客户端在没有收到响应时只需把请求重发一遍即可。但POST消息不是幂等的——至少在HTTP规范里没有保证。

8.不支持发布/订阅
轮流通知（notification by polling）具有极好的可伸缩性

9.无异步交互
HTTP有一个专门的响应代码202 Accepted，它的意思是“请求已被接受处理，但处理还没有结束”。显然，这正是你所需要的。至于处理结果，有多种办法：服务器可以返回一个资源的 URI，然后客户端通过向该URI发送GET请求来访问结果（尽管在专门为一个请求创建资源时采用响应代码201 Created更为恰当）。或者，客户端可以提供一个URI，并期待服务器在处理完成后把结果POST上去。

10.缺少工具

================================================================

（4）http://www.infoq.com/cn/articles/rest-anti-patterns

1.全部采用GET
2.全部采用POST
3.忽视缓存
4.忽视响应代码
5.误用cookies
6.忘记超媒体
7.忽视MIME类型
8.破坏自描述性

==================================================================

（5）http://zh.wikipedia.org/wiki/%E8%B6%85%E6%96%87%E6%9C%AC%E4%BC%A0%E8%BE%93%E5%8D%8F%E8%AE%AE

安全及幂等方法
1.安全方法
开发者应当意识到他们的软件代表了用户在因特网上进行交互，并且应当告知用户，他们正在进行的操作可能对他们自身或者其他人有未曾预料的重要影响。
特别地，对于GET和HEAD方法而言，除了进行获取资源信息外，这些请求不应当再有任何其他意义。也就是说，这些方法应当被认为是“安全的”。客户端应当使用其他“非安全”方法，例如POST，PUT及DELETE来以特殊的方式（通常是按钮而不是超链接）使得客户能够意识到可能要负的责任（例如一个按钮带来的资金交易）或者被告知正在请求的操作可能是不安全的（例如某个文件将被上传或删除）。
但是，不能想当然地认为服务器不会在处理某个GET请求时不会产生任何副作用。事实上，很多动态资源会把这作为其特性。这里重要的区别在于用户并没有请求这一副作用，因此不应由用户为这些副作用承担责任。
2.幂等方法
假如在不考虑诸如错误或者过期等问题的情况下，若干次请求的副作用与单次请求相同或者根本没有副作用，那么这些请求方法就能够被视作“幂等”的。 GET，HEAD，PUT和DELETE方法都有这样的幂等属性，同样由于根据协议，OPTIONS，TRACE都不应有副作用，因此也理所当然也是幂等的。
假如某个由若干个请求做成的请求序列产生的结果在重复执行这个请求序列或者其中任何一个或多个请求后仍没有发生变化，则这个请求序列便是“幂等” 的。但是，可能出现若干个请求做成的请求序列是“非幂等”的，即使这个请求序列中所有执行的请求方法都是幂等的。例如，这个请求序列的结果依赖于某个会在下次执行这个序列的过程中被修改的变量。

关于POST和PUT
创建操作可以使用POST，也可以使用PUT，区别在于POST是作用在一个集合资源之上的（/articles），而PUT操作是作用在一个具体资源之上的（/articles/123），再通俗点说，如果URL可以在客户端确定，那么就使用PUT，如果是在服务端确定，那么就使用POST，比如说很多资源使用数据库自增主键作为标识信息，而创建的资源的标识信息到底是什么只能由服务端提供，这个时候就必须使用POST。