更新了Django部分的文档
|
@ -51,7 +51,7 @@ REST_FRAMEWORK = {
|
|||
# 配置默认页面大小
|
||||
# 'PAGE_SIZE': 10,
|
||||
# 配置默认的分页类
|
||||
# 'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.PageNumberPagination',
|
||||
# 'DEFAULT_PAGINATION_CLASS': '...',
|
||||
# 配置异常处理器
|
||||
# 'EXCEPTION_HANDLER': '...',
|
||||
# 配置默认解析器
|
||||
|
|
|
@ -1,10 +1,34 @@
|
|||
## RESTful架构和DRF进阶
|
||||
|
||||
除了上一节讲到的方法,使用DRF创建REST风格的数据接口还有CBV(基于类的视图)的方式。使用CBV创建数据接口的特点是代码简单,开发效率高,但是没有FBV(基于函数的视图)灵活,因为使用FBV的方式,数据接口对应的视图函数执行什么样的代码以及返回什么的数据是高度可定制的。下面我们以定制学科的数据接口为例,讲解通过CBV方式定制数据接口的具体做法。
|
||||
除了上一节讲到的方法,使用DRF创建REST风格的数据接口也可以通过CBV(基于类的视图)的方式。使用CBV创建数据接口的特点是代码简单,开发效率高,但是没有FBV(基于函数的视图)灵活,因为使用FBV的方式,数据接口对应的视图函数执行什么样的代码以及返回什么的数据是高度可定制的。下面我们以定制学科的数据接口为例,讲解通过CBV方式定制数据接口的具体做法。
|
||||
|
||||
### 使用ModelViewSet
|
||||
### 使用CBV
|
||||
|
||||
修改之前项目中的`polls/views.py`,去掉`show_subjects`视图函数,添加一个名为`SubjectViewSet`的类。
|
||||
#### 继承APIView的子类
|
||||
|
||||
修改之前项目中的`polls/views.py`,去掉`show_subjects`视图函数,添加一个名为`SubjectView`的类,该类继承自`ListAPIView`,`ListAPIView`能接收GET请求,它封装了获取数据列表并返回JSON数据的`get`方法。`ListAPIView`是`APIView` 的子类,`APIView`还有很多的子类,例如`CreateAPIView`可以支持POST请求,`UpdateAPIView`可以支持PUT和PATCH请求,`DestoryAPIView`可以支持DELETE请求。`SubjectView` 的代码如下所示。
|
||||
|
||||
```Python
|
||||
class SubjectView(ListAPIView):
|
||||
# 通过queryset指定如何获取学科数据
|
||||
queryset = Subject.objects.all()
|
||||
# 通过serializer_class指定如何序列化学科数据
|
||||
serializer_class = SubjectSerializer
|
||||
```
|
||||
|
||||
刚才说过,由于`SubjectView`的父类`ListAPIView`已经实现了`get`方法来处理获取学科列表的GET请求,所以我们只需要声明如何获取学科数据以及如何序列化学科数据,前者用`queryset`属性指定,后者用`serializer_class`属性指定。要使用上面的`SubjectView`,需要修改`urls.py`文件,如下所示。
|
||||
|
||||
```Python
|
||||
urlpatterns = [
|
||||
path('api/subjects/', SubjectView.as_view()),
|
||||
]
|
||||
```
|
||||
|
||||
很显然,上面的做法较之之前讲到的FBV要简单很多。
|
||||
|
||||
#### 继承ModelViewSet
|
||||
|
||||
如果学科对应的数据接口需要支持GET、POST、PUT、PATCH、DELETE请求来支持对学科资源的获取、新增、更新、删除操作,更为简单的做法是继承`ModelViewSet`来编写学科视图类。再次修改`polls/views.py`文件,去掉`SubjectView`类,添加一个名为`SubjectViewSet`的类,代码如下所示。
|
||||
|
||||
```Python
|
||||
class SubjectViewSet(ModelViewSet):
|
||||
|
@ -12,7 +36,7 @@ class SubjectViewSet(ModelViewSet):
|
|||
serializer_class = SubjectSerializer
|
||||
```
|
||||
|
||||
通过查看`ModelViewSet`类的源代码可以发现,该类共有6个父类,其中前5个父类分别实现创建学科、获取指定学科、更新指定学科、删除指定学科和获取学科列表的数据接口,对应的方法分别是`create`、`retrieve`、`update`、`destroy`和`list`。由于ModelViewSet的父类中已经实现了这些方法,所以我们几乎没有编写任何代码就完成了学科数据接口的开发,我们要做的仅仅是指出如何获取到学科数据(通过`queryset`属性指定)以及如何序列化学科数据(通过`serializer_class`属性指定)。
|
||||
通过查看`ModelViewSet`类的源代码可以发现,该类共有6个父类,其中前5个父类分别实现对POST(新增学科)、GET(获取指定学科)、PUT/PATCH(更新学科)、DELETE(删除学科)和GET(获取学科列表)操作的支持,对应的方法分别是`create`、`retrieve`、`update`、`destroy`和`list`。由于`ModelViewSet`的父类中已经实现了这些方法,所以我们几乎没有编写任何代码就完成了学科数据全套接口的开发,我们要做的仅仅是指出如何获取到数据(通过`queryset`属性指定)以及如何序列化数据(通过`serializer_class`属性指定),这一点跟上面继承`APIView`的子类做法是一致的。
|
||||
|
||||
```Python
|
||||
class ModelViewSet(mixins.CreateModelMixin,
|
||||
|
@ -28,7 +52,7 @@ class ModelViewSet(mixins.CreateModelMixin,
|
|||
pass
|
||||
```
|
||||
|
||||
要使用上面的`SubjectViewSet`,需要在`urls.py`文件中进行URL映射。不同于之前的视图函数映射URL的方式,我们需要先创建一个路由器对象并通过该对象注册`SubjectViewSet`,然后将注册成功后生成的URL一并添加到`urlspattern`列表中,代码如下所示。
|
||||
要使用上面的`SubjectViewSet`,需要在`urls.py`文件中进行URL映射。由于`ModelViewSet`相当于是多个视图函数的汇总,所以不同于之前映射URL的方式,我们需要先创建一个路由器并通过它注册`SubjectViewSet`,然后将注册成功后生成的URL一并添加到`urlspattern`列表中,代码如下所示。
|
||||
|
||||
```Python
|
||||
router = DefaultRouter()
|
||||
|
@ -36,5 +60,9 @@ router.register('api/subjects', SubjectViewSet)
|
|||
urlpatterns += router.urls
|
||||
```
|
||||
|
||||
### 使用APIView的子类
|
||||
除了`ModelViewSet`类外,DRF还提供了一个名为`ReadOnlyModelViewSet` 的类,从名字上就可以看出,该类是只读视图的集合,也就意味着,继承该类定制的数据接口只能支持GET请求,也就是获取单个资源和资源列表的请求。
|
||||
|
||||
### 数据分页
|
||||
|
||||
### 数据筛选
|
||||
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
## 使用缓存
|
||||
|
||||
|
||||
通常情况下,Web应用的性能瓶颈都会出现在关系型数据库上,当并发访问量较大时,如果所有的请求都需要通过关系型数据库完成数据持久化操作,那么数据库一定会不堪重负。优化Web应用性能最为重要的一点就是使用缓存,就是把哪些数据体量不大但访问频率非常高的数据提前加载到缓存服务器中,这又是典型的空间换时间的方法。通常缓存服务器都是直接将数据置于内存中而且使用了非常高效的数据存取策略(例如:键值对方式),在读写性能上是远远优于传统的关系型数据库的,因此我们可以让Web应用接入缓存服务器来优化其性能,一个非常好的选择就是使用Redis。
|
||||
|
||||
|
|
|
@ -0,0 +1,3 @@
|
|||
## 接入三方平台
|
||||
|
||||
在Web应用的开发过程中,有一些任务并不是我们自己能够完成的。
|
|
@ -1,4 +0,0 @@
|
|||
## 文件上传
|
||||
|
||||
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
## 推荐系统实战
|
||||
|
|
@ -2,10 +2,6 @@
|
|||
|
||||
$k$最近邻(简称kNN,k-Nearest Neighbor)是Cover和Hart在1968年提出的一种简单的监督学习算法,可用于字符识别、文本分类、图像识别等领域。kNN的工作机制非常简单:给定测试样本,基于某种距离度量(如:欧式距离、曼哈顿距离等)找出训练集中与其最接近的$k$个训练样本,然后基于这$k$个“最近邻居”的信息来进行预测。对于分类任务,可以在$k$个最近邻居中选择出现次数最多的类别标签作为预测的结果;对于回归任务,可以使用$k$个最近邻居实际输出(目标值)的平均值作为预测的结果,当然也可以根据距离的远近进行加权平均,距离越近的样本权重值就越大。
|
||||
|
||||
### 距离的度量
|
||||
|
||||
|
||||
|
||||
### 案例:电影分类预测
|
||||
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
## Tensorflow入门
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
## Kaggle项目实战
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
## 天池大数据项目实战
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
## 推荐系统实战(1)
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
## 推荐系统实战(2)
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
## 推荐系统实战(3)
|
||||
|
Before Width: | Height: | Size: 310 KiB After Width: | Height: | Size: 310 KiB |
Before Width: | Height: | Size: 710 KiB After Width: | Height: | Size: 710 KiB |
Before Width: | Height: | Size: 168 KiB After Width: | Height: | Size: 168 KiB |
Before Width: | Height: | Size: 7.9 KiB After Width: | Height: | Size: 7.9 KiB |
Before Width: | Height: | Size: 174 KiB After Width: | Height: | Size: 174 KiB |
Before Width: | Height: | Size: 173 KiB After Width: | Height: | Size: 173 KiB |
51
README.md
|
@ -308,7 +308,12 @@ Python在以下领域都有用武之地。
|
|||
|
||||
### Day56~60 - [用FastAPI开发数据接口](./Day56-60/56-60.用FastAPI开发数据接口.md)
|
||||
|
||||
-
|
||||
- FastAPI五分钟上手
|
||||
- 请求和响应
|
||||
- 接入关系型数据库
|
||||
- 依赖注入
|
||||
- 中间件
|
||||
- 异步化
|
||||
- 虚拟化部署(Docker)
|
||||
- 项目实战:车辆违章查询项目
|
||||
|
||||
|
@ -355,29 +360,49 @@ Python在以下领域都有用武之地。
|
|||
|
||||
#### Day70 - [数据分析项目实战](./Day66-70/70.数据分析项目实战.md)
|
||||
|
||||
### Day71~90 - [机器学习和深度学习](./Day71-90)
|
||||
### Day71~85 - [机器学习和深度学习](./Day71-85)
|
||||
|
||||
#### Day71 - [机器学习基础](./Day71-90/71.机器学习基础.md)
|
||||
#### Day71 - [机器学习基础](./Day71-85/71.机器学习基础.md)
|
||||
|
||||
#### Day72 - [k最近邻分类](./Day71-90/72.k最近邻分类.md)
|
||||
#### Day72 - [k最近邻分类](./Day71-85/72.k最近邻分类.md)
|
||||
|
||||
#### Day73 - [决策树](./Day71-90/73.决策树.md)
|
||||
#### Day73 - [决策树](./Day71-85/73.决策树.md)
|
||||
|
||||
#### Day74 - [贝叶斯分类](./Day71-90/74.贝叶斯分类.md)
|
||||
#### Day74 - [贝叶斯分类](./Day71-85/74.贝叶斯分类.md)
|
||||
|
||||
#### Day75 - [支持向量机](./Day71-90/75.支持向量机.md)
|
||||
#### Day75 - [支持向量机](./Day71-85/75.支持向量机.md)
|
||||
|
||||
#### Day76 - [K-均值聚类](./Day71-90/76.K-均值聚类.md)
|
||||
#### Day76 - [K-均值聚类](./Day71-85/76.K-均值聚类.md)
|
||||
|
||||
#### Day77 - [回归分析](./Day71-90/77.回归分析.md)
|
||||
#### Day77 - [回归分析](./Day71-85/77.回归分析.md)
|
||||
|
||||
#### Day78 - [Tensorflow入门](./Day71-90/78.Tensorflow入门.md)
|
||||
#### Day78 - [深度学习入门](./Day71-85/78.深度学习入门.md)
|
||||
|
||||
#### Day79 - [Tensorflow实战](./Day71-90/79.Tensorflow实战.md)
|
||||
#### Day79 - [Tensorflow概述](./Day71-85/79.Tensorflow概述.md)
|
||||
|
||||
#### Day80 - [推荐系统实战](./Day71-90/80.推荐系统实战.md)
|
||||
#### Day80 - [Tensorflow实战](./Day71-85/79.Tensorflow实战.md)
|
||||
|
||||
### Day81~90 - [大数据分析实战](./Day81-90)
|
||||
#### Day81 - [Kaggle项目实战](./Day71-85/81.Kaggle项目实战.md)
|
||||
|
||||
#### Day82 - [天池大数据项目实战](./Day71-85/82.天池大数据项目实战.md)
|
||||
|
||||
#### Day83 - [推荐系统实战-1](./Day71-85/83.推荐系统实战-1.md)
|
||||
|
||||
#### Day84 - [推荐系统实战-2](./Day71-85/84.推荐系统实战-2.md)
|
||||
|
||||
#### Day85 - [推荐系统实战-3](./Day71-85/85.推荐系统实战-3.md)
|
||||
|
||||
### Day86~90 - [大数据分析概述](./Day86-90)
|
||||
|
||||
####Day86 - [大数据概述]()
|
||||
|
||||
#### Day87 - [Hive查询]()
|
||||
|
||||
#### Day88 - [PySpark和离线数据处理]()
|
||||
|
||||
#### Day89 - [Flink和流式数据处理]()
|
||||
|
||||
#### Day90 - [大数据分析项目实战]()
|
||||
|
||||
### Day91~100 - [团队项目开发](./Day91-100)
|
||||
|
||||
|
|