drf入门规范
web开发模式
# 前后端混合开发（前后端不分离）：返回的是html的内容，需要写模板
# 前后端分离：只专注于写后端接口，返回json，xml格式数据
# 前后端分离需要中间媒介：api接口
API接口
# 通过网络，规定了前后台信息交互规则的url链接，
# 就是前后端交流的媒介，双方协议好传输数据的格式
Restful规范(重点)
# REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征性状态转移）。 它首次出现在2000年Roy Fielding的博士论文中。
# uri：资源唯一标识(抽象概念)
# url：资源唯一定位(具体实现)
RESTful是Web API接口的设计规范风格，这种风格的理念认为后端开发任务就是提供数据的，对外提供的是数据资源的访问接口，尤其适用于前后端分离的应用模式中。
所以在定义接口时，客户端访问的URL路径就表示这种要操作的数据资源。
其实，任何一个框架都可以实现符合restful规范的API接口。
十条规范
1 数据的安全保障：
url链接一般都采用https协议进行传输
注：采用https协议，可以提高数据交互过程中的安全性
2 接口特征表现，一看就知道是个api接口
- 用api关键字标识接口url：
- [https://api.baidu.com](https://api.baidu.com/)
- https://www.baidu.com/api
注：看到api字眼，就代表该请求url链接是完成前后台数据交互的
-路飞的接口：https://api.luffycity.com/api/v1/course/free/
3 多数据版本共存
- 在url链接中标识数据版本
- https://api.baidu.com/v1
- https://api.baidu.com/v2
注：url链接中的v1、v2就是不同数据版本的体现（只有在一种数据资源有多版本情况下）
!!!4 数据即是资源，均使用名词（可复数）
- 接口一般都是完成前后台数据的交互，交互的数据我们称之为资源
- https://api.baidu.com/users
注：一般提倡用资源的复数形式，在url链接中奖励不要出现操作资源的动词
- 特殊的接口可以出现动词，因为这些接口一般没有一个明确的资源，或是动词就是接口的核心含义
- https://api.baidu.com/place/search
- https://api.baidu.com/login
!!!5 资源操作由请求方式决定（method）
- 操作资源一般都会涉及到增删改查，使用请求方式确定操作类型
- https://api.baidu.com/books - get请求：获取所有书
- https://api.baidu.com/books/1 - get请求：获取主键为1的书
- https://api.baidu.com/books - post请求：新增一本书书
- https://api.baidu.com/books/1 - put请求：整体修改主键为1的书
- https://api.baidu.com/books/1 - patch请求：局部修改主键为1的书
- https://api.baidu.com/books/1 - delete请求：删除主键为1的书
6 过滤，通过在url上传参的形式传递搜索条件，或者说查询参数(query_params)
- https://api.example.com/v1/zoos?limit=10：指定返回记录的数量
- https://api.example.com/v1/zoos?offset=10：指定返回记录的开始位置
- https://api.example.com/v1/zoos?page=2&per_page=100：指定第几页，以及每页的记录数
- https://api.example.com/v1/zoos?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序
- https://api.example.com/v1/zoos?animal_type_id=1：指定筛选条件
7 响应状态码
7.1 正常响应
- 响应状态码2xx
- 200：常规请求
- 201：创建成功
7.2 重定向响应
- 响应状态码3xx
- 301：永久重定向
- 302：暂时重定向
7.3 客户端异常
- 响应状态码4xx
- 403：请求无权限
- 404：请求路径不存在
- 405：请求方法不存在
7.4 服务器异常
- 响应状态码5xx
- 500：服务器异常
8 错误处理，应返回错误信息，error当做key
{
error: "无权限操作"
}
9 返回结果，针对不同操作，服务器向用户返回的结果应该符合以下规范
GET /collection：返回资源对象的列表（数组）
GET /collection/resource：返回单个资源对象
POST /collection：返回新生成的资源对象
PUT /collection/resource：返回完整的资源对象
PATCH /collection/resource：返回完整的资源对象
DELETE /collection/resource：返回一个空文档
10 需要url请求的资源需要访问资源的请求链接
- Hypermedia API，RESTful API最好做到Hypermedia，
- 即返回结果中提供链接，连向其他API方法，使得用户不查文档，也知道下一步应该做什么
{
"status": 0,
"msg": "ok",
"results":[
{
"name":"肯德基(罗餐厅)",
"img": "https://image.baidu.com/kfc/001.png"
}
...
]
}
drf的安装和简单使用
# 安装：pip install djangorestframework==3.10.3
# 使用
1 在setting.py 的app中注册
INSTALLED_APPS = [
'rest_framework'
]
2 在models.py中写表模型
class Book(models.Model):
nid=models.AutoField(primary_key=True)
name=models.CharField(max_length=32)
price=models.DecimalField(max_digits=5,decimal_places=2)
author=models.CharField(max_length=32)
3 新建一个序列化类（听不懂）
from rest_framework.serializers import ModelSerializer
from app01.models import Book
class BookModelSerializer(ModelSerializer):
class Meta:
model = Book
fields = "__all__"
4 在视图中写视图类
from rest_framework.viewsets import ModelViewSet
from .models import Book
from .ser import BookModelSerializer
class BooksViewSet(ModelViewSet):
queryset = Book.objects.all()
serializer_class = BookModelSerializer
5 写路由关系
from app01 import views
from rest_framework.routers import DefaultRouter
router = DefaultRouter() # 可以处理视图的路由器
router.register('book', views.BooksViewSet) # 向路由器中注册视图集
# 将路由器中的所以路由信息追到到django的路由列表中
urlpatterns = [
path('admin/', admin.site.urls),
]
#这是什么意思？两个列表相加
# router.urls 列表
urlpatterns += router.urls
6 启动，在postman中测试即可
CBV源码阅读
# django的CBV继承了View
from django.views import View
# 请求经历的阶段，路由层 urls.py
url(r'^books/', views.BookView.as_view())
# 此处as_view()是一个类方法，会在程序跑起来之后返回一个函数的内存地址
# 请求来了，如果路径匹配，给这个返回的函数加括号并传request参数(本次请求对象)调用
# 这个返回出来的函数内部实例化了一个当前视图类BookView的对象，并调用这个对象的dispatch方法
# 这个对象即BookView类没有定义dispatch方法，按照属性查找顺序，使用View的dispatch方法
# View类内部的dispatch方法通过反射来回去这个对象的请求方法，get,post等，并调用。
# 这这个过程中，request都是本次请求的request对象
drf的APIView源码
from rest_framework.views import APIView
url(r'^books/', views.BookView.as_view()),
# urls.py中使用的as_view()是APIView的as_view方法，使用的还都是当前请求的原生request
# APIView的as_view方法内部通过super重用了父类View的as_view()方法，到此，request还是当前请求的原生request。不过，APIView的as_view方法做的事情是通过csrf_exempt()将view解除了csrf的认证，即以后所有的请求方法都不做csrf的认证。
# 然后as_view()返回的当前APIView对象，调用dispatch方法，此时调用的是APIView对象的dispatch方法而不是View的dispatch方法
# APIView对象的dispathc方法内，初始化一个新的drf的Request对象覆盖原生的request请求对象；把原生的reuqest对象当做drf的Request对象的一个属性。
# 至此，请求流程后期使用的request都是drf的Request对象，而不再是原生的当前请求request对象
# 另外，drf的Request对象内部通过__getattr__魔法方法，使得用户访问原生request的属性时通过反射来访问，这样巧妙的将新的drf的Request对象不知不觉地伪装成了原生的request对象
# 然后通过APIView对象的initial()方法，实现认证、权限、流量的控制
# 然后，在APIView对象的dispatch的方法内通过类似View的dispatch的方法，通过反射获取传入新的request参数并执行得到结果
# 最后，将response再封装一层drf的外衣，返回出去
总结
# step0：
程序运行时，执行路由层url匹配关系处APIView的as_view()方法，替换成一个APIView视图对象，并且通过csrf_exempt装饰器的作用去除了所有请求方式的csrf认证
# (重用View的as_view + 派生去除csrf认证)
# step1:
当请求匹配成功时，将当前django原生请求request对象传给替换后的视图view函数, 并加括号执行。
# step2:
加括号执行的内部调用APIView的dispatch方法，该dispatch方法内部初始用drf内部的Request对象，替换原声当前请求request对象。
# step3:
通过反射有请求方式选择相关方法并执行，返回响应结果response
# step4:
最后再在django原生response的基础上，进一步封装成drf的Response
浙公网安备 33010602011771号