一 序列化组件
首先按照restful规范咱们创建一些api接口，按照下面这些形式写吧：
Courses --- GET ---> 查看数据----->返回所有数据列表[{},{},]
Courses--- POST --->添加数据 -----> 返回添加的数据{ }
courses/1 ---PUT---> 更新pk=1的数据 ----->返回更新后的数据{ }
courses/1 --- DELETE---> 删除pk=1的数据 -----> 返回空
courses/1 --- GET --->查看单条数据 -----> 返回单条数据 { }
这样，我们先看一个drf给我们提供的一个类似于Postman功能的页面，首先我们创建一个django项目，创建一个Course表，然后添加一些数据，然后按照下面的步骤操作，
这里面我们可以发送不同类型的请求，看到对应的返回数据，类似于Postman，但是没有Postman好用，所以以后调试我们还是用Postman工具，但是我们知道一下昂。
上面的数据，我们通过json自己进行的序列化，其实django也给我们提供了一个简单的序列化组件，看用法：
那么我们知道了两个序列化方式了，这个序列化是不是就简单很多啊，但是drf给我们做了一个更牛逼的序列化组件，功能更强大，而且不仅仅能做序列化，还能做其他的事情，所以呢，做api的时候，我们还是用drf提供的序列化组件。
看效果：
然后添加一些数据，好，接下来我们玩一些有关联关系的表
看序列化代码：
其实serializer在内部就做了这点事儿，伪代码昂。
urls.py是这样写的：
然后看Postman返回的数据：
那么我们就能够完成各种数据的序列化了，但是你会发现，这样写太累啦，这只是一张表啊，要是上百张表咋整啊，所以还有一个更简单的方式(类似于form和modelform的区别)。
我们使用ModelSerializer，看代码：
上面我们完成了get请求来查看所有的书籍信息，接下来我们玩一个post请求添加一条book数据，直接上代码吧：
上面我们完成了GET和POST请求的接口写法，下面我们来完成PUT、DELETE、GET查看单条数据的几个接口。
urls.py内容如下：
views.py代码如下：
好，五个接口写完，咱们的序列化组件就算是讲完了，别忘了看这一节最后的那个坑。
重写save的create方法
超链接API，Hyperlinked
serializer的属性和方法：
serializer的Field：
serializer的公共参数：
关于同一个序列化组件在做get(获取数据)和post(添加数据)时候的一些坑，直接上代码吧(等我再深入研究一下，再给出更好的答案~~)：
二 视图组件(Mixin混合类)
按照我们上面的序列化组件的视图，接着写，我们上面只说了一个Book表的几个接口操作，但是我们是不是还有其他表呢啊，如果我们将上面的四个表都做一些序列化的接口操作，我们是不是按照下面的方式写啊
好，这样，我们看一下面向对象多继承的用法：
那好，基于这种继承形式，我们是不是就要考虑了，我们上面对每个表的那几个接口操作，大家的处理数据的逻辑都差不多啊，而且你会发现，这么多表，我每个表的GET、PUT、DELETE、POST操作其实都差不多，基本上就两个地方再发生变化，这里我们称为两个变量。
Mixin混合类
关于数据逻辑处理的操作，drf帮我们封装好了几个Mixin类，我们来玩一下就行了，看代码：
序列化组件的类我们放到了一个单独的文件中，名字叫做serializer.py，内容如下
玩了这些drf混合类之后，你会发现，处理数据的相同的逻辑部分被省略了，代码简化了不少。
但是你看，我们上面只是写了一个publish表的操作，咱们还有好多其他表呢，他们的操作是不是也是GET、POST、DELETE、PUT等操作啊，所以你想想有没有优化的地方
然后你再看，还有优化的地方，上面这两个类里面的东西是一样的啊，能不能去重呢，当然可以了，一个类搞定，看写法
但是url要改一改了，看url的写法：
然后大家重启一下自己的程序，通过postman测一下，肯定可以的。
好，那这个东西怎么玩呢？有兴趣的，可以去看看源码~~~
其实源码中最关键的点是这个：
咱们上面做的都是数据接口，但是还有逻辑接口，比如登陆，像这种数据接口就直接写个 class Login(APIView):pass这样来搞就行了，封装的越简单，内部逻辑越复杂，自定制来就越复杂，所以关于不同的逻辑，我们就自己单写。
然后大家好奇吗，想不想去看看put\get\delete的操作中，url里面的那个pk命名路由，到底为啥叫pk，并且，它自己在内部怎么通过pk值找到对应的那个更新之前的原来的model对象的啊？