[ 转 ] 最通俗的 RESTful 介绍

一、什么是RESTful

定义：

　　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。

约束

要让应用RESTful化，需要遵循以下约束。遵循了这些约束的分布式系统，就会拥有如下非功能属性：性能，伸缩性，易用性，扩展性，可见性，可移植性和可靠性。

CS模式

CS模式通过分离客户端和服务器端的关注点，让客户端不再关注数据的存储问题，从而提高客户端代码的可移植性。另一方面，服务器端不再关注用户界面和用户状态，从而变得更简单，提高了伸缩性。服务器端跟客户端可以独立开发，只要它们都遵守契约。

无状态

客户端上下文在多个请求之间是绝不会保存在服务器上的。每个请求必须包含必要的信息。无状态的服务器通过快速释放资源和简化实现提高了可伸缩性。可靠性使得从局部失败中恢复变得容易。很明显，监控系统不必通过考虑单个请求来判断请求的性质。

无状态服务器的一个缺点是降低了网络性能，因为所有需要的数据必须在每次请求中发送。

可缓存

REST应用程序是web系统，因此客户端和中间层可以缓存响应。响应必须被定义为可缓存或不可缓存的，以防客户端重复使用旧数据导致降低可靠性。如果缓存中的陈旧数据与已生成的请求的数据显著不同，则由服务器处理请求。缓存可以消除一些客户端和服务器之间的交互，这就提升了可伸缩性、效率和通过减少平均延迟达到的用户可感知的性能。

 

二、理解RESTful

　　要理解RESTful架构，需要理解Representational State Transfer这个词组到底是什么意思。

　　我们结合REST原则，围绕资源展开讨论，从资源的定义、获取、表述、关联、状态变迁等角度，进行解释。

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

资源与URI：

　　REST全程是表述性状态转移，那么是什么样的表述？其实指的就是资源。任何事物，只要有被引用到的必要，它就是一个资源。资源可以是实体，也可以是一个抽象概念。比如：

　　　　某用户的手机号码

　　　　某用户的个人信息

　　　　最多用户订购的GPRS套餐

　　　　两个产品之间的依赖关系

　　　　某用户可以办理的优惠套餐

　　　　某手机号码的存在价值

　　要让一个资源可以被识别，需要有一个唯一标识。在Web中唯一标识就是URL（Uniform Resource Identifier）

　　URI可以看成是资源的地址，也可以看成是资源的名称。如果某些信息没有使用URI来表示，那它就不能算是一个资源，只能算是资源的一些信息而已。URI的设计应该遵循可寻址性原则，具有自描述性，需要在形式上给人以直觉上的关联。例如：

https://github.com/git
https://github.com/git/git
https://github.com/git/git/blob/master/block-sha1/sha1.h
https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08
https://github.com/git/git/pulls
https://github.com/git/git/pulls?state=closed
https://github.com/git/git/compare/master…next

 

　　看一些URI设计上的技巧：

　　1、使用 - 或 _来让URI可读性更好

　　　　曾经Web上的URI都是冰冷的数字或者无意义的字符串。但现在越来越多的网站使用 _或 - 来分隔一些单词，让URI看上去更为人性化。例如：

http://www.oschina.net/news/38119/oschina-translate-reward-plan

　　2、使用 / 来标识资源的层级关系

　　　　例如上述 /git/git/commit/e3jfae... 就表示了一个多级的资源，指的是git用户的git项目的某次提交记录。又例如/orders/2012/10可以用来表示2012年10月的订单记录。

　　3、使用 ？ 来过滤资源

　　　　很多人只是把?简单的当做是参数的传递，很容易造成URI过于复杂、难以理解。可以把?用于对资源的过滤， 例如/git/git/pulls用来表示git项目的所有推入请求，而/pulls?state=closed用来表示git项目中已经关闭的推入请求， 这种URL通常对应的是一些特定条件的查询结果或算法运算结果。

　　4、 ，或 ；可以用来表示同级资源的关系

　　　　有时候我们需要表示同级的资源时。可以使用 ，或；来进行分割。

 

　　统一资源接口：

　　RESTful架构应遵循统一接口原则，统一接口包含了一组受限的预定义的操作，不论什么样的资源，都是使用相同的接口进行资源的访问。

　　接口应该使用标准的HTTP方法，如GET，PUT和POST，并遵循这些方法的语义。

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

　　1、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）- 服务端当前无法处理请求

　　2、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）- 服务当前无法处理请求

　　3、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）- 服务当前无法处理请求

　　4、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）- 服务端当前无法处理请求

 

　　实践中常见的问题：

　　　　POST和PUT用于创建资源时有什么区别？

　　　　POST和PUT在创建资源的区别在于，所创建的资源的名称(URI)是否由客户端决定。例如为我的博文增加一个java的分类，生成的路径就是分类名 /categories/java ，那么就可以采用PUT方法。

　　　　客户端不一定都支持这些HTTP方法吧？

　　　　对于一些古老的基于浏览器的客户端只能使用GET和POST两种方法

　　　　统一接口是否意味着不能扩展带特殊语义的方法？

　　　　统一接口并不阻止你扩展方法，只要方法对资源的操作有着具体的、可识别的语义即可，并能保持整个接口的统一性。

　　　　统一资源接口对URI有什么指导意义？

　　　　统一资源接口要求使用标准的HTTP方法对资源进行操作，所以URI只应该来表示资源的名称，而不应该包括资源的操作。通俗来说，URI不应该使用动作来描述。例如，下面是一些不符合统一接口要求的URI:

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

　　资源的表述

　　　上面提到，客户端通过HTTP方法可以获取资源吧。不，确切的说客户端获取的知识资源的表述。资源在外界的具体呈现，可以有多种表述（或成表现、表示）形式，在客户端和服务端之间传送的也是资源的表述，而不是资源本身。

　　　　资源的表述包括数据和描述数据的元数据，例如HTTP头“Content-Type”就是这样一个元数据属性。那么客户端如何知道服务器端提供那种表述形式呢？

　　　答案是通过HTTP内容协商，客户端可以通过Accept头请求一种特定格式的表述，服务端通过Content-Type告诉客户端资源的表述形式

　　　　例如：请求某组织资源的json格式的表达式
　　　　

　　　　使用XML请求资源：

　　　　

 

　　实践上常见的设计：

　　1、在URI里面带上版本号

　　例如：

http://api.example.com/1.0/foo
http://api.example.com/1.2/foo
http://api.example.com/2.0/foo

　　如果我们版本号理解成资源的不同表述形式的话，就应该只用一个URL，并同Accept头部来区分，以GitHub为例，它的Accept的完整格式是：

application/vnd.github[.version].param[+json]

　　对于V3版本的话，就是Accept：application/vnd.github.v3。所以同理可以使用下面头部：

Accept: vnd.example-com.foo+json; version=1.0
Accept: vnd.example-com.foo+json; version=1.2
Accept: vnd.example-com.foo+json; version=2.0

　　2、使用URI后缀来区分表述格式

　　使用/user.xml或/user.json来区分不同的格式。这样对于客户端来说更为直观，但混淆了资源的名称和资源的表述形式。

　　3、处理不支持的表述格式

　　当服务器不支持所请求的表述格式，它应该返回一个HTTP406响应，表示拒绝处理该请求。

　　

 

来源：菜鸟教程

　　　

posted @ 2018-03-22 17:43  1440min  阅读(431)  评论(0)  编辑  收藏  举报