RESTful 分享

RESTful 分享

1. 什么是RESTful

2. 理解RESTful

3. RESTful的使用

1.什么是RESTful

REST全称是Representational State Transfer，中文译文就是“表述性状态转移”。

在2000年，由Roy Fielding（HTTP规范的主要编写者之一）在博士论文中提出的。

写作目的：想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。

REST本身并没有创造新的技术、组件或服务，REST指的是一组架构约束条件和原则。而隐藏在RESTful背后的理念就是使用Web的现有特征和能力， 更好地使用现有Web标准中的一些准则和约束。如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。

2.理解RESTful

要理解RESTful架构，需要理解Representational State Transfer这个词组到底是什么意思，它的每一个词都有些什么涵义。
结合REST原则，围绕资源展开讨论，从资源的定义、获取、表述、关联、状态变迁等角度，列举一些关键概念并加以解释。

• 资源与URI
• 统一资源接口
• 资源的表述
• 资源的链接
• 状态的转移

2.1 资源与URI

REST全称是表述性状态转移,其实指的就是资源的表述性。

任何事物，只要有被引用到的必要，它就是一个资源。
一些资源：

• 某用户的手机号码
• 两个产品之间的依赖关系
• 某用户的个人信息
• …
  要让一个资源可以被识别，需要有个唯一标识，在Web中这个唯一标识就是URI(Uniform Resource Identifier)。URI既可以看成是资源的地址，也可以看成是资源的名称.

URI的设计应该遵循可寻址性原则，具有自描述性，需要在形式上给人以直觉上的关联。

命名好的URI:

• https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08
• https://github.com/git/git/pulls
• https://github.com/git/git/compare/master…next

命名技巧：

• 使用_或-来让URI可读性更好
• 使用/来表示资源的层级关系
• 使用?用来过滤资源
• ,或;或…可以用来表示同级资源的关系

2.2 统一资源接口

RESTful架构应该遵循统一接口原则，统一接口包含了一组受限的预定义的操作，即不论什么样的资源，都是通过使用相同的接口进行资源的访问。接口使用标准的HTTP方法如GET，PUT和POST，并遵循这些方法的语义。按照HTTP方法的语义来暴露资源，那么接口将会拥有安全性和幂等性的特性。
GET:获取资源，安全且幂等
POST：创建资源（当使用服务端管理的（自动产生）的实例号），不安全且不幂等
PUT：创建资源（当用客户端管理的实例号），更新资源（通过替换的方式）
DELETE：删除资源，不安全但幂等

统一资源接口要求使用标准的HTTP方法对资源进行操作，所以URI只应该来表示资源的名称，而不应该包括资源的操作。

错误示例：

• GET /getUser/1
• POST /createUser
• PUT /updateUser/1
• DELETE /deleteUser/1

2. 3 资源的表述

客户端通过http方法获取的资源，更确切的说是资源的表述
资源的表述包括数据和描述数据的元数据，
例如，HTTP头"Content-Type" 就是这样一个元数据属性。服务端则通过Content-Type告诉客户端资源的表述形式（资源的格式是什么）。

2.4 资源的链接

当你浏览Web网页时，从一个连接跳到一个页面，再从另一个连接跳到另外一个页面，就是利用了超媒体的概念：把一个个把资源链接起来.
。在《RESTful Web Services》一书中，作者把这种具有链接的特性称为为连通性。

2.5 状态的转移

http协议是无状态的，服务器不记录客户端的状态（登录状态）。无状态通信原则，并不是说客户端应用不能有状态，而是指服务端不应该保存客户端状态。
应用状态与资源状态
状态应该区分应用状态和资源状态，客户端负责维护应用状态，而服务端维护资源状态。客户端与服务端的交互必须是无状态的，并在每一次请求中包含处理该请求所需的一切信息。
服务端不需要在请求间保留应用状态，只有在接受到实际请求的时候，服务端才会关注应用状态。