Django REST framework复习

与其说是复习，不如说是重新的学了一遍。忘光了诶。想到哪写到哪。

请求和响应

前后端不分离的交互有可能是网页的请求，也有可能是数据的操作请求。而前后端分离的交互只需要处理数据，网页url请求由前端进行处理渲染。

传统的django通过form表单来实现用户数据交互。使用了前后端分离之后，django不得不舍弃form，转而去监听前端抛过来的请求，从而修改数据。这也是REST框架的核心部分。DRF提供了：

• 请求对象（Request objects）
• 响应对象（Response objects）
• 状态码再封装（Status codes）

这三个组件来帮助我们处理请求。DRF在视图层提供了两个有用的封装以配合他们使用：

• 用于基于函数视图的@api_view装饰器
• 用于基于类视图的APIView类。

组合在一起这段提供了一个参考样例，告诉我们怎么把上述五个东西相互组合食用。

基于类的视图

正如上面提到的，我们有两种方式来编写视图：

• 可以使用函数，在内部使if-else判断请求的类型，并分别处理；
• 可以使用类，在内部提供get和post等方法，分别用于处理各种类型的请求。

效果上后者可能更加简洁。而且可以更轻松的去复用代码。

mixins和generics视图

我并不喜欢这两个东西，他们高度的集成了我们对于数据的频繁操作：增删改查。但是他们可读性太差了，泛用性太低。即使是可以通过重写方法进行覆盖和定制化，但总归不如最朴素的类视图看的明白。正如drf文档中所说的，使用常规视图和 URL 配置文件更加明确，初学者更容易理解。我认为这种高级的视图更适合于部署在高度重构的生产环境中。

Format suffixes（格式后缀）

对于API来说，有一种频繁的使用方式就是访问xxx.json或者xxx.后缀。在路由中使用正则来匹配这种后缀是很容易出错的，所以DRF提供了一个format关键字，它可以用来自动的识别这些后缀，只需要在allowed列表中加入有效格式的后缀就可以使用了。

当然，目前我是用不到。