什么是resful

REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。他在论文中提到："我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。"如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。

理解RESTful

要理解RESTful架构，需要理解Representational StateTransfer这个词组到底是什么意思，它的每一个词都有些什么涵义。

下面我们结合REST原则，围绕资源展开讨论，从资源的定义、获取、表述、关联、状态变迁等角度，列举一些关键概念并加以解释。

• 资源与URI

• 统一资源界面

• 资源的表述

• 资源的链接

• 状态的转移

资源与URI

REST全称是表述性状态转移，那究竟指的是什么的表述?其实指的就是资源。任何事物，只要有被引用到的必要，它就是一个资源。资源可以是实体(例如手机号码)，也可以只是一个抽象概念(例如价值)。要让一个资源可以被识别，需要有个唯一标识，在Web中这个唯一标识就是URI(Uniform ResourceIdentifier)。URI既可以看成是资源的地址，也可以看成是资源的名称。例如：

http://localhost:8080/User?_method=get&id=1000　　可以通过get请求获取到数据库user 表里面 id=1000 的用户信息

http://localhost:8080/User?_method=post&id=1001&name=zhangsan　　可以向数据库user 表里面插入一条记录

http://localhost:8080/User?_method=put&id=1002&name=lisi　　可以将user表里面 id=1002 的用户名改为lisi

http://localhost:8080/User?_method=delete&id=1003　　用于将数据库user 表里面的id=1003 的信息删除

统一资源界面

RESTful架构应该遵循统一界面原则，统一界面包含了一组受限的预定义的操作，不论什么样的资源，都是通过使用相同的界面进行资源的访问。界面应该使用标准的HTTP方法如GET，PUT和POST，并遵循这些方法的语义。

如果按照HTTP方法的语义来暴露资源，那么界面将会拥有安全性和幂等性的特性，例如GET和HEAD请求都是安全的，无论请求多少次，都不会改变服务器状态。而GET、HEAD、PUT和DELETE请求都是幂等的，无论对资源操作多少次，结果总是一样的，后面的请求并不会产生比第一次更多的影响。

资源的表述

资源在外界的具体呈现，可以有多种表述(或成为表现、表示)形式，在客户端和服务端之间传送的也是资源的表述，而不是资源本身。例如文本资源可以采用html、xml、json等格式，图片可以使用PNG或JPG展现出来。

资源的表述包括数据和描述数据的元数据，例如，HTTP头"Content-Type" 就是这样一个元数据属性。

那么客户端如何知道服务端提供哪种表述形式呢，答案是可以通过HTTP内容协商，客户端可以通过Accept头请求一种特定格式的表述，服务端则通过Content-Type告诉客户端资源的表述形式。

这是某鱼tv，可以看出它支持htmlxhtml+xml

资源的链接

REST是使用标准的HTTP方法来操作资源的，但仅仅因此就理解成带CURD的Web数据库架构就太过于简单了。这种反模式忽略了一个核心概念："超媒体即应用状态引擎（hypermediaas the engine of application state）"。超媒体是什么?当你浏览Web网页时，从一个连接跳到一个页面，再从另一个连接跳到另外一个页面，就是利用了超媒体的概念：把一个个把资源链接起来。要达到这个目的，就要求在表述格式里边加入链接来引导客户端。在《RESTfulWeb Services》一书中，作者把这种具有链接的特性成为连通性。

状态的转移

实际上，状态应该区分应用状态和资源状态，客户端负责维护应用状态，而服务端维护资源状态。客户端与服务端的交互必须是无状态的，并在每一次请求中包含处理该请求所需的一切信息。服务端不需要在请求间保留应用状态，只有在接受到实际请求的时候，服务端才会关注应用状态。这种无状态通信原则，使得服务端和中介能够理解独立的请求和响应。在多次请求中，同一客户端也不再需要依赖于同一服务器，方便实现高可扩展和高可用性的服务端。但有时候我们会做出违反无状态通信原则的设计，例如利用Cookie跟踪某个服务端会话状态，常见的像J2EE里边的JSESSIONID。这意味着，浏览器随各次请求发出去的Cookie是被用于构建会话状态的。当然，如果Cookie保存的是一些服务器不依赖于会话状态即可验证的信息（比如认证令牌），这样的Cookie也是符合REST原则的。

状态转移到这里已经很好理解了，"会话"状态不是作为资源状态保存在服务端的，而是被客户端作为应用状态进行跟踪的。客户端应用状态在服务端提供的超媒体的指引下发生变迁。服务端通过超媒体告诉客户端当前状态有哪些后续状态可以进入。这些类似"下一页"之类的链接起的就是这种推进状态的作用--指引你如何从当前状态进入下一个可能的状态。

如果你觉得本文对您有一些帮助的话，点一波关注吧，老铁！