DRF

1. Web应用模式
2. api接口
3. RESTful API规范
4. 序列化
5. Django Rest_Framework
DRF框架视图总结：

1. Web应用模式

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

（1）前后端不分离[客户端看到的内容和所有界面效果都是由服务端提供出来的。]

这种模式中，前端页面看到的效果都是由后端控制，由后端渲染页面或重定向，也就是后端需要控制前端的展示，前端与后端的耦合度很高。
这种应用模式比较适合纯网页应用，但是当后端对接App时，App可能并不需要后端返回一个HTML网页，而仅仅是数据本身，所以后端原本返回网页的接口不再适用于前端App应用，为了对接App后端还需再开发一套接口。

请求的数据交互如下图：

flask框架应用模板开发就是前后端不分离开发模式

特点

http请求次数少
只需要一个后台服务器
前后端开发耦合，责任不明确
单纯开发网站，效率非常高
响应的往往是html的页面
分工
- 前端：负责写html、css、js
- 后端：需要控制数据的展示，负责渲染页面或重定向
实现方案：访问页面后，后端根据路由进行匹配视图函数，通过render等返回页面和数据，如：return render(request,'home.html',res)渲染页面。

（2）前后端分离【把前端的界面效果(html，css，js分离到另一个服务端，python服务端只需要返回数据即可)】

前端形成一个独立的网站，服务端构成一个独立的网站

含义：前后端开发约定好接口文档（url、参数、数据类型等），独立开发，前端可mock数据进行测试，最后前后端集成，实现了前后端应用的解耦合。

在前后端分离的应用模式中，后端仅返回前端所需的数据，不再渲染HTML页面，不再控制前端的效果。至于前端用户看到什么效果，从后端请求的数据如何加载到前端中，都由前端自己决定，网页有网页的处理方式，App有App的处理方式，但无论哪种前端，所需的数据基本相同，后端仅需开发一套逻辑对外提供数据即可。
在前后端分离的应用模式中，前端与后端的耦合度相对较低。
在前后端分离的应用模式中，我们通常将后端开发的每个视图都称为一个接口，或者API，前端通过访问接口来对数据进行增删改查。

对应的数据交互如下图：

特点：

有静态文件服务器、后台的应用服务器
后台服务器只提供的接口的服务
前后端责任分工明确
一个后台即可满足网站、app、小程序等多种应用的需要
响应的往往是json的数据
分工：
- 前端：负责数据展示和用户交互
- 后端：负责提供数据处理接口
实现方案：
- 一般基于vue.js框架来编写前端页面，需要通过ajax形式向后端发送请求获取接口数据。后端接收到请求后，执行视图函数，将数据以json格式返回给前端。前端接收到数据后，渲染到页面。

前后端分离的优点：

彻底解放前端:前端不再需要向后台提供模板或是后台在前端html中嵌入后台代码
前后端可同时开发，完全独立，提升效率:前后端分离的工作流程可以使前端只关注前端的事，后台只关心后台的活，两者开发可以同时进行，在后台还没有时间提供接口的时候，前端可以先将数据写死或者调用本地的json文件即可，页面的增加和路由的修改也不必再去麻烦后台，开发更加灵活。
json数据格式拓展性强
局部性能提升:通过前端路由的配置，我们可以实现页面的按需加载，无需一开始加载首页便加载网站的所有的资源，服务器也不再需要解析前端页面，在页面交互及用户体验上有所提升。
降低维护成本:通过MVC框架，我们可以非常快速的定位及发现问题的所在，客户端的问题不再需要后台人员参与及调试，代码重构及可维护性增强。

2. api接口

目前市面上大部分公司开发人员使用的接口实现规范主要有：restful、RPC。

（1）RPC（ Remote Procedure Call ）: 翻译成中文:远程过程调用[远程服务调用]. 从字面上理解就是访问/调用远程服务端提供的api接口。

