RESTful架构详解

1.什么是REST

REST全称是Representantional State Transfer，中文译为表述（表征）性状态转移。“REST指的是一组架构约束条件和原则。”若是一个架构符合REST的约束条件和原则，就称其为RESTful架构。

2.理解RESTful

理解RESTful架构，须要理解epresentational State Transfer这个词组究竟是什么意思，它的每个词都有些什么涵义。下面结合REST原则，围绕资源展开讨论，从资源的定义、获取、表述、关联、状态变迁等角度，列举一些关键概念并加以解释。
2.1资源与URI
REST全称表述性状态转移，到底是的是什么的表述？其实指的就是资源。任何事物，只要有被引用的必要，它就是一个资源。资源能够是实体（如手机号），也能够是一个抽象概念（如价值）。
要让一个资源能够被识别，须要有个惟一标识，在Web中这个惟一标识就是URI（Uniform Resource Identifier）。URI能够当作是资源的地址，也能够当作资源的名称。如某些信息没有使用URI来表示，就不算是一个资源，只能算是资源的一些信息而已。URI的设计应遵循可寻址性原则，具备自描述性，须要在形式上给人以直觉上的关联。
URI设计技巧：
使用_或-来让URI可读性更好
使用/来表示资源的层级关系
使用？来过滤资源
，或；能够用来表示同级资源关系
2.2统一资源接口
RESTful架构应该遵循统一接口原则，统一接口包含一组受限的预约义操做，不论什么样的资源，都是经过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GET，PUT和POST，并遵循这些方法的语义。
若是按照HTTP方法的语义来暴露资源，那么接口将会拥有安全性和幂等性的特性。
GET
安全且幂等
获取表示
变动时获取表示（缓存）
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）- 服务端当前没法处理请求
POST
不安全且不幂等
使用服务端管理的（自动产生）实例号建立资源
建立子资源
部分更新资源
如没有被修改，则不更新资源（乐观锁）
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）- 服务当前没法处理请求
PUT
不安全但幂等
用客户端管理的实例号建立一个资源
经过替换的方式更新资源
如未被修改，则更新资源（乐观锁）
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）- 服务当前没法处理请求
DELETE
不安全但幂等
删除资源
200 （OK）- 资源已被删除
301 （Moved Permanently）- 资源的URI已更改
303 （See Other）- 其余，如负载均衡
400 （bad request）- 指代坏请求
404 （not found）- 资源不存在
409 （conflict）- 通用冲突
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务端当前没法处理请求
实践中常见问题：
统一资源接口对URI有什么指导意义?
统一资源接口要求使用标准的HTTP方法对资源进行操做，因此URI只应该来表示资源的名称，而不该该包括资源的操做。通俗来讲，URI不该该使用动做来描述。
若是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" 就是这样一个元数据属性。
实践上常见设计：
再URI里面带上版本号
使用URI后缀区分表述格式
如何处理不支持的表述格式：返回一个HTTP406响应，表示处理该请求。
2.4资源的连接
咱们知道REST是使用标准的HTTP方法来操做资源的，但仅仅所以就理解成带CURD的Web数据库架构就太过于简单了。 这种反模式忽略了一个核心概念：“超媒体即应用状态引擎（hypermedia as the engine of application state）”。 超媒体是什么? 当你浏览Web网页时，从一个链接跳到一个页面，再从另外一个链接跳到另一个页面，就是利用了超媒体的概念：把一个个资源连接起来。要达到这个目的，就要求在表述格式里边加入连接来引导客户端。在《RESTful Web Services》一书中，做者把这种具备连接的特性成为连通性。
2.5状态转移
咱们先来讨论一下REST原则中的无状态通讯原则。初看一下，好像自相矛盾了，既然无状态，何来状态转移一说? 其实，这里说的无状态通讯原则，并非说客户端应用不能有状态，而是指服务端不该该保存客户端状态。
2.5.1应用状态与资源状态
实际上，状态应该区分应用状态和资源状态，客户端负责维护应用状态，而服务端维护资源状态。
客户端与服务端的交互必须是无状态的，并在每一次请求中包含处理该请求所需的一切信息。
服务端不须要在请求间保留应用状态，只有在接受到实际请求的时候，服务端才会关注应用状态。
这种无状态通讯原则，使得服务端和中介可以理解独立的请求和响应。
在屡次请求中，同一客户端也再也不须要依赖于同一服务器，方便实现高可扩展和高可用性的服务端。
但有时候咱们会作出违反无状态通讯原则的设计，例如利用Cookie跟踪某个服务端会话状态，常见的像J2EE里边的JSESSIONID。
这意味着，浏览器随各次请求发出去的Cookie是被用于构建会话状态的。
固然，若是Cookie保存的是一些服务器不依赖于会话状态便可验证的信息（好比认证令牌），这样的Cookie也是符合REST原则的。
2.5.2应用状态的转移
状态转移到这里已经很好理解了， "会话"状态不是做为资源状态保存在服务端的，而是被客户端做为应用状态进行跟踪的。客户端应用状态在服务端提供的超媒体的指引下发生变迁。服务端经过超媒体告诉客户端当前状态有哪些后续状态能够进入。 这些相似"下一页"之类的连接起的就是这种推动状态的做用——指引你如何从当前状态进入下一个可能的状态。
3总结
如今广东XXX版本、XXX等项目中均使用传统的RPC、SOAP方式的Web服务，而移动南方基地XXXX项目的后台， 虽然采用了JSON格式进行交互，但仍是属于RPC风格的。本文从资源的定义、获取、表述、关联、状态变迁等角度， 试图快速理解RESTful架构背后的概念。RESTful架构与传统的RPC、SOAP等方式在理念上有很大的不一样，但愿本文能对各位理解REST有所帮助。