RESTful

最新推荐文章于 2024-08-03 20:43:02 发布

Running SnaiL_

最新推荐文章于 2024-08-03 20:43:02 发布

阅读量157

点赞数

文章标签：网络 java

本文链接：https://blog.csdn.net/qq_44491553/article/details/114763263

版权

REST与RESTful

REST（[Resource] Representational State Transfer）：表现层状态转化

REST指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是RESTful。

Resource

在网络上，一切皆资源，每一种资源都有一个特定的URI指向。

Representation

资源呈现出的具体方式，称为“表现层”（representation）。例如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现；图片可以用JPG格式表现，也可以用PNG格式表现。

URI只代表资源实体，不代表它的形式。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对“表现层”的描述。

accept:application/json 浏览器->后台
content-type:application/json 响应格式

在这里插入图片描述

State Transfer

访问一个网站，就代表了客户端和服务器的一个互动过程，在这个过程中，势必涉及到数据和状态的变化。

互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。

因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生“状态转化”（State Transfer）。而这种转化是建立在表现层之上的，所以就是“表现层状态转化”。

改变（服务器端）资源的状态，可以通过某种手段，例如ajax、form。

新增：从无到有状态的变化
更新：从某个状态变成另外一种状态的转化
删除：从有到无状态的变化

Uniform Interface

REST要求，必须通过统一的接口来对资源执行各种操作。对于每个资源只能执行一组有限的操作。

以HTTP1.1协议为例，有7个HTTP方法：

GET（SELECT/查询）：从服务器取出资源（一项或多项）。
POST（CREATE/新增）：在服务器新建一个资源。
PUT（UPDATE/更新）：在服务器更新资源（客户端提供改变后的完整资源）。PUT更新整个对象。
DELETE（DELETE/删除）：从服务器删除资源。
PATCH（UPDATE/更新）：在服务器更新资源（客户端提供改变的属性【补丁】）。PATCH更新个别属性。
HEAD：获得一个资源的元数据，比如一个资源的hash值或者最后修改日期。
OPTIONS：获得客户端针对一个资源能够实施的操作（获取该资源的API）。

HTTP头信息（可自定义）
HTTP响应状态代码（可自定义）

这些就是HTTP1.1协议提供的统一接口。

REST还要求，对于资源执行的操作，其语义必须由HTTP消息体之前的部分完全表达，不能将操作语义封装在HTTP消息体内部。
正确的写法：http://www.wolfcode.cn/employees
错误的写法：http://www.wolfcode.cn/employee/saveOrUpdate.do?id=1&name=xx

RESTful设计

在RESTful架构中，每个网址代表一种资源（resource），所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表名对应。

一般来说，数据库中的表都是同种记录的集合（collection），所以URI中的名词也应该使用复数。

http://api.example.com/v1/zoos	动物园资源
http://api.example.com/v1/animals	动物资源
http://api.example.com/v1/employees	饲养员资源

GET /zoos 列出所有动物园，返回资源对象的列表（数组/集合）
POST /zoos 新建一个动物园，返回新生成的资源对象
GET /zoos/ID 获取某个指定动物园的信息，返回单个资源对象
PUT /zoos/ID	更新某个指定动物园的信息（提供该动物园的全部信息），返回完整的资源对象
PATCH /zoos/ID 更新某个指定动物园的信息（提供该动物园的部分信息），返回完整的资源对象
DELETE /zoos/ID 删除某个动物园，返回一个空文档（不返回）
GET /zoos/ID/animals 列出某个指定动物园的所有动物

200 OK - [GET]：服务器成功返回用户请求的数据。

201 CREATED - [POST/PUT/PATCH]：用户新建或修改数据成功。

202 Accepted - [*]：表示一个请求已经进入后台排队（异步任务）

204 NO CONTENT - [DELETE]：用户删除数据成功。

400 INVALID REQUEST -
[POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。

401 Unauthorized - [*]：表示用户没有权限（令牌、用户名、密码错误）。

403 Forbidden - [*] 表示用户得到授权（与401错误相对），但是访问是被禁止的。

404 NOT FOUND - [*]：用户发出的请求针对的是不存在的记录，服务器没有进行操作，该操作是幂等的。

406 Not Acceptable - [GET]：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）。

410 Gone -[GET]：用户请求的资源被永久删除，且不会再得到的。

422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误。

500 INTERNAL SERVER ERROR - [*]：服务器发生错误，用户将无法判断发出的请求是否成功。

一个API可以允许返回JSON，Xml甚至HTML等文档格式，建议使用json。

以前通过URL来规定获取得格式类型，比如：

https://api.example.com/employee.json
https://api.example.com/employee.html

但是更建议使用Accept这个请求头。

Accept与Content-Type的区别

在这里插入图片描述

Accept属于请求头， Content-Type属于实体头

Http报头分为通用报头，请求报头，响应报头和实体报头。
请求方的http报头结构：通用报头|请求报头|实体报头
响应方的http报头结构：通用报头|响应报头|实体报头

Accept代表发送端（客户端）希望接受的数据类型

比如：Accept：application/json;
代表客户端希望接受的数据类型是json类型,后台返回json数据

Content-Type代表发送端（客户端|服务器）发送的实体数据的数据类型。

比如：Content-Type:application/json 代表发送端发送的数据格式是json, 后台就要以这种格式来接收前端发过来的数据。

二者合起来：

Accept:application/json
Content-Type:application/json

即代表希望接受的数据类型是json格式，本次请求发送的数据的数据格式也是json格式。

设计restful接口步骤：

确定资源
确定请求方式
确定返回结果（类型、头信息、状态码）