RESTful基础详解

一、基础定义。

1.1 全称定义

REST全称是Representational State Transfer，中文为：表述性状态转移。

1.2 历史背景

它首次出现在 2000 年 Roy Fielding 的博士论文中，他是 HTTP 规范的主要编写者之一。他在论文中他这么设计的目的是，在符合架构原理的前提下，理解和评估以网络为基础的软件架构设计，得到一个功能好、性能好、事宜通信的架构。REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。

1.3 专业术语解释

1.3.1 资源与url

REST全称是表述性状态转移，其实就是资源。任何事物，只要有被引用到的必要，它就是一个资源。比如：一个人的身高、体重、肺活量（具体）；一个人的个性（抽象）。在我们看来这些都可以被称为资源。然而当我们利用网络进行查询的时候，就必须通过一个唯一表示来进行访问。这个唯一标识就是URL。URI既可以看成是资源的地址，也可以看成是资源的名称。例如：https://mp.csdn.net/postedit

1.3.2 统一资源接口

RESTful应该遵守同一资源接口原则。统一接口包含了一组，受限的预定义操作，不论什么样的资源，都是使用相同的接口，进行资源访问。接口应该使用标准的HTTP方法：get、pur和post。并遵循这些方法的语义。如果按照http的语义来进行暴露资源，那么接口就会拥有安全性和幂等性的特性。例如get和head方式都是安全的，无论请求多少次都不会改变服务器的状态。而get、head、pur和delete请求都是幂等性的。无论对资源操作多少次，结果都是一样的，后面的请求并不会产生比第一次更多的影响。

幂等性：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。举个最简单的例子，那就是支付，用户购买商品使用约支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额返发现多扣钱了，流水记录也变成了两条。这就不是幂等性。

1.3.3 资源的表述

客户端可以通过http方法获取资源，但确切的说，其实客户端只是获取的资源的表述。可以有多种表述(或成为表现、表示)形式，在客户端和服务端之间传送的也是资源的表述，而不是资源本身。例如文本资源可以采用html、xml、json等格式，图片可以使用PNG或JPG展现出来。

1.3.4 资源的链接

超媒体即应用状态引擎（hypermedia as the engine of application state）浏览Web网页时，从一个连接跳到一个页面，再从另一个连接跳到另外一个页面，就是利用了超媒体的概念：把一个个把资源链接起来。就要求在表述格式里边加入链接来引导客户端。很多人在设计RESTful架构时，使用很多时间来寻找漂亮的URI，而忽略了超媒体。所以，应该多花一些时间来给资源的表述提供链接，而不是专注于"资源的CRUD"。

1.3.5 状态的转移

无状态通信原则，并不是说客户端应用不能有状态，而是指服务端不应该保存客户端状态。

1.3.6 应用状态和资源状态

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

当然，如果Cookie保存的是一些服务器不依赖于会话状态即可验证的信息（比如认证令牌），这样的Cookie也是符合REST原则的。

1.4 简单定义

RESTful架构：

（1）每一个URI代表一种资源；

（2）客户端和服务器之间，传递这种资源的某种表现层；

（3）客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。

关于RESTful API设计指南：下面有一篇文章已经写的非常详细。

点击： RESTful API设计指南