第九单元 DRF框架及APIView

9.1 基本概念

9.1.1 什么是前后端分离

前后端分离

• 前：浏览器
  • HTML、CSS、Bootstrap、JS、JQuery、Vue、NodeJS、webpack
  • 体验为主：炫酷、流畅、兼容
• 后：服务端
  • Jvm、springboot、Django、flask、tornado、
  • 三高：高并发、高可用、高性能

传统的不分离

用户在浏览器上发送请求，服务器端接收到请求，根据 Header 中的 token 进行用户鉴权，从数据库取出数据，处理后将结果数据填入 HTML 模板，返回给浏览器，浏览器将 HTML 展现给用户，不分离的核心就是模版，比如 Django 直接将返回数据到模版，通过模版表单将数据返回至后端

• 业务耦合较强

那这样就有一个问题，从事不分离的开发者，一般需要懂数据库、懂框架操作、懂模版前端，小型项目还好，一个人可以抗的下来，你可以加班，但如果项目较大，一个人无法独立完成，需要团队合作

---

• 指责划分不明确

并且不分离的情况，所有的业务、代码、逻辑都在一套服务体系内，会造成团队之间沟通混乱，代码风格不统一，每个人的前后端技能水平层次不齐的水平，出了问题找背锅的人更慢，无法快速找到罪魁祸首

• 开发成本较高

除此之外，不分离还有一个问题，现在的服务，比如一个电商平台，除了WEB端之外，还会有 IOS 端、安卓端的各种 APP，本质上这些软件 APP 用的都是同一套数据，但是现在除了每一套前端的应用界面，由于不分离的情况，还需要给每一个平台不同的 APP 开发多套后端，这个开发成本是很高的，需要很多很多的不同语言的开发者

• 服务器压力较大

此外页面的渲染本应该是在客户端完成，但是现在都是在服务端渲染好之后再返回给用户，那么在高并发的情况下，会大量占用服务器的资源

• 提高 SEO 速度，提高搜索引擎收录检索速度

当然，不分离也有好处，页面数据都是渲染好返回的，可以有效提高 SEO的速度

现在的前后端分离

数据渲染的工作在客户端浏览器，不需要服务端完成，服务端专注于提供数据

那么这就要求Django框架不需要返回一个模版页面，而是返回一套JSON数据，而由于JSON可以在多种语言中支持，是一种交互、兼容非常合适的语言格式，所以现在后台常返回的数据都为JSON格式的，这个过程也称作序列化

• 部署解耦

前后端分离再就是部署压力较小，前后端分离部署，可以分离业务，起码在后端宕机时，前端还可以正常服务

---

• 业务划分清晰，职责更为明确

后端工程师只需要专注于编写接口，从数据库提取数据，进行逻辑处理，并返回给前端，而前端怎么去渲染，怎么写样式，用什么前端，这都不是后端工程师需要考虑的，后端要做好的就一件事，写好接口就可以

---

• 开发成本较低，一套后台可以支持多套前端渲染

一般来说，一套接口编写好之后，业务相同的情况下，是可以在多种 app 端、pc 端进行渲染展示的，不需要额外开发多套耦合的服务，这就很省钱了

---

• SEO 优化较差，需要引入一些页面静态化手段

但是前后端分离也有不好的地方，在于页面数据的渲染是需要花费时间的，数据并不是渲染好返回给用户，所以可能会出现白屏时间，并且影响搜索引擎爬虫的检索收录

9.1.2 什么是restful风格

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

例如:对于后端数据库中保存了商品的信息，前端可能需要对商品数据进行增删改查，那相应的每个操作后端都需要提供一个API接口：

• POST /add-goods 增加商品
• POST /delete-goods 删除商品
• POST /update-goods 修改商品
• GET /get-goods查询商品信息

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

是否存在一种统一的定义方式，被广大开发人员接受认可的方式呢？

这就是被普遍采用的*API*的RESTful设计风格。

RestFul 规范建议

1. 域名要有标示

Restful 风格建议，Api 服务器的域名要尽量在专用域名之下

如：百度面向用户的站点地址为https://baidu.com

那么后端的接口地址可以为

https://api.baidu.com

也可以放在连接之后

https://baidu.com/api/

---

2. 路由中体现接口版本号

如果你的接口会不停的升级，那么建议你把接口的版本号维护在URL中，比如图灵机器人就是这么干的，API 的升级会把版本放入连接

https://api.baidu.com/v1/
https://baidu.com/api/v1/
http://openapi.tuling123.com/openapi/api/v2

3.使用合理的请求方式

对应操作，应该返回操作后的资源结果，比如获取数据，那就应该使用GET请求方式

如果是更新数据，那么建议你使用PUT或PATCH方法