drf框架,全程: django-rest framework , rest是插件名字,django插件的名字叫rest,framework是框架的意思
web接口组成: url: 长得像返回数据(api.baidu.map/search)的url链接,长得像还不一定就是接口,还要有请求参数,接口一定要告诉前台要给我传什么参数,比如登录接口要传用户名和密码,请求参数: 前台按照指定的key提供数据给后台, 为什么按指定的key提供,因为后台在request中get的时候按写死的字符串,前端不按照这些字符串提,后端就提不出来,所以后台占主导,后台要什么前台就返回什么,另外响应数据,比如注册,注册成功的时候起码要返回一个注册成功.我才知道注册侧成功了,后台与用户交互的信息,前台应该多少知道点,玩意没有返回给前端,前端就会断了,响应数据就是后台与数据库交互后将数据反馈给前端,综合以上分析,可以得出结论,接口就是一个规定了请求参数的url,访问后能返回对应结果.
接口规范: 为了采用不同的后台语言,也能使用同样的接口获取到同样的数据
如何学习: 接口规范是规范化书写接口的,写接口要写url, 响应数据.
注意: 如果将请求参数也纳入考量范围,那就是在写接口文档,这个接口文档最主要的还是给前台看
最主要的接口规范还是两大部分:
url: 用api关键字标识接口url(api.baidu.com | www.baidu.com/api ); 接口数据安全性决定优先选择https协议; 如果一个接口有多版本存在,需要在url中标识体现; 接口操作的数据源(api.baidu.com/books)称之为资源(book), 在url中一般采用资源复数形式,一个接口可以概括对资源的多种操作方式,(原来学的是一个视图对应的一个接口,一个接口做一个操作,从本节起就要写cbv,一个类中写一堆方法,一个方法一项业务逻辑,就属于一个类,接口就是跟类进行绑定的,那么代码怎么组装,我们的接口就怎么组装,也就是一个url对应一个类), 以前的就是这种: api.baidu.com/delete_book, 从现在起就要写成api.baidu.com/books,操作单个资源的话还可以这样写: api.baidu.com/books/(pk),比如增加或者删除某个书; 这里就有疑问了,请求方式有多种,用一个url处理如何保证不混乱-通过请求方式标识操作资源的方式:
/books 发送的是get请求 获取所有
/books post 增加一个(多个)
/books/(pk) delete 删除一个
/books(pk) put 整体更新一个
/books(pk) patch 局部更新一个
资源往往涉及数据的各种操作方式-筛选,排序,限制 比如api.baidu.com/books/?search=西&ordering=-price&limit=3
search=西 是查询跟'西'有关系的,ordering=-price 价格降序 limit=3,三位数
响应数据:
1. http请求的响应会有响应状态码,接口用来返回操作的资源数据, 可以拥有操作数据结果的状态码;
注意: 资源状态码不像http状态码, 一般都是后台与前台或是客户约定的
2. 资源的状态码文字提示 status OK '账号有误' '密码有误' '用户锁定' ;
3. 资源本身 results ;
注意: 删除资源成功不做任何数据返回(返回空字符串)
4. 不能直接返回的资源(子资源, 图片, 视频等资源), 返回该资源的url链接
主路由: url.py
from django.conf.urls import url, include
from django.contrib import admin
urlpatterns = [
url(r'^admin/', admin.site.urls),
# 路由分发
url(r'^api/', include('api.urls'))
]
api组件(在项目的目录下建立的api的包)的子路由: api/url.py
from django.conf.urls import url
from . import views
urlpatterns = [
url(r'^books/', views.Book.as_view()),
url(r'^books/(?P.*)/$', views.Book.as_view()),
]
模型层: model.py
from django.db import models
class Book(models.Model):
title = models.CharField(max_length=64)
price = models.DecimalField(max_digits=5, decimal_places=2)
class Meta:
db_table = 'old_boy_book'
verbose_name = '书籍' # 告诉后台管理将book转化为汉字"书籍"
verbose_name_plural = verbose_name # 去掉后台管理的book后面的s
def __str__(self):
return '《%s》' % self.title
后台层: admin.py
from django.contrib import admin
from . import models
admin.site.register(models.Book)
数据库迁移
>: python manage.py makemigrations
>: python manage.py migrrate
>: python manage.py createsuperuser
视图层: views.py
from django.http import JsonResponse
from django.views import View
from . import models
# 六大基础接口:获取一个 获取所有 增加一个 删除一个 整体更新一个 局部更新一个
# 十大接口:群增 群删 整体改群改 局部改群改
class Book(View):
def get(self, request, *args, **kwargs):
pk = kwargs.get('pk')
if not pk: # 群查
# 操作数据库
book_obj_list = models.Book.objects.all() # 没有pk就是查所有
# 序列化过程
book_list = []
for obj in book_obj_list:
dic = {}
dic['title'] = obj.title # 将对象转化为字典
dic['price'] = obj.price
book_list.append(dic) # 每次循环都产生一个
# 响应数据
return JsonResponse({
'status': 0,
'msg': 'ok',
'results': book_list
}, json_dumps_params={'ensure_ascii': False}) # 将页面上的字符串进行反序列化
else: # 单查
book_dic = models.Book.objects.filter(pk=pk).values('title', 'price').first()
if book_dic:
return JsonResponse({
'status': 0,
'msg': 'ok',
'results': book_dic
}, json_dumps_params={'ensure_ascii': False})
return JsonResponse({
'status': 2,
'msg': '无结果',
}, json_dumps_params={'ensure_ascii': False})
postman可以完成不同方式的请求:get | post | put ...
postman发送数据包有三种方式:form-data | urlencoding | json
原生django对urlencoding方式数据兼容最好
def post(self, request, *args, **kwargs):
前台通过urlencoding方式提交数据
try:
book_obj = models.Book.objects.create(**request.POST.dict())
if book_obj:
return JsonResponse({
'status': 0,
'msg': 'ok',
'results': {'title': book_obj.title, 'price': book_obj.price}
}, json_dumps_params={'ensure_ascii': False})
except:
return JsonResponse({
'status': 1,
'msg': '参数有误',
}, json_dumps_params={'ensure_ascii': False})
return JsonResponse({
'status': 2,
'msg': '新增失败',
}, json_dumps_params={'ensure_ascii': False})
get请求,携带参数采用Params
postman可以完成不同方式的请求,原生django对urlencoding方式数据兼容最好
post等请求,可以使用postman,提交数据包可以采用三种方式:form-date、urlencoding、json, 这些在body内发送数据
安装:
>: pip3 install djangorestframework
安装完成后去seetings注册,没有注册app可以访问里面的类,但是数据库迁移的时候无法检测到model ,在settings里面没有注册的话,有时候逻辑是可以使用的,但是有些功能是使用不了的,pep8规定在最上方写系统的,接下来写第三方的,最后写自己的
drf框架规矩的封装风格
from rest_framework.views import APIView # 完成视图
from rest_framework.response import Response # 响应数据
from rest_framework.request import Request # 请求数据
from rest_framework.serializers import Serializer # 序列化类
from rest_framework.settings import APISettings
from rest_framework.filters import SearchFilter # 查询过滤器
from rest_framework.pagination import PageNumberPagination # 分页器
from rest_framework.authentication import TokenAuthentication # auth认证
from rest_framework.permissions import IsAuthenticated # 权限认证
from rest_framework.throttling import SimpleRateThrottle # 频率
class Test(APIView):
def get(self, request, *args, **kwargs):
return Response('drf get ok')
drf请求生命周期
1) 请求走的是APIView的as_view函数
2) 在APIView的as_view调用父类(django原生)的as_view,还禁用了 csrf 认证
3) 在父类的as_view中dispatch方法请求走的又是APIView的dispatch
4) 完成任务方法交给视图类的请求函数处理,得到请求的响应结果,返回给前台
源码入口:
APIView类的dispatch方法中:request = self.initialize_request(request, *args, **kwargs)
源码分析:
# 二次封装得到def的request对象
request = self.initialize_request(request, *args, **kwargs) 点进去
# 在rest_framework.request.Request实例化方法中
self._request = request 将原生request作为新request的_request属性
# 在rest_framework.request.Request的__getattr__方法中
try:
return getattr(self._request, attr) # 访问属性完全兼容原生request
except AttributeError:
return self.__getattribute__(attr)
重点总结:
1) drf 对原生request做了二次封装,request._request就是原生request
2) 原生request对象的属性和方法都可以被drf的request对象直接访问(兼容)
3) drf请求的所有url拼接参数均被解析到query_params中,所有数据包数据都被解析到data中
class Test(APIView):
def get(self, request, *args, **kwargs):
# url拼接的参数
print(request._request.GET) # 二次封装方式
print(request.GET) # 兼容
print(request.query_params) # 拓展
return Response('drf get ok')
def post(self, request, *args, **kwargs):
# 所有请求方式携带的数据包
print(request._request.POST) # 二次封装方式
print(request.POST) # 兼容
print(request.data) # 拓展,兼容性最强,三种数据方式都可以
print(request.query_params)
return Response('drf post ok')
源码入口:
APIView类的dispatch方法中:self.response = self.finalize_response(request, response, *args, **kwargs)
源码分析
最后解析reponse对象数据
self.response = self.finalize_response(request, response, *args, **kwargs) 点进去
拿到运行的解析类的对象们
neg = self.perform_content_negotiation(request, force=True) 点进去
获得解析类对象
renderers = self.get_renderers() 点进去
从视图类中得到renderer_classes请求类,如何实例化一个个对象形参解析类对象列表
return [renderer() for renderer in self.renderer_classes]
重点:self.renderer_classes获取renderer_classes的顺序
自己视图类的类属性(局部配置) =>
APIView类的类属性设置 =>
自己配置文件的DEFAULT_RENDERER_CLASSES(全局配置) =>
drf配置文件的DEFAULT_RENDERER_CLASSES
全局配置: 所有视图类统一处理,在项目的settings.py中
REST_FRAMEWORK = {
# drf提供的渲染类
'DEFAULT_RENDERER_CLASSES': [
'rest_framework.renderers.JSONRenderer',
'rest_framework.renderers.BrowsableAPIRenderer',
],
}
局部配置: 某一个或一些实体类单独处理,在views.py视图类中提供对应的类属性
class Test(APIView):
def get(self, request, *args, **kwargs):
return Response('drf get ok')
def post(self, request, *args, **kwargs):
return Response('drf post ok')
# 在setting.py中配置REST_FRAMEWORK,完成的是全局配置,所有接口统一处理
# 如果只有部分接口特殊化,可以完成 - 局部配置
from rest_framework.renderers import JSONRenderer
class Test2(APIView):
# 局部配置
renderer_classes = [JSONRenderer]
def get(self, request, *args, **kwargs):
return Response('drf get ok 2')
def post(self, request, *args, **kwargs):
return Response('drf post ok 2')