drf基础:初识drf | django |《python学习之路》| python 技术论坛-江南app体育官方入口

web应用模式

在开发web应用中，有两种应用模式：

• 前后端不分离
• 前后端分离

前后端不分离

在前后端不分离的应用模式中，前端页面看到的效果都是由后端控制，由后端渲染页面或重定向，也就是后端需要控制前端的展示，前端与后端的耦合度很高。

这种应用模式比较适合纯网页应用，但是当后端对接app时，app可能并不需要后端返回一个html网页，而仅仅是数据本身，所以后端原本返回网页的接口不再适用于前端app应用，为了对接app后端还需再开发一套接口。

前后端分离

在前后端分离的应用模式中，后端仅返回前端所需的数据，不再渲染html页面，不再控制前端的效果。至于前端用户看到什么效果，从后端请求的数据如何加载到前端中，都由前端自己决定，网页有网页的处理方式，app有app的处理方式，但无论哪种前端，所需的数据基本相同，后端仅需开发一套逻辑对外提供数据即可。

在前后端分离的应用模式中 ，前端与后端的耦合度相对较低。

在前后端分离的应用模式中，我们通常将后端开发的每个视图都称为一个接口，或者api，前端通过访问接口来对数据进行增删改查。

简介

1. 在序列化与反序列化时，虽然操作的数据不尽相同，但是执行的过程却是相似的，也就是说这部分代码是可以复用简化编写的。
2. 在开发rest api的视图中，虽然每个视图具体操作的数据不同，但增、删、改、查的实现流程基本套路化，所以这部分代码也是可以复用简化编写的：
   • 增：校验请求数据 -> 执行反序列化过程 -> 保存数据库 -> 将保存的对象序列化并返回
   • 删：判断要删除的数据是否存在 -> 执行数据库删除
   • 改：判断要修改的数据是否存在 -> 校验请求的数据 -> 执行反序列化过程 -> 保存数据库 -> 将保存的对象序列化并返回
   • 查：查询数据库 -> 将数据序列化并返回

django rest framework可以帮助我们简化上述两部分的代码编写，大大提高rest api的开发速度。

是什么

django rest framework 框架是一个用于构建web api 的强大而又灵活的工具。

通常简称为drf框架 或 rest framework。

drf框架是建立在django框架基础之上，由tom christie大牛二次开发的开源项目。

特点

• 提供了定义序列化器serializer的方法，可以快速根据 django orm 或者其它库自动序列化/反序列化；
• 提供了丰富的类视图、mixin扩展类，简化视图的编写；
• 丰富的定制层级：函数视图、类视图、视图集合到自动生成 api，满足各种需要；
• 多种身份认证和权限认证方式的支持；
• 内置了限流系统；
• 直观的 api web 界面；
• 可扩展性，插件丰富

资料：

认识restful

简介

在前后端分离的应用模式里，后端api接口如何定义？

例如对于后端数据库中保存了商品的信息，前端可能需要对商品数据进行增删改查，那相应的每个操作后端都需要提供一个api接口：

1. post /add-goods 增加商品
2. post /delete-goods 删除商品
3. post /update-goods 修改商品
4. get /get-goods 查询商品信息

对于接口的请求方式与路径，每个后端开发人员可能都有自己的定义方式，风格迥异。

是否存在一种统一的定义方式，被广大开发人员接受认可的方式呢？

这就是被普遍采用的api的restful设计风格。

起源

rest这个词，是在他2000年的中提出的。

fielding是一个非常重要的人，他是http协议（1.0版和1.1版）的主要设计者、apache服务器软件的作者之一、apache基金会的第一任主席。所以，他的这篇论文一经发表，就引起了关注，并且立即对互联网开发产生了深远的影响。

名称

fielding将他对互联网软件的架构原则，定名为rest，即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设计方法

域名

应该尽量将api部署在专用域名之下。

https://api.example.com

如果确定api很简单，不会有进一步扩展，可以考虑放在主域名下。

https://example.org/api/

版本（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方便和直观。采用这种做法。

因为不同的版本，可以理解成同一种资源的不同表现形式，所以应该采用同一个url。版本号可以在http请求头信息的accept字段中进行区分（参见）：

accept: vnd.example-com.foojson; version=1.0
accept: vnd.example-com.foojson; version=1.1
accept: vnd.example-com.foojson; version=2.0

路径（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

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：删除某个指定动物园的指定动物

过滤信息（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 的含义是相同的。

状态码（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 - [*]：服务器发生错误，用户将无法判断发出的请求是否成功。

状态码的完全列表参见或。

错误处理（error handling）

如果状态码是4xx，服务器就应该向用户返回出错信息。一般来说，返回的信息中将error作为键名，出错信息作为键值即可。

{
    error: "invalid api key"
}

返回结果

针对不同操作，服务器向用户返回的结果应该符合以下规范。

• get /collection：返回资源对象的列表（数组）
• get /collection/resource：返回单个资源对象
• post /collection：返回新生成的资源对象
• put /collection/resource：返回完整的资源对象
• patch /collection/resource：返回完整的资源对象
• delete /collection/resource：返回一个空文档

超媒体（hypermedia api）

restful api最好做到hypermedia（即返回结果中提供链接，连向其他api方法），使得用户不查文档，也知道下一步应该做什么。

比如，github的api就是这种设计，访问会得到一个所有可用api的网址列表。

{
"current_user_url": "https://api.github.com/user",
"authorizations_url": "https://api.github.com/authorizations",
// ...
}

从上面可以看到，如果想获取当前用户的信息，应该去访问，然后就得到了下面结果。

{
  "message": "requires authentication",
  "documentation_url": "https://developer.github.com/v3"
}

上面代码表示，服务器给出了提示信息，以及文档的网址。

其他

服务器返回的数据格式，应该尽量使用json，避免使用xml。

核心任务

在开发rest api接口时，视图中做的最主要有三件事：

• 将请求的数据（如json格式）转换为模型类对象
• 操作数据库
• 将模型类对象转换为响应的数据（如json格式）

序列化serialization

中对于序列化的定义：

序列化（serialization）在计算机科学的资料处理中，是指将数据结构或物件状态转换成可取用格式（例如存成档案，存于缓冲，或经由网络中传送），以留待后续在相同或另一台计算机环境中，能恢复原先状态的过程。依照序列化格式重新获取字节的结果时，可以利用它来产生与原始物件相同语义的副本。对于许多物件，像是使用大量参照的复杂物件，这种序列化重建的过程并不容易。面向对象中的物件序列化，并不概括之前原始物件所关联的函式。这种过程也称为物件编组（marshalling）。从一系列字节提取数据结构的反向操作，是反序列化（也称为解编组, deserialization, unmarshalling）。

序列化在计算机科学中通常有以下定义:

在数据储存与传送的部分是指将一个存储至一个，例如或是等，或者透过网络传送资料时进行编码的过程，可以是或是等格式。而的或编码格式可以还原完全相等的。这程序被应用在不同之间传送，以及服务器将储存到或。相反的过程又称为。

简而言之，我们可以将序列化理解为：

将程序中的一个数据结构类型转换为其他格式（字典、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接口时，我们在视图中需要做的最核心的事是：

• 将数据库数据序列化为前端所需要的格式，并返回；
• 将前端发送的数据反序列化为模型类对象，并保存到数据库中。