1. 什么是REST
REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。 它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。 他在论文中提到："我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。" 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。
REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力， 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深， 但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。 所以我们这里描述的REST也是通过HTTP实现的REST。
2. 理解RESTful
要理解RESTful架构，需要理解Representational State Transfer这个词组到底是什么意思，它的每一个词都有些什么涵义。 下面我们结合REST原则，围绕资源展开讨论，从资源的定义、获取、表述、关联、状态变迁等角度，列举一些关键概念并加以解释。
统一资源接口
资源的表述
资源的链接
状态的转移
2. 1 资源与URI
REST全称是表述性状态转移，那究竟指的是什么的表述? 其实指的就是资源。任何事物，只要有被引用到的必要，它就是一个资源。资源可以是实体(例如手机号码)，也可以只是一个抽象概念(例如价值) 。下面是一些资源的例子：
某用户的手机号码
某用户的个人信息
最多用户订购的GPRS套餐
两个产品之间的依赖关系
某用户可以办理的优惠套餐
某手机号码的潜在价值
要让一个资源可以被识别，需要有个唯一标识，在Web中这个唯一标识就是URI(Uniform Resource Identifier)。
URI既可以看成是资源的地址，也可以看成是资源的名称。如果某些信息没有使用URI来表示，那它就不能算是一个资源， 只能算是资源的一些信息而已。URI的设计应该遵循可寻址性原则，具有自描述性，需要在形式上给人以直觉上的关联。这里以github网站为例，给出一些还算不错的URI：
/git/git/blob/master/block-sha1/sha1.h
/git/git/commit/e3af72cdafab5993d18fae056f87e1d
/git/git/pulls
/git/git/pulls?state=closed
/git/git/compare/master…next
下面让我们来看看URI设计上的一些技巧:
使用_或-来让URI可读性更好
曾经Web上的URI都是冰冷的数字或者无意义的字符串，但现在越来越多的网站使用_或-来分隔一些单词，让URI看上去更为人性化。 例如国内比较出名的开源中国社区，它上面的新闻地址就采用这种风格， 如http://www.oschina.net/news/38119/oschina-translate-reward-plan。
使用/来表示资源的层级关系
例如上述/git/git/commit/e3af72cdafab5993d18fae056f87e1d就表示了一个多级的资源， 指的是git用户的git项目的某次提交记录，又例如/orders/2012/10可以用来表示2012年10月的订单记录。
使用?用来过滤资源
很多人只是把?简单的当做是参数的传递，很容易造成URI过于复杂、难以理解。可以把?用于对资源的过滤， 例如/git/git/pulls用来表示git项目的所有推入请求，而/pulls?state=closed用来表示git项目中已经关闭的推入请求， 这种URL通常对应的是一些特定条件的查询结果或算法运算结果。
,或;可以用来表示同级资源的关系
有时候我们需要表示同级资源的关系时，可以使用,或;来进行分割。例如哪天github可以比较某个文件在随意两次提交记录之间的差异，或许可以使用/git/git /block-sha1/sha1.h/compare/e3af72cdafab5993d18fae056f87e1d;bd63e61bdf38e872ddcc16e4febca作为URI。 不过，现在github是使用…来做这个事情的，例如/git/git/compare/master…next。
2. 2 统一资源接口
RESTful架构应该遵循统一接口原则，统一接口包含了一组受限的预定义的操作，不论什么样的资源，都是通过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GET，PUT和POST，并遵循这些方法的语义。
如果按照HTTP方法的语义来暴露资源，那么接口将会拥有安全性和幂等性的特性，例如GET和HEAD请求都是安全的， 无论请求多少次，都不会改变服务器状态。而GET、HEAD、PUT和DELETE请求都是幂等的，无论对资源操作多少次， 结果总是一样的，后面的请求并不会产生比第一次更多的影响。
下面列出了GET，DELETE，PUT和POST的典型用法:
安全且幂等
变更时获取表示（缓存）
200（OK） - 表示已在响应中发出
204（无内容） - 资源有空表示
301（Moved Permanently） - 资源的URI已被更新
303（See Other） - 其他（如，负载均衡）
304（not modified）- 资源未更改（缓存）
400 （bad request）- 指代坏请求（如，参数错误）
404 （not found）- 资源不存在
406 （not acceptable）- 服务端不支持所需表示
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务端当前无法处理请求
不安全且不幂等
使用服务端管理的（自动产生）的实例号创建资源
创建子资源
部分更新资源
如果没有被修改，则不过更新资源（乐观锁）
200（OK）- 如果现有资源已被更改
201（created）- 如果新资源被创建
202（accepted）- 已接受处理请求但尚未完成（异步处理）
301（Moved Permanently）- 资源的URI被更新
303（See Other）- 其他（如，负载均衡）
400（bad request）- 指代坏请求
404 （not found）- 资源不存在
406 （not acceptable）- 服务端不支持所需表示
409 （conflict）- 通用冲突
412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）
415 （unsupported media type）- 接受到的表示不受支持
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务当前无法处理请求
不安全但幂等
用客户端管理的实例号创建一个资源
通过替换的方式更新资源
如果未被修改，则更新资源（乐观锁）
200 （OK）- 如果已存在资源被更改
201 （created）- 如果新资源被创建
301（Moved Permanently）- 资源的URI已更改
303 （See Other）- 其他（如，负载均衡）
400 （bad request）- 指代坏请求
404 （not found）- 资源不存在
406 （not acceptable）- 服务端不支持所需表示
409 （conflict）- 通用冲突
412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）
415 （unsupported media type）- 接受到的表示不受支持
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务当前无法处理请求
不安全但幂等
200 （OK）- 资源已被删除
301 （Moved Permanently）- 资源的URI已更改
303 （See Other）- 其他，如负载均衡
400 （bad request）- 指代坏请求
404 （not found）- 资源不存在
409 （conflict）- 通用冲突
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务端当前无法处理请求
下面我们来看一些实践中常见的问题:
POST和PUT用于创建资源时有什么区别?
POST和PUT在创建资源的区别在于，所创建的资源的名称(URI)是否由客户端决定。 例如为我的博文增加一个java的分类，生成的路径就是分类名/categories/java，那么就可以采用PUT方法。不过很多人直接把POST、GET、PUT、DELETE直接对应上CRUD，例如在一个典型的rails实现的RESTful应用中就是这么做的。 我认为，这是因为rails默认使用服务端生成的ID作为URI的缘故，而不少人就是通过rails实践REST的，所以很容易造成这种误解。
客户端不一定都支持这些HTTP方法吧?
的确有这种情况，特别是一些比较古老的基于浏览器的客户端，只能支持GET和POST两种方法。 在实践上，客户端和服务端都可能需要做一些妥协。例如rails框架就支持通过隐藏参数_method=DELETE来传递真实的请求方法， 而像Backbone这样的客户端MVC框架则允许传递_method传输和设置X-HTTP-Method-Override头来规避这个问题。
统一接口是否意味着不能扩展带特殊语义的方法?
统一接口并不阻止你扩展方法，只要方法对资源的操作有着具体的、可识别的语义即可，并能够保持整个接口的统一性。 像WebDAV就对HTTP方法进行了扩展，增加了LOCK、UPLOCK等方法。而github的API则支持使用PATCH方法来进行issue的更新，例如:
PATCH /repos/:owner/:repo/issues/:number
不过，需要注意的是，像PATCH这种不是HTTP标准方法的，服务端需要考虑客户端是否能够支持的问题。
统一资源接口对URI有什么指导意义?
统一资源接口要求使用标准的HTTP方法对资源进行操作，所以URI只应该来表示资源的名称，而不应该包括资源的操作。 通俗来说，URI不应该使用动作来描述。例如，下面是一些不符合统一接口要求的URI:
GET /getUser/1
POST /createUser
PUT /updateUser/1
DELETE /deleteUser/1
如果GET请求增加计数器，这是否违反安全性?
安全性不代表请求不产生副作用，例如像很多API开发平台，都对请求流量做限制。像github，就会限制没有认证的请求每小时只能请求60次。 但客户端不是为了追求副作用而发出这些GET或HEAD请求的，产生副作用是服务端"自作主张"的。 另外，服务端在设计时，也不应该让副作用太大，因为客户端认为这些请求是不会产生副作用的。
直接忽视缓存可取吗?
即使你按各个动词的原本意图来使用它们，你仍可以轻易禁止缓存机制。 最简单的做法就是在你的HTTP响应里增加这样一个报头： Cache-control: no-cache。 但是，同时你也对失去了高效的缓存与再验证的支持(使用Etag等机制)。 对于客户端来说，在为一个REST式服务实现程序客户端时，也应该充分利用现有的缓存机制，以免每次都重新获取表示。
响应代码的处理有必要吗?
HTTP的响应代码可用于应付不同场合，正确使用这些状态代码意味着客户端与服务器可以在一个具备较丰富语义的层次上进行沟通。 例如，201（"Created"）响应代码表明已经创建了一个新的资源，其URI在Location响应报头里。 假如你不利用HTTP状态代码丰富的应用语义，那么你将错失提高重用性、增强互操作性和提升松耦合性的机会。 如果这些所谓的RESTful应用必须通过响应实体才能给出错误信息，那么SOAP就是这样的了，它就能够满足了。
2. 3 资源的表述
上面提到，客户端通过HTTP方法可以获取资源，是吧? 不，确切的说，客户端获取的只是资源的表述而已。 资源在外界的具体呈现，可以有多种表述(或成为表现、表示)形式，在客户端和服务端之间传送的也是资源的表述，而不是资源本身。 例如文本资源可以采用html、xml、json等格式，图片可以使用PNG或JPG展现出来。 资源的表述包括数据和描述数据的元数据，例如，HTTP头"Content-Type" 就是这样一个元数据属性。
那么客户端如何知道服务端提供哪种表述形式呢?
答案是可以通过HTTP内容协商，客户端可以通过Accept头请求一种特定格式的表述，服务端则通过Content-Type告诉客户端资源的表述形式。
以github为例，请求某组织资源的json格式的表述形式:
　　假如github也能够支持xml格式的表述格式，那么结果就是这样的:
　　下面我们来看一些实践上常见的设计:
在URI里边带上版本号
有些API在URI里边带上版本号，例如:
如果我们把版本号理解成资源的不同表述形式的话，就应该只是用一个URL，并通过Accept头部来区分，还是以github为例，它的Accept的完整格式是:application/vnd.github[.version].param[+json]
对于v3版本的话，就是Accept: application/vnd.github.v3。对于上面的例子，同理可以使用使用下面的头部:
Accept: vnd.example-com.foo+ version=1.0
Accept: vnd.example-com.foo+ version=1.2
Accept: vnd.example-com.foo+ version=2.0
使用URI后缀来区分表述格式
像rails框架，就支持使用/users.xml或/users.json来区分不同的格式。 这样的方式对于客户端来说，无疑是更为直观，但混淆了资源的名称和资源的表述形式。 我个人认为，还是应该优先使用内容协商来区分表述格式。
如何处理不支持的表述格式
当服务器不支持所请求的表述格式，那么应该怎么办？若服务器不支持，它应该返回一个HTTP 406响应，表示拒绝处理该请求。下面以github为例，展示了一个请求XML表述资源的结果：
　　2. 4 资源的链接
我们知道REST是使用标准的HTTP方法来操作资源的，但仅仅因此就理解成带CURD的Web数据库架构就太过于简单了。 这种反模式忽略了一个核心概念："超媒体即应用状态引擎（hypermedia as the engine of application state）"。 超媒体是什么? 当你浏览Web网页时，从一个连接跳到一个页面，再从另一个连接跳到另外一个页面，就是利用了超媒体的概念：把一个个把资源链接起来.
要达到这个目的，就要求在表述格式里边加入链接来引导客户端。在《RESTful Web Services》一书中，作者把这种具有链接的特性成为连通性。下面我们具体来看一些例子。
下面展示的是github获取某个组织下的项目列表的请求，可以看到在响应头里边增加Link头告诉客户端怎么访问下一页和最后一页的记录。 而在响应体里边，用url来链接项目所有者和项目地址。
　　又例如下面这个例子，创建订单后通过链接引导客户端如何去付款。
上面的例子展示了如何使用超媒体来增强资源的连通性。很多人在设计RESTful架构时，使用很多时间来寻找漂亮的URI，而忽略了超媒体。所以，应该多花一些时间来给资源的表述提供链接，而不是专注于"资源的CRUD"。
2. 5 状态的转移
有了上面的铺垫，再讨论REST里边的状态转移就会很容易理解了。 不过，我们先来讨论一下REST原则中的无状态通信原则。初看一下，好像自相矛盾了，既然无状态，何来状态转移一说?
其实，这里说的无状态通信原则，并不是说客户端应用不能有状态，而是指服务端不应该保存客户端状态。
2. 5.1 应用状态与资源状态
实际上，状态应该区分应用状态和资源状态，客户端负责维护应用状态，而服务端维护资源状态。 客户端与服务端的交互必须是无状态的，并在每一次请求中包含处理该请求所需的一切信息。
服务端不需要在请求间保留应用状态，只有在接受到实际请求的时候，服务端才会关注应用状态。
这种无状态通信原则，使得服务端和中介能够理解独立的请求和响应。
在多次请求中，同一客户端也不再需要依赖于同一服务器，方便实现高可扩展和高可用性的服务端。
但有时候我们会做出违反无状态通信原则的设计，例如利用Cookie跟踪某个服务端会话状态，常见的像J2EE里边的JSESSIONID。
这意味着，浏览器随各次请求发出去的Cookie是被用于构建会话状态的。
当然，如果Cookie保存的是一些服务器不依赖于会话状态即可验证的信息（比如认证令牌），这样的Cookie也是符合REST原则的。
2. 5.2 应用状态的转移
状态转移到这里已经很好理解了， "会话"状态不是作为资源状态保存在服务端的，而是被客户端作为应用状态进行跟踪的。客户端应用状态在服务端提供的超媒体的指引下发生变迁。服务端通过超媒体告诉客户端当前状态有哪些后续状态可以进入。 这些类似"下一页"之类的链接起的就是这种推进状态的作用——指引你如何从当前状态进入下一个可能的状态。
现在广东XXX版本、XXX等项目中均使用传统的RPC、SOAP方式的Web服务，而移动南方基地XXXX项目的后台， 虽然采用了JSON格式进行交互，但还是属于RPC风格的。本文从资源的定义、获取、表述、关联、状态变迁等角度， 试图快速理解RESTful架构背后的概念。RESTful架构与传统的RPC、SOAP等方式在理念上有很大的不同，希望本文能对各位理解REST有所帮助。
记住登录状态
重复输入密码RESTful HTTP的实践[转] -
- ITeye技术网站
博客分类：
REST是一种风格，而不是标准。因为既没有REST RFC，也没有REST协议规范或者类似的规定。REST架构是Roy Fielding（他也是HTTP和URI规范的主要作者之一）在一篇论文中描述的。像REST这样的架构风格通常会定义一组高层决定让应用程序去实现。所有实现了某种特定架构风格的应用程序，都使用相同的模式，也用相同的方式使用别的架构元素，如缓存，分布式策略等。Roy Fielding把REST定义成一种架构风格，其目标是“使延迟和网络交互最小化，同时使组件实现的独立性和扩展性最大化”
虽然REST受Web技术的影响很深，但是理论上REST架构风格并非绑定在HTTP上。然而，HTTP是唯一与REST相关的实例。基于该原因，本文描述了通过HTTP实现的REST，通常它也被称为RESTful HTTP。
REST并没有创造新的技术，组件或服务，隐藏在RESTful HTTP背后的理念是使用Web的现有特征和能力。RESTful HTTP定义了如何更好地使用现有Web标准中的一些准则和约束。
资源是REST中最关键的抽象概念，它们是能够被远程访问的应用程序对象。一个资源就是一个标识单位，任何可以被访问或被远程操纵的东西都可能是一个资源。资源可以是静态的，也就是该资源的状态永远不会改变。相反，某些资源的状态可能随着时间推移呈现很大的可变性。这两种类型的资源都是有效的。
图1中所显示的这些类都能被很容易地映射成资源。面向对象设计者不容易理解把实体类（如Hotel或者Room）映射成资源，同样他们也不太理解从控制类（如coordination，事务和某个类的控制类）到资源的映射。
图1：分析模型的例子
分析模型是识别资源的一个非常好的“切入点”。然而，并非只能进行1对1映射，比如， &Hotel&.listOccupancy()操作也可以被建模成资源。此外，也有可能某些资源只表示实体的某一部分。资源设计的主要驱动力是网络因素而不是对象模型。
任何重要的资源都应该能够通过一个唯一的标识被访问。RESTful HTTP使用URI来识别资源。URI提供了Web通用的识别机制，它包含了客户端直接与被引用的资源进行交互时需要的所有信息。
如何命名资源标识？
虽然RESTful HTTP并没有明确指出如何构造一个URI路径，但实际上经常被使用的是一些特定的命名模式。URI命名模式有助于应用程序调试和跟踪，通常一个URI包含资源类型及其后面用于定位特定资源的标识。这样的URI不包括指定业务操作的动词（verb），而只用于定位资源。图中a1给出了Hotel资源的一个示例，同一个Hotel资源也可以通过URI（a2）访问。同一资源可以被多个URI引用。
(a1) http://localhost/hotel/656bcee2-28d2-404b-891b
(a2) http://127.0.0.1/hotel/656bcee2-28d2-404b-891b
(b) http://localhost/hotel/656bcee2-28d2-404b-891b/Room/4
(c) http://localhost/hotel/656bcee2-28d2-404b-891b/Reservation/15
(d) http://localhost/hotel/656bcee2-28d2-404b-891b/Room/4/Reservation/15
(e) http://localhost/hotel/656bcee2-28d2-404b-891b/Room/4/Reservation/15v7
(f) http://localhost/hotel/656bcee2-28d2-404b-891bv12
图2：资源寻址的例子
URI也可以被资源用来在资源表示（representation）之间建立关联。例如，Hotel表示通过URI去引用已分配的Room资源，而不是使用普通的RoomID。使用普通的ID会强制调用者通过对资源的访问去构造URI，而调用者如果没有主机名和基础URI路径等上下文信息是无法访问到该资源的。
超链接常被客户端用于资源导航。RESTful API是超文本驱动的，这表示客户端通过获得一个Hotel表示，就能够导航到已分配的Room表示和Reservation表示。
在实践中，图1所示的这些类经常被映射成某种业务对象，这意味着在业务对象的整个生命周期中URI将保持不变。如果要创建一个新资源，则要为之分配一个新的URI。而一旦这个新资源被删除，相应的URI则跟着失效。如图2中的（a），（b），（c）和（d）就是这种标识的例子。另一方面，URI也可以用来引用资源快照，比如（e）和（f）就是对这类快照的引用，其URI中包含了一个版本标识。
URI还可以定位子资源，如示例中的（b），（c），（d）和（e）。通常，被聚集的对象会被映射成子资源，如Room是被Hotel聚集的。被聚集的对象通常没有自己的生命周期，如果它的父对象被删除，所有的被聚集对象也跟着被删除。
然而，如果一个子资源可以从一个父资源移动到另一个父对象， 那么在它的URI中就不应该包含其父资源的标识。比如图1中的Reservation资源，它就可以被分配给另一个Room资源。如果一个Reservation资源的URI包含了其父资源Room的标识，如（d）所示，则当Room实例标识改变时，如果该Reservation资源又被另一个资源引用的话，这就会出问题。为了避免无效的URI，Reservation应该通过（c）这样的方式进行寻址。
通常，资源的URI是由服务器控制的。客户端访问资源时并不需要理解资源的URI命名空间结构。比如，使用（c）和（d）两个URI结构对客户端而言具有效果相同。
统一资源接口
为了简化整体系统架构，REST架构风格包含了统一接口的概念。统一接口包含一组受限的良定义的操作，由它们进行资源的访问和操作。不论什么资源，都使用相同的接口。客户端与Hotel，Room或CreditScore等资源交互时使用的接口是一样的。统一接口独立于资源的URI，并且也不需要类似IDL的文件去描述可用的操作。
RESTful HTTP的接口非常流行且广为使用。它包含标准的HTTP方法如GET，PUT和POST（浏览器使用它发出请求并提取页面）。不幸的是，很多开发者认为实现RESTful应用就是用一种直接使用HTTP的方式，这种理解是错误的。举个例子，HTTP方法的实现必须要遵循HTTP规范的，而通过GET方法创建或修改对象是不遵守HTTP规范的。
应用统一接口
关于何时以及如何使用不同的HTTP动词（verb），在Fielding的论文中没有任何表格、列表或其他方式的描述。对于大部分方法，如GET或 DELETE，通过阅读HTTP规范就能清楚其含义，而对于POST和部分更新，就不那么容易了。在实践中，对资源进行部分更新有好几种方法，下文将有详细介绍。
表1列出了大部分重要的方法GET，DELETE，PUT和POST的典型用法：
典型状态码
- 获取表示
- 变更时获取表示（缓存）
200（OK） - 表示已在响应中发出
204（无内容） - 资源有空表示
301（Moved Permanently） - 资源的URI已被更新
303（See Other） - 其他（如，负载均衡）
304（not modified）- 资源未更改（缓存）
400 （bad request）- 指代坏请求（如，参数错误）
404 （not found）- 资源不存在
406 （not acceptable）- 服务端不支持所需表示
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务端当前无法处理请求
- 删除资源
200 （OK）- 资源已被删除
301 （Moved Permanently）- 资源的URI已更改303 （See Other）- 其他，如负载均衡
400 （bad request）- 指代坏请求t404 （not found）- 资源不存在409 （conflict）- 通用冲突
500 （internal server error）- 通用错误响应503 （Service Unavailable）- 服务端当前无法处理请求
- 用客户端管理的实例号创建一个资源
- 通过替换的方式更新资源
- 如果未被修改，则更新资源（乐观锁）
200 （OK）- 如果已存在资源被更改201 （created）- 如果新资源被创建
301（Moved Permanently）- 资源的URI已更改
303 （See Other）- 其他（如，负载均衡）
400 （bad request）- 指代坏请求
404 （not found）- 资源不存在
406 （not acceptable）- 服务端不支持所需表示/p&
409 （conflict）- 通用冲突
412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）
415 （unsupported media type）- 接受到的表示不受支持
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务当前无法处理请求
- 使用服务端管理的（自动产生）的实例号创建资源
- 创建子资源
- 部分更新资源
- 如果没有被修改，则不过更新资源（乐观锁）
200（OK）- 如果现有资源已被更改201（created）- 如果新资源被创建202（accepted）- 已接受处理请求但尚未完成（异步处理）
301（Moved Permanently）- 资源的URI被更新303（See Other）- 其他（如，负载均衡）
400（bad request）- 指代坏请求404 （not found）- 资源不存在406 （not acceptable）- 服务端不支持所需表示409 （conflict）- 通用冲突412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）415 （unsupported media type）- 接受到的表示不受支持
500 （internal server error）- 通用错误响应503 （Service Unavailable）- 服务当前无法处理请求
表1：统一接口示例
对资源的操纵永远是通过其表示实现的。资源可能永远不会在网络中传输，相反，传输的是资源的表示。资源的表示包括数据和描述数据的元数据，例如，HTTP头“Content-Type” 就是这样一个元数据属性。
图3展示了如何使用Java获取表示。该例程使用了Java HTTP库xLightweb中的HttpClient类，这个库由作者本人维护。
HttpClient httpClient = new HttpClient();
IHttpRequest request = new GetRequest(centralHotelURI);
IHttpResponse response = httpClient.call(request);
图3：获取表示的Java例程
通过调用HTTP客户端的call方法，一个访问Hotel资源表示的HTTP请求就被发送出去。返回的表示如图4所示，它也包含了用于指示实体主体的多媒体类型的Content-Type头。
GET /hotel/656bcee2-28d2-404b-891b HTTP/1.1
Host: localhost
User-Agent: xLightweb/2.6
HTTP/1.1 200 OK
Server: xLightweb/2.6
Content-Length: 277
Content-Type: application/x-www-form-urlencoded
classification=Comfort&name=Central&RoomURI=http%3A%2F%2Flocalhost%2Fhotel%2F
656bcee2-28d2-404b-891b%2FRoom%2F2&RoomURI=http%3A%2F%2Flocalhost%2Fhotel%2F6
56bcee2-28d2-404b-891b%2FRoom%2F1
图4：RESTful HTTP交互
如何支持特定表示？
为了避免传输很大的数据集，有时应该接收表示属性一个子集。在实现时，用于指定部分属性的一种方式就是支持对指定属性的寻址，如图5所示。
GET /hotel/656bcee2-28d2-404b-891b/classification HTTP/1.1
Host: localhost
User-Agent: xLightweb/2.6
Accept: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: xLightweb/2.6
Content-Length: 26
Content-Type: application/x-www-form- charset=utf-8
classification=Comfort
图5：属性过滤
图5中所示的GET调用只请求了一个属性（classification），如果要请求多个属性，所请求的属性要用逗号隔开，如图6所示。
GET /hotel/656bcee2-28d2-404b-891b/classification,name HTTP/1.1
Host: localhost
User-Agent: xLightweb/2.6
Accept: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: xLightweb/2.6
Content-Length: 43
Content-Type: application/x-www-form- charset=utf-8
classification=Comfort&name=Central
图6：多属性过滤
确定所需属性的另一种方法是使用查询参数，通过它列出所请求的属性，如图7所示。查询参数将用于定义查询条件以及更复杂的过滤或查询准则。
GET /hotel/656bcee2-28d2-404b-891b?reqAttr=classification&reqAttr=name HTTP/1.1
Host: localhost
User-Agent: xLightweb/2.6
Accept: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: xLightweb/2.6
Content-Length: 43
Content-Type: application/x-www-form- charset=utf-8
classification=Comfort&name=Central
图7：查询字符串
在上述例子中，服务器总是返回以application/x-www-form-urlencoded编码的媒体类型的表示。该媒体类型将实体编码成键值对列表。键值方法理解起来很容易，但缺点是，它不适用与更加复杂的数据结构。此外，这种媒体类型不支持标量数据类型的绑定，如Integer，Boolean，Date等。基于这个原因，通常使用XML，JSON或Atom来表征资源（JSON也没有定义Data类型的绑定）
HttpClient httpClient = new HttpClient();
IHttpRequest request = new GetRequest(centralHotelURI);
request.setHeader("Accept", "application/json");
IHttpResponse response = httpClient.call(request);
String jsonString = response.getBlockingBody().readString();
JSONObject jsonObject = (JSONObject) JSONSerializer.toJSON(jsonString);
HotelHotel= (Hotel) JSONObject.toBean(jsonObject, Hotel.class);
图8：请求JSON表示
通过设置“Accept”请求头，客户端就可以请求指定的表示编码。图8展示了如何对application/json类型的表示的请求。JSONlib将把图9中显示的返回响应消息映射成Hotel bean。
GET /hotel/656bcee2-28d2-404b-891b HTTP/1.1
Host: localhost
User-Agent: xLightweb/2.6
Accept: application/json
HTTP/1.1 200 OK
Server: xLightweb/2.6
Content-Length: 263
Content-Type: application/ charset=utf-8
{"classification":"Comfort",
"name":"Central",
"RoomURI":["http://localhost/hotel/656bcee2-28d2-404b-891b/Room/1",
"http://localhost/hotel/656bcee2-28d2-404b-891b/Room/2"]}
图9：JSON表示
如何报告错误？
当服务器不支持所请求的表示时怎么办？图10展示了一个请求XML表示资源的HTTP交互，若服务器不支持这种表示，它将返回一个HTTP 406响应，表示拒绝处理该请求。
GET /hotel/656bcee2-28d2-404b-891b HTTP/1.1
Host: localhost
User-Agent: xLightweb/2.6
Accept: text/xml
HTTP/1.1 406 No match for accept header
Server: xLightweb/2.6
Content-Length: 1468
Content-Type: text/ charset=iso-8859-1
&meta http-equiv="Content-Type" content="text/ charset=ISO-8859-1"/&
&title&Error 406 No match for accept header&/title&
&h2&HTTP ERROR: 406&/h2&&pre&No match for accept header&/pre&
图10：不支持的表示
RESTful HTTP服务端程序必须根据HTTP规范返回状态码。状态码的第一个数字标识返回类型，1xx表示临时响应，2xx表示成功响应 ，3xx代表转发，4xx表示客户端错误，5xx代表服务端错误。使用错误的响应码，或者总返回200响应，并在消息主体中包含特定应用程序的响应，这两种做法都是不好的实践。
客户代理和中介也要分析返回码。例如，xLightweb HttpClient默认会把持久的HTTP连接保存在连接池中，当一个HTTP交互完成时，持久化HTTP连接就应返回到内部连接池已备重用。而只有完好的连接才能被放回连接池，比如，若返回码是5xx，那该连接就不会重回连接池了。
有时某些特定的客户端要求更简洁的返回码。一种方法是增加一个HTTP头“X-Header”，用它来详细描述HTTP状态码。
POST /Guest/ HTTP/1.1
Host: localhost
User-Agent: xLightweb/2.6
Content-Length: 94
Content-Type: application/x-www-form-urlencoded
zip=30314&lastName=Gump&street=42+Plantation+Street&firstName=Forest&country=US&
city=Baytown&state=LA
HTTP/1.1 400 Bad Request
Server: xLightweb/2.6
Content-Length: 55
Content-Type: text/ charset=utf-8
X-Enhanced-Status: BAD_ADDR_ZIP
AddressException: bad zip code 99566
图11：附加状态码
通常只有在进行编程问题诊断时才需要详细的错误码。尽管比起详细的错误码，HTTP状态码的描述性总是要差很多，但是在大多数情况下，它们对于客户端正确处理问题已经足够了。另一种方法是在响应主体中包含详细的错误码。
PUT还是POST？
较之流行的RPC方式，HTTP方法不仅仅在方法名上有所不同，而且HTTP方法中的某些属性（如幂等性，安全性等）也扮演着重要的角色。不同的HTTP方法的幂等性和安全性属性也是不同的。
HttpClient httpClient = new HttpClient();
String[] params = new String[] { "firstName=Forest",
"lastName=Gump",
"street=42 Plantation Street",
"zip=30314",
"city=Baytown",
"state=LA",
"country=US"};
IHttpRequest request = new PutRequest(gumpURI, params);
IHttpResponse response = httpClient.call(request);
图12：使用PUT方法
如图12和13所示，使用PUT操作来创建一个新的Guest资源。PUT方法将封装好的资源存放在Request-URI之下。该URI是由客户端决定的，当Request-URI指向某现存资源时，该资源将被新资源替换。基于该原因，PUT方法一般用于创建新资源或更新现有资源。然而，通过使用PUT，资源的整个状态都会被改变，若一个请求只需要修改zip域，它不得不包含该资源的其他域，如 firstName，city等。
PUT Hotel/guest/bc45-9aa3-3f22d HTTP/1.1
Host: localhost
User-Agent: xLightweb/2.6
Content-Length: 94
Content-Type: application/x-www-form-urlencoded
zip=30314&lastName=Gump&street=42+Plantation+Street&firstName=Forest&country=US&
city=Baytown&state=LA
HTTP/1.1 200 OK
Server: xLightweb/2.6
Content-Length: 36
Content-Type: text/ charset=utf-8
Location: http://localhost/guest/bc45-9aa3-3f22d
The guest resource has been updated.
图13：HTTP PUT交互
PUT方法是幂等的，幂等性意味着对于一个成功执行的请求，不管其执行多少次，其结果都是一致的。也就是说，只要你愿意，你可以用PUT方法对Hotel资源进行任意次更新，其结果都一样。如果两个PUT方法同时发生，那么只有其中之一会赢得最后的胜利并决定资源的最终状态。删除操作也是幂等的，如果一个PUT方法和DELETE方法同时发生，那么资源或者被更新，或者被删除，而不可能停留在某个中间状态。
如果你不确定是PUT还是DELETE被成功执行，并且没有得到状态码409 (Conflict)或者 417 (Expectation Failed)的话，那么就重新执行一遍。而不需要附加的可靠性协议来避免重复请求，因为通常重复的请求不会有任何影响。
上述描述对于POST方法就不适用了，因为POST方法不是幂等的，若要两次执行同一个POST请求那就要注意了。POST方法所缺失的幂等性就解释了为什么当你每次重新发送POST请求时浏览器总是弹出警告。POST方法用于创建资源，而不需要由客户端指定实例id，图14展示了通过POST方法创建一个Hotel资源的HTTP交互过程。通常，客户端使用只包含基路径和资源类型名的URI来发送POST请求。
POST /HotelHTTP/1.1
Host: localhost
User-Agent: xLightweb/2.6
Content-Length: 35
Content-Type: application/x-www-form- charset=utf-8
Accept: text/plain
classification=Comfort&name=Central
HTTP/1.1 201 Created
Server: xLightweb/2.6
Content-Length: 40
Content-Type: text/ charset=utf-8
Location: http://localhost/hotel/656bcee2-28d2-404b-891b
the Hotelresource has been created
图14：HTTP POST交互（创建）
POST方法也经常用于更新资源的部分内容，比如，如果我们要通过发送仅包含classification属性的PUT请求去更新Hotel资源的话，这就是违反HTTP的，但是用POST方法则没有问题。POST方法既不是幂等的，也不是安全的。图15展示了一个执行部分更新的POST方法。
POST /hotel/0ae526f0-9c3d HTTP/1.1
Host: localhost
User-Agent: xLightweb/2.6
Content-Length: 19
Content-Type: application/x-www-form- charset=utf-8
Accept: text/plain
classification=First+Class
HTTP/1.1 200 OK
Server: xLightweb/2.6
Content-Length: 52
Content-Type: text/ charset=utf-8
the Hotelresource has been updated (classification)
图15： HTTP POST交互 （更新）
还可以使用PATCH方法来进行部分更新，PATCH方法是对资源进行部分更新的一个特殊方法。一个PATCH请求包含一个补丁文档，它将应用于由Request-URI所指定的资源。然而PATCH的RFC规范还在草稿中。
使用HTTP缓存
为提高扩展性并降低服务端负载， RESTful的HTTP应用程序可以利用WEB基础设施的缓存机制。HTTP已经意识到缓存是WEB基础设施必不可少的一部分，比如，HTTP协议定义了专门的消息头来支持缓存。如果服务端设置了这个头，客户端（如HTTP客户端或Web缓存代理）就能够有效地支持缓存策略。
HttpClient httpClient = new HttpClient();
httpClient.setCacheMaxSizeKB(500000);
IHttpRequest request = new GetRequest(centralHotelURI + "/classification");
request.setHeader("Accept", "text/plain");
IHttpResponse response = httpClient.call(request);
String classification = response.getBlockingBody.readString();
// ... sometime later re-execute the request
response = httpClient.call(request);
classification = response.getBlockingBody.readString();
图16：客户端缓存交互
图16显示了一个重复的GET调用。通过设置最大缓存大小的值&0激活了HttpClient的缓存功能。如果响应消息中包含了刷新头，比如Expires或Cache-Control: max-age，该响应就会被HttpClient缓存。这些头指明了关联的表示可以保鲜的时间为多久。如果在一段时间内发出了相同的请求，那么HttpClient就会使用缓存为这些请求提供服务，而不需要重复进行网络调用。在网络上总共只有一次HTTP交互，如图17所示。诸如WEB代理之类的缓存中介也实现了相同的功能，而且该缓存还可以在不同客户端之间共享。
GET /hotel/656bcee2-28d2-404b-891b/classification HTTP/1.1
Host: localhost
User-Agent: xLightweb/2.6
Accept: text/plain
HTTP/1.1 200 OK
Server: xLightweb/2.6
Cache-Control: public, max-age=60
Content-Length: 26
Content-Type: text/ charset=utf-8
图17：包含过期头的HTTP响应
过期模型在静态资源上很好用，可是，对于动态资源（资源状态经常改变且无法预测）则不尽相同。HTTP通过验证头，如Last-Modified以及ETag来支持动态资源的缓存。与过期模型相比，验证模型没有节省网络调用。但是，当执行带条件的GET方法时它会对昂贵的操作节约网络传输，图 18（2.request）显示了带条件的GET操作，它带有一个额外的Last-Modified头，这个头包含了缓存对象最后修改日期。如果该资源未被更改，服务端将会返回一个304 (Not Modified) 响应。
1. REQUEST:
GET /hotel/656bcee2-28d2-404b-891b/Reservation/1 HTTP/1.1
Host: localhost
User-Agent: xLightweb/2.6
Accept: application/x-www-form-urlencoded
1. RESPONSE:
HTTP/1.1 200 OK
Server: xLightweb/2.6
Content-Length: 252
Content-Type: application/x-www-form-urlencoded
Last-Modified: Mon, 01 Jun :18 GMT
from=T09%3A49%3A09.718&to=T09%3A49%3A09.718&guestURI=
http%3A%2F%2Flocalhost%2Fguest%2Fbc45-9aa3-3f22d&RoomURI=http%3A%2F%2F
localhost%2Fhotel%2F656bcee2-28d2-404b-891b%2FRoom%2F1
2. REQUEST:
GET /hotel/0ae526f0-9c3d/Reservation/1 HTTP/1.1
Host: localhost
User-Agent: xLightweb/2.6
Accept: application/x-www-form-urlencoded
If-Modified-Since: Mon, 01 Jun :18 GMT
2. RESPONSE:
HTTP/1.1 304 Not Modified
Server: xLightweb/2.6
Last-Modified: Mon, 01 Jun :18 GMT
图18：基于验证的缓存
不要在服务端存储应用状态
RESTful HTTP的交互必须是无状态的，这表明每一次请求要包含处理该请求所需的一切信息。客户端负责维护应用状态。RESTful服务端不需要在请求间保留应用状态，服务端负责维护资源状态而不是应用状态。服务端和中介能够理解独立的请求和响应。Web缓存代理拥有一切正确处理请求所需的信息并管理它的缓存。
这种无状态的方法是实现高扩展和高可用应用的基本原则。通常无状态使得每一个客户请求可以由不同的服务器来响应，当流量增加时，新的服务器可以加进来，而如果某个服务器失败，它也可以从集群中移除。若要了解关于负载均衡以及故障恢复方面的更详细信息，请参考这篇文章。
对non-CRED操作的支持
开发者经常想了解如何将non-CRUD（Create-Read-Update-Delete）操作映射到资源。显然，Create、Read、Update和Delete等操作能够很容易地映射到资源的方法。然而， RESTful HTTP还不仅限于面向CRUD的应用。
图19: RESTful HTTP资源
就如图19所示的creditScoreCheck而言，它提供了一个non-CRUD操作creditScore(...)，该操作接受一个address，计算出score并返回。这样的操作可以通过CreditScoreResource实现，该资源代表着计算的返回。图20展示了一个GET方法，它传入address，然后提取CreditScoreResource表示，查询参数被用来指定CreditScoreResource。GET方法是安全的，并且可缓存，所提它很适用于CreditScore Check的creditScore(...)方法的非功能性行为。计算的结果可以缓存一段时间，如图20所示，响应包含了一个缓存头，它通知客户端和中介执行响应缓存。
GET /CreditScore/?zip=30314&lastName=Gump&street=42+Plantation+Street&
firstName=Forest&country=US&city=Baytown&state=LA HTTP/1.1
Host: localhost
User-Agent: xLightweb/2.6
Accept: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: xLightweb/2.6
Content-Length: 31
Content-Type: application/x-www-form-urlencoded
Cache-Control: public, no-transform, max-age=300
scorecard=Excellent&points=92
图20：Non-CRUD HTTP GET交互
上述例子还显示了GET方法的局限性。尽管HTTP规范并没有指定URL的最大长度，但是实际上客户端，中介以及服务端对URL的长度都有限制。基于此，通过GET的查询参数发送一个很大的实体可能会因为中介和服务器对URL长度的限制而失败。
另一解决方法是使用POST方法，如果作了设置，它也是可缓存的。如图21所示，第一个POST请求的结果是创建了一个虚拟资源CreditScoreResource。输入的address数据用text/card这个mime类型进行编码，在服务端计算得到score之后，它发回一个201（created）响应，该响应包含着所创建的CreditScoreResource资源的URI。 示例中还展示了如果进行了设定，POST响应也可以被缓存。通过一个GET请求就能够取到计算结果。GET响应也包含一个缓存控制头，如果客户端紧接着重新执行这两次请求，那么它们都可由缓存进行响应。
1. REQUEST:
POST /CreditScore/ HTTP/1.1
Host: localhost
User-Agent: xLightweb/2.6
Content-Length: 198
Content-Type: text/x-vcard
Accept: application/x-www-form-urlencoded
BEGIN:VCARD
VERSION:2.1
FN:Forest Gump
ADR;HOME:;;42 Plantation St.;BLA;30314;US
LABEL;HOME;ENCODING=QUOTED-PRINTABLE:42 Plantation St.=0D=0A30314 Baytown=0D=0ALA US
1. RESPONSE:
HTTP/1.1 201 Created
Server: xLightweb/2.6
Cache-Control: public, no-transform, max-age=300
Content-Length: 40
Content-Type: text/ charset=utf-8
Location: http://localhost/CreditScore/l00005c
the credit score resource has been created
2. REQUEST:
GET /CreditScore/l00005c HTTP/1.1
Host: localhost
User-Agent: xLightweb/2.6
2. RESPONSE:
HTTP/1.1 200 OK
Server: xLightweb/2.6
Content-Length: 31
Content-Type: application/x-www-form-urlencoded
Cache-Control: public, no-transform, max-age=300
scorecard=Excellent&points=92
图21： Non-CRUD HTTP POST交互
还有其他不同的实现方式。比如不返回201响应，而返回301(Moved Permanently)转发响应。该响应缺省是可缓存的。其他避免二次请求的方法是在201响应中增加一个新创建的CreditScoreResource资源的表示。
大多数SOA架构（如SOAP或CORBA）都试图映射如图1所示的类模型，或多或少是一对一的远程访问。通常，这些SOA架构的比较多地关注在编程语言对象的透明映射上，这种映射很容易理解，且易于跟踪。可是，它们把对分布性和扩展性等方面的关注排在第二位。
相反，REST架构风格的最主要驱动是分布性和扩展性。RESTful HTTP接口的设计是由网络因素而非编程语言的绑定驱动的。 RESTful HTTP也没有试图去封装很那些难隐藏的因素，如网络延迟，网络健壮性以及网络带宽等。
RESTful HTTP应用用一种直接的方式使用HTTP协议，而不需任何抽象层，也不存在REST指定的数据域，如错误域，安全令牌域等。RESTful HTTP应用只使用WEB的固有能力。设计RESTful HTTP的接口意味着远程结构的设计者必须在HTTP协议上进行思考。这通常增加了开发周期中额外步骤。
然而，RESTful HTTP使得应用程序实现具有高扩展性，更健壮。特别是为很大用户群提供Web应用的公司，如 WebMailing或SocialNetworking的应用就能从REST架构风格中获益。通常，这些应用要更快更高地扩展，而且，这些公司通常在一些低预算的基础设施（基于广泛使用的标准组件和软件之上）上运行应用。
Gregor Roth，xLightweb HTTP库的作者。在United Internet组织担任软件架构师，该组织是最重要的欧洲因特网服务提供商，其产品有GMX, 1&1, and Web.de等。他感兴趣的领域包括软件和系统架构、企业架构管理、面向对象设计、分布式计算和开发方法论等。
zhanshenny
浏览: 131004 次
来自: 北京
请问，这段代码哪里用到了Memcache,整个验证用cooki ...
alfresco简体中文汉化包：
http://www.inn ...
http://www.oschina.net/question ...