DRF 框架总结-引入 Django REST framework 框架

引入 Django REST framework 框架

Web 应用模式

在开发 Web 应用中，有两种开发模式：

前后端不分离

前后端分离

前后端不分离

在前后端不分离的应用模式中，前端看到的效果都是有后端控制，由后端渲染页面或重定向，也就是后端需要 控制前端的展示，前端与后端的耦合度很高。

这种应用模式比较适合纯网页应用，但是当后端对接 app 时， app 可能并不需要后端返回一个 HTML 网页，而仅仅是数据本身，所以后端原本返回网页的接口不再适用于前端的 app 应用，为了对接 app 后端还需要再开发一套接口。

前后端分离

低耦合，高内聚

耦合：；模块与模块之间接口的复杂程度，模块之间联系越复杂耦合度越高，牵一发而动全身。

内聚：每个模块尽可能独立完成自己的功能，不依赖于模块外部的代码。

使模块的“可重用性”，“移植性” 大大增强

在前后端分离的应用模式中，后端仅返回前端所需要的数据，不再渲染 HTML页面，不再控制前端的效果。至于前端用户看到什么效果，从后端请求的数据如何加载到前端中，都由前端自己决定，网页有网页的处理方式，app 有 app 的处理方式，但无论哪种前端，所需的数据基本相同，后端仅需开发一套逻辑对外提供数据即可。

在前后端分离的应用模式中，前端与后端的耦合度相对较低。

在前后端分离的应用模式中，我们通常将后端开发的每个视图都称为一个接口，或者 API，前端通过访问接口来对数据进行增删改查。

认识 RESTful

在前后端分离的应用模式里，后端 API 接口如何定义？

后端数据库中保存的数据，前端可能需要对商品数据进行增删改查，对应的每个操作后端都需要提供一个 API 接口；

对于接口的请求方式与路径，每个后端开发人员可能都有自己的定义方式。

所以普遍采用的 API 的 RESTful 设计风格。

起源

REST 是 Fielding 在他的 2000 年的博士论文中提出的，他还是 HTTP 协议的主要设计者

名称

Fielding 将互联网软件的架构原则，定名为REST，即Representational State Transfer的缩写。维基百科称其为“具象状态传输”，国内大部分人理解为“表现层状态转化”。

RESTful 是一种开发理念。维基百科说：REST 是设计风格而不是标准。

REST 特点：url 简洁，将参数通过 url 传到服务器。

一个架构符合 REST 原则，就称它为 RESTful 架构。

要理解RESTful架构，理解Representational State Transfer这三个单词的意思：

具象的，就是指表现层，要表现的对象也就是“资源”，就是客户访问服务器，所获取的就是资源。

表现: 文本可以使用 txt、html、xml、json格式表现，图片可以使用 jpg、png 表现

状态转换: 就是客户端和服务器互动的一个过程，在这个过程或只能怪，势必涉及到数据和状态的变化，这种变化叫状态转换。

互联网通信协议HTTP协议，客户端访问必然使用HTTP协议，如果客户端想要操作服务器，必须通过某种手段，让服务器发生“状态转化”（State Transfer）

HTTP 协议实际上包含有 4 个表示操作方式的动词，分别是 GET, POST, PUT, DELETE,他们分别对应四种操作。GET 用于获取资源，POST 用于新建资源，PUT 用于更新资源，DELETE 用于删除资源。GET 和 POST 是表单提交的两种 基本方式，比较常见。

HTTP 协议是一种无状态协议，这样就必须把所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器发生“状态转化”。

总结

RESTful 架构就是：

每个 URL 代表一种资源

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

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

RESTful 设计方法

域名

应该尽量将 API 部署在专用域名之下，如果 API 确定很简单，不会有进一步扩展，可以考虑放在主域名下。

版本

应该将 API 的版本号放入 URL，另一种做法是将版本号放在 HTTP 头信息中。

路径

路径又称为“终点”，表示 API 的具体网址，每个网址代表一种资源。

资源作为网址，只能有名词，不能有动词，而且所用的名称往往与数据库的表名对应。

API 中的名称应该使用复数。无论子资源 或者所有资源。

HTTP 动词

对于资源的具体操作类型，由HTTP动词表示。

常用的HTTP动词有下面四个（括号里是对应的SQL命令）。

