GenericAPIView数据从序列化到最终返回响应的数据流
// 以ModelSerializer+generics.CreateAPIView为例
程序终归是为了处理数据，怎么处理，以怎样的顺序和方法去处理，就涉及到了具体的业务流程。当我们是用了一个牛掰的框架，发现原来熟悉的方法不见了，取而代之的是不断地重写或复用 已有的方法，但要想知道什么时候应该去复用谁，什么时候应该去重写谁，就必须要清楚数据在各模块方法间的传递顺序，即数据流。
目录
- GenericAPIView数据从序列化到最终返回响应的数据流
- [// 以ModelSerializer+generics.CreateAPIView为例](#// 以ModelSerializer+generics.CreateAPIView为例)
- [1 数据从 Serializer 传递到 generics.CreateAPIView再到最终提交到数据库经历的几个过程](#1 数据从 Serializer 传递到 generics.CreateAPIView再到最终提交到数据库经历的几个过程)
-
- [1.1 数据反序列化](#1.1 数据反序列化)
- [1.2 数据验证（Validation）](#1.2 数据验证（Validation）)
- [1.3 创建实例（Instance Creation）](#1.3 创建实例（Instance Creation）)
- [1.4 数据保存（Data Saving）](#1.4 数据保存（Data Saving）)
- [1.5 返回响应（Response）](#1.5 返回响应（Response）)
- [2 同时重写perform_create和create方法时](#2 同时重写perform_create和create方法时)
1 数据从 Serializer 传递到 generics.CreateAPIView再到最终提交到数据库经历的几个过程
从 Serializer 到 generics.CreateAPIView 再到数据库的数据流包括了数据的反序列化、数据验证、实例创建、持久化、返回响应这几个过程。
1.1 数据反序列化
前端调用接口，给到后端的是JSON/XML结构的数据，这类数据本质是字符串，无法被后端代码直接使用，所以要将字符串变成python对象，这个过程叫做反序列化。反之，则为序列化。
这一步是透明的，通常不需要做处理。
1.2 数据验证（Validation）
一旦数据被反序列化，Serializer 将会对数据进行验证 。这意味着它会检查数据是否符合您在 Serializer 类中定义的模型字段的规则，例如字段类型、长度限制、唯一性等等。如果数据验证失败，Serializer 将会抛出验证错误。
这一步可以：
- 可以用validate方法自定义验证方式，可以校验一些特殊的字段，比如电话号码等等
- 可以重写Serializer的create方法，从而修改或添加一些必要的字段
1.3 创建实例（Instance Creation）
如果数据通过了验证，generics.CreateAPIView 的 create() 方法将被调用。在该方法内部，会使用验证后的数据 创建模型实例。通常，您会使用 serializer.save() 方法来创建模型实例，该方法会返回已经保存到数据库的实例对象。
这一步可以：
- 可以重写perform_create方法，在正式提交到数据库之前，对一些字段做修改
1.4 数据保存（Data Saving）
在perform_create 中，会调用serializer.save() 方法来创建模型实例，一旦实例被创建，save() 方法会将实例保存到数据库中。这通常会触发数据库操作，如 INSERT 查询，将数据持久化存储到数据库中。
1.5 返回响应（Response）
数据保存成功后，create() 方法会返回一个 HTTP 响应，通常是成功创建对象的响应，包含新创建的对象的数据。
这一步可以：
- 可以重写create方法，可以自定义返回值。
2 同时重写perform_create和create方法时
在 generics.CreateAPIView 中，数据首先到达 perform_create() 方法，然后再到达 create() 方法。同时重写了这两个方法，数据流并没有发生变化，这两个方法的作用也没有发生变化。
依然是perform_create用来保存实例到数据库，create则返回响应结果。
可以根据实际情况来重写这两个方法。