作为一名只有几个月IT自学经历的人，在接受新知识的时候总是想找到浅显易懂的方式去理解，但往往却很难找到相关的文章，大部分都是针对具有一定经验的开发人员，因此在看了很多相关的文章才对RESTful架构有所了解，接下来我将以简单的方式描述RESTful，方便一些初学者容易理解，也作为自己的一个总结学习过程。

RESTful简介

在谈 RESTful 之前让我们先了解下什么是 Web Service，之所以要提这个是因为 RESTful 本身就是属于 Web Service 范畴，web service 是一个 SOA（面向服务的编程）的架构，它是不依赖于语言，不依赖于平台，可以实现不同语言间的相互调用，通过 Internet 进行基于 HTTP 协议的网络应用间的交互。简单来说就是实现跨语言和跨平台的程序之间的通信。更多了解可以参考 Web Service是什么？——阮一峰。

RESTful 是2000年由 Roy Thomas Fielding 在他的博士论文中首次提出，Fielding 是 HTTP 协议的主要设计者、Apache 服务器软件作者之一，他认为他的目的是“在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通讯的架构”，最后他提出了 RESTful 架构。 RESTful（Representational State Transfer）不是协议，只是一种设计风格，而满足这种风格的应用程序或设计被认为是 RESTful 的。

什么是 RESTful？

REST 翻译成中文是“表现层状态转移”。接下来我们解释下什么是“表现层状态转移”，首先我们引入“资源”这一概念，资源也是 REST 的核心概念，在 REST 中可以认为一切皆资源。所谓资源是指网络上的某一个实体，这个实体可以是文件、图片、视频、音频，这类资源比较具体，容易呈现和理解；也可以是一种特定的服务（比如银行转账），这种资源比较抽象。在网络上每一个资源都有一个唯一标识，就是所谓的 URI（Uniform Resource Identifier，统一资源标识符），在设计时只要保证每个资源有自己唯一的 URI，当我们想访问资源时可以通过访问相应的 URI 获得该资源。例如，在浏览器中访问 http://test.com/content/1.txt，就是通过 UR I直接获得 1.txt 这个文本文件。因此对网络的访问可以抽象成对资源的“访问”，也就是调用资源对应的 URI。

　　现在我们来理解“表现层状态转移”，表现层（Representation）是资源的一种表现方式。例如，同样一段文字可以使用纯文本展示，也可以使用 HTML、XML 和 JSON 来表示，无论什么样的表现形式，最后表示的内容都是相同的。同样，相同的一张图片，可以使 BMP 格式，也可以是 JPG 格式，还可以是 PNG 格式。在通信过程中我们会将具体的表现形式（也就是格式信息）写在HTTP请求头和响应头的 Accept 和 Content-Type 中。

　　对资源的访问，肯定牵涉到对资源的“修改”，而在 REST 中，将修改资源抽象成资源的“状态转移”。理论上 REST 架构风格并非绑定在HTTP协议上，但目前 HTTP 是与 REST 唯一相关的实例，HTTP 协议是无状态的，其所有的状态都保存在服务器端，所以 REST 的核心就是使用某种方式完成资源的状态转移，而这种转移则是基于资源的表现层的，通常我们会用HTTP的方法来实现，常用的方法有 GET、POST、PUT 和 DELETE，正好对应数据库中的 CURD 操作。这几种方法具体的含义如下：

　　（1）GET：获取资源。该方法是获取资源的某种表现层，对应数据库中的查找。

　　（2）POST：投递资源，创建资源。该方法一般用来创建资源，对应数据库中的添加。

　　（3）PUT：更新资源。该方法和 POST 类似，不同之处在于 PUT 是用来更新已经存在的资源，对应数据库中的修改。

　　（4）DELETE：删除资源。顾名思义，该方法就是讲已经存在的资源删除，对应数据库中的删除。

RESTful API设计准则　

　　RESTful API可以理解为对资源进行操作的一种优雅的接口，URI 定位想要操作的资源，HTTP请求方式确定对该资源做什么样的操作，返回的状态码确定本次操作的结果。一个好的RESTful API的设计准则：

　　（1）一个好的RESTful API只允许第三方调用者使用五HTTP动词（GET, POST, PUT, DELETE, PATCH，在这里PUT和PATCH类似）进行数据交互，并在URL段里面不显示任何动词。

　　（2）在引入新版本API时，要保证旧版本仍然可用，当你想弃用旧版本时，一定要提醒用户使用新版本，旧版本会在某个时间段失效，另外在URL中要注明当前的版本号，当你决定不再支持某个版本时，一定要明确告诉第三方开发者这个版本即将被删除，可以以某种条件触发，比如在一个过时的API上发送了10000次请求就以邮件的形式告诉第三方开发者该API即将关闭。

　　（3）URL根应该尽量简洁，例如：

　　　　https://example.org/api/v1/*

　　　　https://api.example.com/v1/*

同时要注意前缀必须是https，一个好的RESTful API总是基于https来发布信息的。

　　（4） 端点就是指向特定资源或资源集合的URL，例如一个关于动物园，动物和员工信息的API，你还可以将HTTP请求方式和下面的URL任意组合。

　　　　https://api.example.com/v1/zoos

　　　　https://api.example.com/v1/animals

　　　　https://api.example.com/v1/animale_types

　　　　https://api.example.com/v1/employees

　　（5）当结果集比较大的时候可以采用过滤器或者分页来处理数据，只返回用户想要的数据（一般出现在查询时），可以使用？limit=10 或者？offset=10 等来操作，进行过滤或者分页。另外要避免用任何数据库的错误信息发送到客户端。

　　（6） 一个RESTful API 很重要的一点就是要使用HTTP的状态码，因为这是HTTP的标准，很多网络设备都可以识别这些状态码。

　　（7） 当使用不同的HTTP请求向服务器请求时，客户端需要在返回结果中拿到一系列的信息。例如（经典）。

　　　　GET/collection 返回一系列资源对象

　　　　GET/collection/resource 返回单独的资源对象

　　　　POST/collection 返回新创建的资源对象（当客户创建一个新资源时通常不知道它的ID，这些属性将在随后的请求中返回

　　　　PUT/collection/resource 返回完整的资源对象

　　　　PATCH/collection/resource 返回完整的资源对象

　　　　DELETE/collection/resource 返回空文档

　　（8）对于一个RESTful API 来说很重要的一点就是要使用HTTP的状态码，因为他们是HTTP的标准。很多的网络设备都可以识别这些状态码，借助HTTP的状态码可以让我们很清晰地指导请求结果。

　　（9）目前RESTful API中的数据类型主要是JSON，JSON数据类型是可以跨平台，跨语言的。

总结：

　　RESTful 是一种轻量级的架构，并且充分利用 HTTP 协议的特性实现对资源的操作，在未来 RESTful 架构风格将越来越主流化，采用 RESTful 架构可以让我们快速地开发出高效的 Web 应用。