一，前言
其实，我怀疑你并不了解 Restful ，不过没关系，今天，就让我来为大家揭开 Restful 的面纱，带大家看一些深层次的东西吧。
二，什么是 Restful？
Restful 是一种最流行的互联网架构。在介绍 Restful 之前，我们先介绍一下 REST。
REST 是 Fielding 大神在2000年时提出的，这位大神非同小可，不仅是 HTTP 协议的主要设计者，还是 Apache 基金会的第一任主席。故当他提出 REST 的概念时，便如同一石激起千层浪，对互联网行业产生了巨大的影响。
REST 即 Representational State Transfer，中文翻译是表现层状态转化，表示了 Fielding 大神对互联网软件架构原则的思考。
若一个架构符合 REST，那么我们称其为 RESTful 架构。
看到这里，可能大家还是一头雾水，博主你倒是说说什么是 REST 啊，你说符合 REST 的就是 RESTful 架构，我们又怎么知道什么是 REST 呢？别急，理解 REST 并不是一件容易的事情，且听我慢慢述说。
我们之前说过，REST 是 Representational State Transfer ，这几个单词连在一起可能比较难以理解，但是我们可以换个思路，先理解每个单词的意思，再把单词的语义连起来，这样不就得到了 REST 的语义了？
三，各个单词的语义
资源
我们说，REST 的语义是表现层状态转化，其实我们省略了主语，这个主语就是 “资源”，表现层是资源的表现层。
那么，什么是资源呢？资源，是网络上的一个具体信息，例如，一首歌是资源，一段文字是资源，一张图片亦是资源。我们可以使用一个 URI 指向资源，每一种资源对应特定的 URI 。每当我们需要访问资源的时候，只需访问其 URI 即可。
我们可以这么理解，URI 是资源的地址。所谓互联网上资源的调用，实际上就是调用资源所对应的 URI 。
Representational
Representational ，即表现层。
资源是具体信息，但信息可能有多种表现形式，举个例子，文本可以用 txt 格式实现，可以用 html 格式实现，还可以用二进制格式实现。我们把资源呈现出来的形式，称为它的表现层。
总的来说，URI 只代表资源的实体，不代表它的形式。
State Transfer
State Transfer 即状态转化。
当我们访问网站时，实际上是一个客户端和服务器互动的过程，在这个过程中会造成数据和状态的变化。
我们知道 HTTP 协议是一个无状态协议，所有的状态都保存在服务器端。若客户端想要操作服务器，必须通过某种手段，使服务器端发生状态转化。由于这种转化是在表现层之上的，所以又称为表现层状态转化。
所谓的手段，不过是 HTTP 协议罢了。实际上，HTTP 协议有四个动词，分别代表四种基本操作，这个在我们后文会详细介绍。
四，回到原点：到底什么是 Restful？
我们说，若一个架构符合 REST，那么我们称其为 RESTful 架构，然后我们又介绍了一下 REST，那么，是时候我们该给 Restful 做个简单的总结了。所谓 Restful，需要符合以下几个原则：
- 资源：每一个 URI ，代表一种资源
- Representational ：客户端和服务器之间会传递这种资源的某个表现层
- State Transfer：客户端通过四个 HTTP 动词，对服务器端资源进行操作
五，四个 HTTP 动词
HTTP 协议中，有四个表示操作方式的动词，代表对资源的不同操作：
| HTTP 方法 | 对资源的操作 | 幂等性 | 安全性 |
|---|---|---|---|
| GET | 获取资源 | 是 | 是 |
| POST | 新建资源 | 否 | 否 |
| PUT | 更新资源 | 是 | 否 |
| DELETE | 删除资源 | 是 | 否 |
我们看到上面提到了幂等性与安全性这两个名词，那么这两个名词究竟是什么意思呢？
- 幂等性：对同一 REST 接口的多次访问，得到的资源状态相同
- 安全性：对 REST 接口的访问，不会使服务器端资源的状态发生改变
六，接口写法
传统的 URI 请求格式
我们先来看看传统的 URI 请求格式，看看有什么问题。
- http://127.0.0.1/user/query/1 : 表示根据 id 查询用户数据
- http://127.0.0.1/user/save ： 表示新增用户数据
- http://127.0.0.1/user/update ： 表示修改用户数据
- http://127.0.0.1/user/delete ： 表示删除用户数据
大家看这样的 URI 请求格式如何？也许有的同学会说，设计的不错啊，条理清晰，没啥大毛病啊。但事实上，这样的 URI 请求格式是不符合 RESTful 架构的，因为这些 URI 都包含了动词。
我们之前说，资源是具体信息，所以它应该是名词，因此，URI 中不应包含动词，那么我们应该如何表示对资源的操作，或者换句话说，动词应该放在哪里呢？其实，动词应该放在 HTTP 协议中。
Restful 请求格式
我们说，动词应该放在 HTTP 协议中，那么具体应该怎么设计请求格式呢？我们把传统的四种 URI 请求格式稍作修改，去掉了 URI 中的动词，将其放入 HTTP 协议中，修改后的请求格式如下：
- http://127.0.0.1/user/1 GET ：表示根据 id 查询用户数据
- http://127.0.0.1/user POST ：表示新增用户数据
- http://127.0.0.1/user PUT ： 表示修改用户数据
- http://127.0.0.1/user DELETE ： 表示删除用户数据
七，响应
在响应中，我们需要根据 http 响应码，判断请求状态，并进行进一步的操作。
八，总结
在 Restful 架构中，URI 用于定位资源，而 HTTP 动词描述了对资源进行什么操作。
使用 Restful，我们可以实现以下目标：
- 根据 URI 可以知道需要的资源
- 根据 http method 可以知道对资源进行什么样的操作
- 根据 http status code 可以知道返回结果
