DRF (Django REST framework) 框架介绍(1)
Web应用模式
在开发Web应用中,有两种应用模式:
- 前后端不分离
- 前后端分离
1 前后端不分离
在前后端不分离的应用模式中,前端页面看到的效果都是由后端控制,由后端渲染页面或重定向,也就是后端需要控制前端的展示,前端与后端的耦合度很高。
这种应用模式比较适合纯网页应用,但是当后端对接App时,App可能并不需要后端返回一个HTML网页,而仅仅是数据本身,所以后端原本返回网页的接口不再适用于前端App应用,为了对接App后端还需再开发一套接口。
2 前后端分离
在前后端分离的应用模式中,后端仅返回前端所需的数据,不再渲染HTML页面,不再控制前端的效果。至于前端用户看到什么效果,从后端请求的数据如何加载到前端中,都由前端自己决定,网页有网页的处理方式,App有App的处理方式,但无论哪种前端,所需的数据基本相同,后端仅需开发一套逻辑对外提供数据即可。
在前后端分离的应用模式中 ,前端与后端的耦合度相对较低。
在前后端分离的应用模式中,我们通常将后端开发的每个视图都称为一个接口,或者API,前端通过访问接口来对数据进行增删改查。
认识RESTful
即Representational State Transfer的缩写。维基百科称其为“具象状态传输”,国内大部分人理解为“表现层状态转化”。
RESTful是一种开发理念。维基百科说:REST是设计风格而不是标准。 REST描述的是在网络中client和server的一种交互形式;REST本身不实用,实用的是如何设计 RESTful API(REST风格的网络接口),一种万维网软件架构风格。
我们先来具体看下RESTful风格的url,比如我要查询商品信息,那么
非REST的url:http://.../queryGoods?id=1001&type=t01
REST的url: http://.../t01/goods/1001
可以看出REST特点:url简洁,将参数通过url传到服务器,而传统的url比较啰嗦,而且现实中浏览器地址栏会拼接一大串字符,想必你们都见过吧。但是采用REST的风格就会好很多,现在很多的网站已经采用这种风格了,这也是潮流方向,典型的就是url的短化转换。
那么,到底什么是RESTFul架构: 如果一个架构符合REST原则,就称它为RESTful架构。
要理解RESTful架构,理解Representational State Transfer这三个单词的意思。
-
具象的,就是指表现层,要表现的对象也就是“资源”,什么是资源呢?网站就是资源共享的东西,客户端(浏览器)访问web服务器,所获取的就叫资源。比如html,txt,json,图片,视频等等。
-
表现,比如,文本可以用txt格式表现,也可以用HTML格式、XML格式、JSON格式表现,甚至可以采用二进制格式;图片可以用JPG格式表现,也可以用PNG格式表现。
浏览器通过URL确定一个资源,但是如何确定它的具体表现形式呢?应该在HTTP请求的头信息中用Accept和Content-Type字段指定,这两个字段才是对"表现层"的描述。
-
状态转换, 就是客户端和服务器互动的一个过程,在这个过程中, 势必涉及到数据和状态的变化, 这种变化叫做状态转换。
互联网通信协议HTTP协议,客户端访问必然使用HTTP协议,如果客户端想要操作服务器,必须通过某种手段,让服务器端发生"状态转化"(State Transfer)。
HTTP协议实际上含有4个表示操作方式的动词,分别是 GET,POST,PUT,DELETE,他们分别对应四种操作。GET用于获取资源,POST用于新建资源,PUT用于更新资源,DElETE用于删除资源。GET和POST是表单提交的两种基本方式,比较常见,而PUT和DElETE不太常用。
而且HTTP协议是一种无状态协议,这样就必须把所有的状态都保存在服务器端。因此,如果客户端想要操作服务器,必须通过某种手段,让服务器端发生"状态转化"(State Transfer)
总结
综合上面的解释,RESTful架构就是:
- 每一个URL代表一种资源;
- 客户端和服务器之间,传递这种资源的某种表现层;
- 客户端通过四个HTTP动词,对服务器端资源进行操作,实现"表现层状态转化"。
RESTful设计方法
1. 域名
应该尽量将API部署在专用域名之下。
https://api.example.com
如果确定API很简单,不会有进一步扩展,可以考虑放在主域名下。
https://example.org/api/
2. 版本(Versioning)
应该将API的版本号放入URL。
http://www.example.com/app/1.0/foo
http://www.example.com/app/1.1/foo
http://www.example.com/app/2.0/foo
另一种做法是,将版本号放在HTTP头信息中,但不如放入URL方便和直观。Github采用这种做法。
因为不同的版本,可以理解成同一种资源的不同表现形式,所以应该采用同一个URL。版本号可以在HTTP请求头信息的Accept字段中进行区分(参见Versioning REST Services):
Accept: vnd.example-com.foo+json; version=1.0
Accept: vnd.example-com.foo+json; version=1.1
Accept: vnd.example-com.foo+json; version=2.0
3. 路径(Endpoint)
路径又称"终点"(endpoint),表示API的具体网址,每个网址代表一种资源(resource)
(1) 资源作为网址,只能有名词,不能有动词,而且所用的名词往往与数据库的表名对应。
举例来说,以下是不好的例子:
/getProducts
/listOrders
/retreiveClientByOrder?orderId=1
对于一个简洁结构,你应该始终用名词。 此外,利用的HTTP方法可以分离网址中的资源名称的操作。
GET /products :将返回所有产品清单
POST /products :将产品新建到集合
GET /products/4 :将获取产品 4
PATCH(或)PUT /products/4 :将更新产品 4
(2) API中的名词应该使用复数。无论子资源或者所有资源。
举例来说,获取产品的API可以这样定义
获取单个产品:http://127.0.0.1:8080/AppName/rest/products/1
获取所有产品: http://127.0.0.1:8080/AppName/rest/products
3. HTTP动词
对于资源的具体操作类型,由HTTP动词表示。
常用的HTTP动词有下面四个(括号里是对应的SQL命令)。
- GET(SELECT):从服务器取出资源(一项或多项)。
- POST(CREATE):在服务器新建一个资源。
- PUT(UPDATE):在服务器更新资源(客户端提供改变后的完整资源)。
- DELETE(DELETE):从服务器删除资源。
还有三个不常用的HTTP动词。
- PATCH(UPDATE):在服务器更新(更新)资源(客户端提供改变的属性)。
- HEAD:获取资源的元数据。
- OPTIONS:获取信息,关于资源的哪些属性是客户端可以改变的。
下面是一些例子。
GET /zoos:列出所有动物园
POST /zoos:新建一个动物园(上传文件)
GET /zoos/ID:获取某个指定动物园的信息
PUT /zoos/ID:更新某个指定动物园的信息(提供该动物园的全部信息)
PATCH /zoos/ID:更新某个指定动物园的信息(提供该动物园的部分信息)
DELETE /zoos/ID:删除某个动物园
GET /zoos/ID/animals:列出某个指定动物园的所有动物
DELETE /zoos/ID/animals/ID:删除某个指定动物园的指定动物
4. 过滤信息(Filtering)
如果记录数量很多,服务器不可能都将它们返回给用户。API应该提供参数,过滤返回结果。
下面是一些常见的参数。
?limit=10:指定返回记录的数量
?offset=10:指定返回记录的开始位置。
?page=2&per_page=100:指定第几页,以及每页的记录数。
?sortby=name&order=asc:指定返回结果按照哪个属性排序,以及排序顺序。
?animal_type_id=1:指定筛选条件
参数的设计允许存在冗余,即允许API路径和URL参数偶尔有重复。比如,GET /zoos/ID/animals 与 GET /animals?zoo_id=ID 的含义是相同的。
6. 状态码(Status Codes)
服务器向用户返回的状态码和提示信息,常见的有以下一些(方括号中是该状态码对应的HTTP动词)。
- 200 OK - [GET]:服务器成功返回用户请求的数据
- 201 CREATED - [POST/PUT/PATCH]:用户新建或修改数据成功。
- 202 Accepted - [*]:表示一个请求已经进入后台排队(异步任务)
- 204 NO CONTENT - [DELETE]:用户删除数据成功。
- 400 INVALID REQUEST - [POST/PUT/PATCH]:用户发出的请求有错误,服务器没有进行新建或修改数据的操作
- 401 Unauthorized - [*]:表示用户没有权限(令牌、用户名、密码错误)。
- 403 Forbidden - [*] 表示用户得到授权(与401错误相对),但是访问是被禁止的。
- 404 NOT FOUND - [*]:用户发出的请求针对的是不存在的记录,服务器没有进行操作,该操作是幂等的。
- 406 Not Acceptable - [GET]:用户请求的格式不可得(比如用户请求JSON格式,但是只有XML格式)。
- 410 Gone -[GET]:用户请求的资源被永久删除,且不会再得到的。
- 422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时,发生一个验证错误。
- 500 INTERNAL SERVER ERROR - [*]:服务器发生错误,用户将无法判断发出的请求是否成功。
7. 错误处理(Error handling)
如果状态码是4xx,服务器就应该向用户返回出错信息。一般来说,返回的信息中将error作为键名,出错信息作为键值即可。
{
error: "Invalid API key"
}
8. 返回结果
针对不同操作,服务器向用户返回的结果应该符合以下规范。
- GET /collection:返回资源对象的列表(数组)
- GET /collection/resource:返回单个资源对象
- POST /collection:返回新生成的资源对象
- PUT /collection/resource:返回完整的资源对象
- PATCH /collection/resource:返回完整的资源对象
- DELETE /collection/resource:返回一个空文档
9. 超媒体(Hypermedia API)
RESTful API最好做到Hypermedia(即返回结果中提供链接,连向其他API方法),使得用户不查文档,也知道下一步应该做什么。
比如,Github的API就是这种设计,访问api.github.com会得到一个所有可用API的网址列表。
{
"current_user_url": "https://api.github.com/user",
"authorizations_url": "https://api.github.com/authorizations",
// ...
}
从上面可以看到,如果想获取当前用户的信息,应该去访问api.github.com/user,然后就得到了下面结果。
{
"message": "Requires authentication",
"documentation_url": "https://developer.github.com/v3"
}
上面代码表示,服务器给出了提示信息,以及文档的网址。
10. 其他
服务器返回的数据格式,应该尽量使用JSON,避免使用XML。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 | 使用Django开发REST 接口 我们以在Django框架中使用的图书英雄案例来写一套支持图书数据增删改查的REST API接口,来理解REST API的开发。 在此案例中,前后端均发送JSON格式数据。 # views.py from datetime import datetime class BooksAPIVIew(View): """ 查询所有图书、增加图书 """ def get( self , request): """ 查询所有图书 路由:GET /books/ """ queryset = BookInfo.objects. all () book_list = [] for book in queryset: book_list.append({ 'id' : book. id , 'btitle' : book.btitle, 'bpub_date' : book.bpub_date, 'bread' : book.bread, 'bcomment' : book.bcomment, 'image' : book.image.url if book.image else '' }) return JsonResponse(book_list, safe = False ) def post( self , request): """ 新增图书 路由:POST /books/ """ json_bytes = request.body json_str = json_bytes.decode() book_dict = json.loads(json_str) # 此处详细的校验参数省略 book = BookInfo.objects.create( btitle = book_dict.get( 'btitle' ), bpub_date = datetime.strptime(book_dict.get( 'bpub_date' ), '%Y-%m-%d' ).date() ) return JsonResponse({ 'id' : book. id , 'btitle' : book.btitle, 'bpub_date' : book.bpub_date, 'bread' : book.bread, 'bcomment' : book.bcomment, 'image' : book.image.url if book.image else '' }, status = 201 ) class BookAPIView(View): def get( self , request, pk): """ 获取单个图书信息 路由: GET /books/<pk>/ """ try : book = BookInfo.objects.get(pk = pk) except BookInfo.DoesNotExist: return HttpResponse(status = 404 ) return JsonResponse({ 'id' : book. id , 'btitle' : book.btitle, 'bpub_date' : book.bpub_date, 'bread' : book.bread, 'bcomment' : book.bcomment, 'image' : book.image.url if book.image else '' }) def put( self , request, pk): """ 修改图书信息 路由: PUT /books/<pk> """ try : book = BookInfo.objects.get(pk = pk) except BookInfo.DoesNotExist: return HttpResponse(status = 404 ) json_bytes = request.body json_str = json_bytes.decode() book_dict = json.loads(json_str) # 此处详细的校验参数省略 book.btitle = book_dict.get( 'btitle' ) book.bpub_date = datetime.strptime(book_dict.get( 'bpub_date' ), '%Y-%m-%d' ).date() book.save() return JsonResponse({ 'id' : book. id , 'btitle' : book.btitle, 'bpub_date' : book.bpub_date, 'bread' : book.bread, 'bcomment' : book.bcomment, 'image' : book.image.url if book.image else '' }) def delete( self , request, pk): """ 删除图书 路由: DELETE /books/<pk>/ """ try : book = BookInfo.objects.get(pk = pk) except BookInfo.DoesNotExist: return HttpResponse(status = 404 ) book.delete() return HttpResponse(status = 204 ) # urls.py urlpatterns = [ url(r '^books/$' , views.BooksAPIVIew.as_view()), url(r '^books/(?P<pk>\d+)/$' , views.BookAPIView.as_view()) ] 测试 使用Postman测试上述接口 1 ) 获取所有图书数据 GET 方式访问 http: / / 127.0 . 0.1 : 8000 / books / , 返回状态码 200 ,数据如下 [ { "id" : 1 , "btitle" : "射雕英雄传" , "bpub_date" : "1980-05-01" , "bread" : 12 , "bcomment" : 34 , "image" : "" }, { "id" : 2 , "btitle" : "天龙八部" , "bpub_date" : "1986-07-24" , "bread" : 36 , "bcomment" : 40 , "image" : "" }, { "id" : 3 , "btitle" : "笑傲江湖" , "bpub_date" : "1995-12-24" , "bread" : 20 , "bcomment" : 80 , "image" : "" }, { "id" : 4 , "btitle" : "雪山飞狐" , "bpub_date" : "1987-11-11" , "bread" : 58 , "bcomment" : 24 , "image" : "" }, { "id" : 5 , "btitle" : "西游记" , "bpub_date" : "1988-01-01" , "bread" : 10 , "bcomment" : 10 , "image" : "booktest/xiyouji.png" }, { "id" : 6 , "btitle" : "水浒传" , "bpub_date" : "1992-01-01" , "bread" : 10 , "bcomment" : 11 , "image" : "" }, { "id" : 7 , "btitle" : "红楼梦" , "bpub_date" : "1990-01-01" , "bread" : 0 , "bcomment" : 0 , "image" : "" } ] 2 )获取单一图书数据 GET 访问 http: / / 127.0 . 0.1 : 8000 / books / 5 / ,返回状态码 200 , 数据如下 { "id" : 5 , "btitle" : "西游记" , "bpub_date" : "1988-01-01" , "bread" : 10 , "bcomment" : 10 , "image" : "booktest/xiyouji.png" } GET 访问http: / / 127.0 . 0.1 : 8000 / books / 100 / ,返回状态码 404 3 )新增图书数据 POST 访问http: / / 127.0 . 0.1 : 8000 / books / ,发送JSON数据: { "btitle" : "三国演义" , "bpub_date" : "1990-02-03" } 返回状态码 201 ,数据如下 { "id" : 8 , "btitle" : "三国演义" , "bpub_date" : "1990-02-03" , "bread" : 0 , "bcomment" : 0 , "image" : "" } 4 )修改图书数据 PUT 访问http: / / 127.0 . 0.1 : 8000 / books / 8 / ,发送JSON数据: { "btitle" : "三国演义(第二版)" , "bpub_date" : "1990-02-03" } 返回状态码 200 ,数据如下 { "id" : 8 , "btitle" : "三国演义(第二版)" , "bpub_date" : "1990-02-03" , "bread" : 0 , "bcomment" : 0 , "image" : "" } 5 )删除图书数据 DELETE 访问http: / / 127.0 . 0.1 : 8000 / books / 8 / ,返回 204 状态码 |
明确REST接口开发的核心任务
分析一下上节的案例,可以发现,在开发REST API接口时,视图中做的最主要有三件事:
- 将请求的数据(如JSON格式)转换为模型类对象
- 操作数据库
- 将模型类对象转换为响应的数据(如JSON格式)
序列化Serialization
维基百科中对于序列化的定义:
序列化(serialization)在计算机科学的资料处理中,是指将数据结构或物件状态转换成可取用格式(例如存成档案,存于缓冲,或经由网络中传送),以留待后续在相同或另一台计算机环境中,能恢复原先状态的过程。依照序列化格式重新获取字节的结果时,可以利用它来产生与原始物件相同语义的副本。对于许多物件,像是使用大量参照的复杂物件,这种序列化重建的过程并不容易。面向对象中的物件序列化,并不概括之前原始物件所关联的函式。这种过程也称为物件编组(marshalling)。从一系列字节提取数据结构的反向操作,是反序列化(也称为解编组, deserialization, unmarshalling)。
序列化在计算机科学中通常有以下定义:
在数据储存与传送的部分是指将一个对象)存储至一个储存媒介,例如档案或是记亿体缓冲等,或者透过网络传送资料时进行编码的过程,可以是字节或是XML等格式。而字节的或XML编码格式可以还原完全相等的对象)。这程序被应用在不同应用程序之间传送对象),以及服务器将对象)储存到档案或数据库。相反的过程又称为反序列化。
简而言之,我们可以将序列化理解为:
将程序中的一个数据结构类型转换为其他格式(字典、JSON、XML等),例如将Django中的模型类对象装换为JSON字符串,这个转换过程我们称为序列化。
如:
queryset = BookInfo.objects.all()
book_list = []
# 序列化
for book in queryset:
book_list.append({
'id': book.id,
'btitle': book.btitle,
'bpub_date': book.bpub_date,
'bread': book.bread,
'bcomment': book.bcomment,
'image': book.image.url if book.image else ''
})
return JsonResponse(book_list, safe=False)
反之,将其他格式(字典、JSON、XML等)转换为程序中的数据,例如将JSON字符串转换为Django中的模型类对象,这个过程我们称为反序列化。
如:
json_bytes = request.body
json_str = json_bytes.decode()
# 反序列化
book_dict = json.loads(json_str)
book = BookInfo.objects.create(
btitle=book_dict.get('btitle'),
bpub_date=datetime.strptime(book_dict.get('bpub_date'), '%Y-%m-%d').date()
)
我们可以看到,在开发REST API时,视图中要频繁的进行序列化与反序列化的编写。
总结
在开发REST API接口时,我们在视图中需要做的最核心的事是:
-
将数据库数据序列化为前端所需要的格式,并返回;
-
将前端发送的数据反序列化为模型类对象,并保存到数据库中。
Django REST framework 简介
- 在序列化与反序列化时,虽然操作的数据不尽相同,但是执行的过程却是相似的,也就是说这部分代码是可以复用简化编写的。
- 在开发REST API的视图中,虽然每个视图具体操作的数据不同,但增、删、改、查的实现流程基本套路化,所以这部分代码也是可以复用简化编写的:
- 增:校验请求数据 -> 执行反序列化过程 -> 保存数据库 -> 将保存的对象序列化并返回
- 删:判断要删除的数据是否存在 -> 执行数据库删除
- 改:判断要修改的数据是否存在 -> 校验请求的数据 -> 执行反序列化过程 -> 保存数据库 -> 将保存的对象序列化并返回
- 查:查询数据库 -> 将数据序列化并返回
Django REST framework可以帮助我们简化上述两部分的代码编写,大大提高REST API的开发速度。
认识Django REST framework
Django REST framework 框架是一个用于构建Web API 的强大而又灵活的工具。
通常简称为DRF框架 或 REST framework。
DRF框架是建立在Django框架基础之上,由Tom Christie大牛二次开发的开源项目。
特点
- 提供了定义序列化器Serializer的方法,可以快速根据 Django ORM 或者其它库自动序列化/反序列化;
- 提供了丰富的类视图、Mixin扩展类,简化视图的编写;
- 丰富的定制层级:函数视图、类视图、视图集合到自动生成 API,满足各种需要;
- 多种身份认证和权限认证方式的支持;
- 内置了限流系统;
- 直观的 API web 界面;
- 可扩展性,插件丰富
资料:
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 开发中对象命名的一点思考
· .NET Core内存结构体系(Windows环境)底层原理浅谈
· C# 深度学习:对抗生成网络(GAN)训练头像生成模型
· .NET 适配 HarmonyOS 进展
· .NET 进程 stackoverflow异常后,还可以接收 TCP 连接请求吗?
· 本地部署 DeepSeek:小白也能轻松搞定!
· 基于DeepSeek R1 满血版大模型的个人知识库,回答都源自对你专属文件的深度学习。
· 在缓慢中沉淀,在挑战中重生!2024个人总结!
· 如何给本地部署的DeepSeek投喂数据,让他更懂你
· 大人,时代变了! 赶快把自有业务的本地AI“模型”训练起来!