GET（SELECT）：从服务器取出资源（一项或多项）。

POST（CREATE）：在服务器新建一个资源。

PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。

DELETE（DELETE）：从服务器删除资源。

还有三个不常用的HTTP动词。

PATCH（UPDATE）：在服务器更新(更新)资源（客户端提供改变的属性）。

HEAD：获取资源的元数据。

OPTIONS：获取信息，关于资源的哪些属性是客户端可以改变的。

过滤信息

如果记录数量很多，服务器不可能都将它们返回给用户。API 应该提供参数，过滤返回结果 。

参数的设计允许存在冗余，即允许 API 路径和 URL 参数偶尔有重复。

状态码

服务器向用户返回的状态码和提示信息：

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 - [*]：服务器发生错误，用户将无法判断发出的请求是否成功。

错误处理

如果状态码是 4xx，服务器就应该向用户返回出错信息。一般来说，返回的信息中将 error 作为键名，出错信息作为键值即可。

返回结果

针对不同操作，服务器向用户返回的结果应该符合以下规范。

GET /collection：返回资源对象的列表（数组）

GET /collection/resource：返回单个资源对象

POST /collection：返回新生成的资源对象

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

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

DELETE /collection/resource：返回一个空文档

超媒体

RESTful API 最好做到 Hypermedia（即返回结果中提供链接，连向其他 API 方法），使得用户不查文档，也知道下一步应该做什么。

其他

服务器返回的数据格式，应该尽量使用 json，避免使用 xml

使用 Django 开发 REST 接口

不同的请求访问不同的路由，不同的路由对应相应要执行的方法，取到数据，构造 json 格式，返回数据。

GET /books/ 返回所有的数据

POST /books/ 新建数据

GET /books/id/ 查询一条数据

PUT /books/id/ 修改某条数据

DELETE /books/id/ 删除某条数据

明确 REST 接口开发的核心任务

在开发 REST API 接口时，视图中做的最主要有三件事：

将请求的数据转换为模型类对象

操作数据库

将模型类对象转换为响应的数据

序列化 serialization

序列化简单理解就是将程序中的一个数据结构类型转换为其他格式（字典、JSON、XML等），例如将 Django 中的模型类对象转换为 json 字符串这个转换过程我们称为序列化。

反之，将其他格式（字典、json、xml等）转换为程序中的数据，例如将 json 字符串转换为 Django 中的模型类对象，这个过程我们称为反序列化。

在开发 REST API 时，视图中要频繁的进行序列化与反序列化的编写。

总结

在开发 REST API 接口时，我们在视图中需要做的最核心的事是：

将数据库数据序列化为前端所需要的格式，并返回；

将前端发送的数据反序列化为模型类对象，并保存到数据库中。

Django REST framework 简介

在序列化与反序列化时，虽然操作的数据不尽相同，但是执行的过程却是相似的，也就是说这部分代码是可以复用简化编写的。

在开发 REST API 的视图中，虽然每个视图具体操作的数据不同，但增、删、改、查的实现流程基本套路化，所以这部分代码也是可以复用简化编写的：

增：校验请求数据 -> 执行反序列化过程 -> 保存数据库 -> 将保存的对象序列化返回

删：判断要删除的数据是否存在 -> 执行数据库删除

该：判断要修改的数据是否存在 -> 校验请求的数据 -> 执行反序列化过程 -> 保存数据库 -> 将保存的对象序列化并返回

查：查询数据库 -> 将数据序列化并返回

Django REST framework 可以帮助我们简化上述两部分的代码编写，大大提高 REST API 的开发速度。

认识 Django REST framework

Django REST framework 框架是一个用于构建 web API 的强大而又灵活的工具。通常简称为 DRF 框架或 REST framework。

DRF 框架是建立在 Django 框架基础之上，由 Tom Christie 大牛二次开发的开源项目。

特点：

提供了定义序列化器 serializer 的方法，可以快速根据 Django ORM 或者其它库自动序列化/反序列化；

提供了丰富的类视图、Mixin 扩展类、简化视图的编写；

丰富的定制层级：函数视图、类视图、视图集合到自动生成 API，满足各种需要；

多种身份认证和权限认证方式的支持；

内置了限流系统；

直观的 API Web 界面；

可扩展性，插件丰富。