API（Application Programming Interface，应用程序接口）
REST，即Representational State Transfer的缩写,中文是"表现层状态转化"。
它是一种互联网应用程序的API设计理念：可以用URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作来解释什么是REST。
其实全称是 Resource Representational State Transfer：通俗来讲就是：资源在网络中以某种表现形式进行状态转移。(再通俗来说，就是通过HTTP请求服务器上的某资源，使该资源copy了一份到服务请求方那去了(get动作)。个人这么理解)
我们分解开来进行解释：
- Resource：资源，即数据它可以是一段文本、一张图片、一首歌曲等；
- Representational：某种表现形式，比如用JSON，XML，JPEG等；HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对"表现形式"的描述。
- State Transfer：状态变化。通过HTTP动词实现。
注：互联网通信协议HTTP协议，是一个无状态协议。**这意味着，所有的状态都保存在服务器端。**因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
- REST的设计原则
- 网络上的所有事物都被抽象为资源
- 每个资源都有一个唯一的资源标识符
- 同一个资源具有多种表现形式(xml,json等)
- 对资源的各种操作不会改变资源标识符
- 所有的操作都是无状态的
HTTP协议-URL
HTTP是一个属于应用层的协议，特点是简捷、快速。
schema：//host[:port]/path[?quert-string] [#anchor]
-
schema 指定底层使用的协议（例如：http，https,ftp）
-
host 服务器的IP地址或者域名
-
port 服务器端口，默认为80
-
path 访问资源的路径
-
query0string 发送给http服务器的数据
-
anchor 锚
HTTP协议-请求
HTTP协议-请求
组成格式：请求行、消息报头、请求正文
请求行
格式如下：Method Request-URI HTTP-Version CRLF
举例
GET / HTTP / 1.1 CRLF
请求方法
- GET 请求获取Request-URI所标识的资源
- POST 在Request-URI所标识的资源后附加新的数据
- HEAD 请求获取由Request-URI所标识的资源的响应消息
获取
发送数据
- PUT 请求服务器存储一个资源 ，并用Request-URI作为其标识
- DELETE 请求服务器删除Request-URI所标识的资源
- OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求
HTTP协议-响应
HTTP协议-响应
组成格式：状态行、消息报头、响应正文
状态行
HTTP-Version Status-Code Reason-Phrase CRLF
HTTP/1.1 200 OK
常用状态码
-
200 OK //客户端请求成功
-
400 Bad Request //客户端请求有语法错误，不能被服务器所理解
-
401 Unauthorized //服务器收到请求，但是拒绝提供服务
-
404 Not Found //请求资源不存在
5xx服务器错误
- 500 Internal Server Error //服务器发生不可预期的错误
- 503 Server Unavailable //服务器当前不能处理客户端的请求
RESTful架构与其他架构的区别
SOAP WebService
WebService是一种跨编程语言和跨操作系统平台的远程调用技术
WebService通过HTTP协议发送请求和接受结果时采用XML格式封装，并增加了一些特定的HTTP消息头，这些特定的HTTP消息头和XML内容格式就是SOAP协议。
WebService 、SOAP协议、RESTful架构与WebService
RESTful架构与其他架构的区别
效率和易用性
SOAP由于各种需求不断扩充本身协议的内容，导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。
RESTful由于其面向资源接口设计以及操作抽象简化了开发者的不良设计,同时也最大限度的利用了Http最初的应用协议设计理念。
安全性
RESTful对于资源型服务接口来说很合适,同时特别适合对于效
率要求很高,但是对于安全要求不高的场景。
SOAP的成熟性可以给需要提供给多开发语言的, 对于安全性
要求较高的接口设计带来便利。所以觉得纯粹说什么设计模
式将会占据主导地位没有什么意义,关键还是看应用场景。
restful适合做什么开发
接口或者应用
4、 如何使用Restful
如何设计RESTful API
-
资源路径（URI）
-
HTTP动词
-
过滤信息
-
状态码
-
错误处理
-
返回结果
请求设计规范
- URI使用名词，尽量用复数，如/users
- URI使用嵌套表示关联关系，如 /users/12/repos/5
- 使用正确的HTTP方法，如GET/POST/PUT/DELETE
- 不符合CRUD的情况：POST/action/子资源
资源路径
在RESTful架构中，每个网址代表一种资源，所以网址中不能有动词，只能有名词，一般来说API中的名词应该使用复数。goods、users等。
举例
举例来说,有一个API提供动物园( zoo )的信息,还包括各种动物和雇员的信息。则它的路径应该设计成下面这样。
https://api.example.com/v1/zoos //动物园资源
https://api.example.com/v1/animals //动物园资源
https://api.example.com/v1/employees //动物园资源
v1版本、http请求头中 或者 名词复数
获取一个动物 animals/id=1
资源的设计
http 动词 四种操作 创建 更新 读取 删除
HTTP动词
对于资源的操作（CURD），由HTTP动词（谓词）表示
-
GET：从服务器取出资源（一项或多项）。
-
POST：在服务器新建一个资源。
-
PUT：在服务器更新资源（客户端提供改变后的完整资源）
-
PATCH：在服务器更新资源（客户端提供改变的属性）。
-
DELETE：从服务器删除资源。
put更新资源 patch只会返回更新的数据 比如改密码 密码变了就返回密码。
举例
-
POST /zoos:新建一个动物园
-
GET /zoos/ID:获取某个指定动物园的信息
-
PUT /zoos/ID: 更新某个指定动物园的信息
-
DELETE /zoos/ID:删除某个动物园
删除动物园，动物园里的动物都删除
POST新建 GET 获取 PUT 更新 DELETE 删除
状态码
标准的
服务器向用户返回的状态码和提示信息，使用标准HTTP状态码。
- 200 OK 服务器成功返回用户请求的数据，该操作是幂等的。
- 201 CREATED created 新建或修改数据成功
- 204 NO CONTENT 删除数据成功
200 OK
201新建修改204删除，用得比较少的。
- 400 BAD REQUEST request 用户发出的请求有错误，该操作是幂等的。
- 401 Unauthorized 表示用户没有认证，无法进行当前操作。
- 403 Forbidden 表示用户访问是被禁止的。
客户端的请求有问题
401 没有认证
403 提供了 但参数不足 或者权限不够
- 422 Unprocesable Entity 当创建一个对象时，发生一个验证错误。
- 500 INTERNAL SERVER ERROR internal server error 服务器发生错误，用户将无法判断发出的请求是否成功。
422
验证错误 后端需要用户名 密码 前端只提供了一个用户名 错误了 密码不能为空
500
服务器错误
错误处理
422 参数错误 500