初始前后端连调

第九单元知识点

一.什么是前后端分离 和 前后端不分离，以及优缺点。

1.传统的不分离：

• 业务耦合较强

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

• 指责划分不明确

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

---

• 开发成本较高

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

---

• 服务器压力较大

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

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

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

2.现在的前后端分离：

• 部署解耦

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

---

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

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

---

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

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

---

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

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

9.1.2 什么是restful风格

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

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

• `POST /add-

二.restful风格：使用合理的请求方式、提供参数过滤数据、使用合理的状态码：

Restful 风格建议，Api 服务器的域名要尽量在专用域名之下
如：百度面向用户的站点地址为https://baidu.com
那么后端的接口地址可以为

https://api.baidu.com

也可以放在连接之后

https://baidu.com/api/

2.使用合理的请求方式

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

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

• GET：获取数据
• POST：提交数据，创建数据
• PUT：提交数据，更新数据
• DELETE：删除数据

---

如果数据较多，返回所有数据是不现实的，那么可以让API提供参数，进行结果返回

2.提供参数过滤数据

?limit=10：指定返回记录的数量
?offset=10：指定返回记录的开始位置。
?page=2&per_page=100：指定第几页，以及每页的记录数。
?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序。
?animal_type_id=1：指定筛选条件

3.状态码：

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

3.API接口 以及 接口文档：

API接口文档一般分为接口描述、接口地址、请求方法、请求参数、响应内容、错误代码、实例几个部分：

4.DRF项目配置：

INSTALLED_APPS = [
…
‘rest_framework’,
]

5.APIView、Response

先导入：from rest_framework.views import APIView #drf里的
APIView：
class Index(APIView):
    def post(self,request):
        # data，代替post
        user = request.data.get('user')
        pwd = request.data.get('pwd')
        print(user)
        print(pwd)
        return Response({'name':'李四'}) #返回成json数据
        from rest_framework.response import Response：#返回成json数据

6.什么是json，序列化和反序列化。

这一种在各个编程语言中流通的数据格式，可以在不同的编程语言中的进行数据传递和交互，比如{“name”:“姓名”}或者[{“name”:“姓名”}]

序列化：ORM操作数据 -->JSON数据（序列化）查询

class All(APIView):
    def get(self,request):
        data = People.objects.all() #查询是所有人物信息，data为ORM操作的查询结果集
        # 手动实现序列化，orm数据-》转换json格式数据：
        people_list = [] #存放所有人物信息
        for people in data:
            people_info = {
                'peo_name': people.peo_name,
                'desc': people.desc,
                'sex': people.sex,
                'movie': people.movie.movie_name
            }
            people_list.append(people_info)  #追加到列表尾部
        return Response(people_list)

JSON格式数据 -->ORM操作数据（反序列化）添加 更新

删除不涉及序列化和反序列化

序列化器，帮助实现序列化和反序列化的过程的工具