服务端提供一个唯一的访问入口地址：http://api.xxx.com/ 或 http://www.xx.com/api 或者基于其他协议的地址
客户端请求服务端的时候，所有的操作都理解为动作(action)，一般web开发时，对应的就是HTTP请求的post请求
通过请求体参数，指定要调用的接口名称和接口所需的参数

action=get_all_student&class=301&sex=1

m=get_all_student&sex=1&age=22

command=100&sex=1&age=22

rpc接口多了,对应函数名和参数就多了,前端在请求api接口时难找.对于年代久远的rpc服务端的代码也容易出现重复的接口

（2）restful: 翻译成中文: 资源状态转换.(表征性状态转移)

把服务端提供的所有的数据/文件都看成资源，那么通过api接口请求数据的操作，本质上来说就是对资源的操作了.

因此，restful中要求，我们把当前接口对外提供哪种资源进行操作，就把资源的名称写在url地址。
web开发中操作资源，最常见的最通用的无非就是增删查改，所以restful要求在地址栏中声明要操作的资源是什么。然后通过http请求动词来说明对该资源进行哪一种操作.

POST http://www.xxx.com/api/students/ 添加学生数据

GET http://www.xxx.com/api/students/ 获取所有学生

GET http://www.xxx.com/api/students// 获取id=pk的学生

DELETE http://www.xxx.com/api/students// 删除id=pk的一个学生

PUT http://www.xxx.com/api/students// 修改一个学生的全部信息 [id,name,sex,age,]

PATCH http://www.xxx.com/api/students// 修改一个学生的部分信息[age]

也就是说，我们仅需要通过url地址上的资源名称结合HTTP请求动作，就可以说明当前api接口的功能是什么了。

restful是以资源为主的api接口规范，体现在地址上就是资源就是以名词表达。
rpc则以动作为主的api接口规范，体现在接口名称上往往附带操作数据的动作。

3. RESTful API规范

REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。

RESTful是一种专门为Web 开发而定义API接口的设计风格，尤其适用于前后端分离的应用模式中。这种风格的理念认为后端开发任务就是提供数据的，对外提供的是数据资源的访问接口，所以在定义接口时，客户端访问的URL路径就表示这种要操作的数据资源。而对于数据资源分别使用POST、DELETE、GET、UPDATE等请求动作来表达对数据的增删查改。

请求方法	请求地址	后端操作
GET	/students	获取所有学生
POST	/students	增加学生
GET	/students/	获取编号为pk的学生
PUT	/students/	修改编号为pk的学生
DELETE	/students/	删除编号为pk的学生

restful规范是一种通用的规范，不限制语言和开发框架的使用。事实上，我们可以使用任何一门语言，任何一个框架都可以实现符合restful规范的API接口。

4. 序列化

api接口开发，最核心最常见的一个代码编写过程就是序列化，所谓序列化就是把数据转换格式。常见的序列化方式：json，pickle，base64，….

序列化可以分两个阶段：

序列化：把我们识别的数据转换成指定的格式提供给别人。

例如：我们在django中获取到的数据默认是模型对象，但是模型对象数据无法直接提供给前端或别的平台使用，所以我们需要把数据进行序列化，变成字符串或者json数据，提供给别人。

反序列化：把别人提供的数据转换/还原成我们需要的格式。

例如：前端js提供过来的json数据，对于python而言json就是字符串，我们需要进行反序列化换成字典，然后接着字典再进行转换成模型对象，这样我们才能把数据保存到数据库中。

5. Django Rest_Framework

核心思想: 大量缩减编写api接口的代码

Django REST framework是一个建立在Django基础之上的Web 应用开发框架，可以快速的开发REST API接口应用。在REST framework中，提供了序列化器Serialzier的定义，可以帮助我们简化序列化与反序列化的过程，不仅如此，还提供丰富的类视图、扩展类、视图集来简化视图的编写工作。REST framework还提供了认证、权限、限流、过滤、分页、接口文档等功能支持。REST framework提供了一个API 的Web可视化界面来方便查看测试接口。

特点：

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

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

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

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

内置了限流系统；

直观的 API web 界面；【方便我们调试开发api接口】

可扩展性，插件丰富