drf理论

最新推荐文章于 2022-06-01 10:15:04 发布

昱珩1024

最新推荐文章于 2022-06-01 10:15:04 发布

阅读量187

点赞数

文章标签： python django web

本文链接：https://blog.csdn.net/weixin_44886189/article/details/116236941

版权

文章目录

引子
1. API
2.RESTful API规范
3. Django REST framework

引子

如果我们对web的开发模式进行分类的话，大致可以分为前后端未分离和前后端分离两种；

前后端未分离

后端人员工作占比较大，在这种开发模式下前端将html写成半成品的页面后，需要与后端人员对接哪里需要数据进行相应标注；后端人员编写逻辑连接数据库后获取数据并通过数据渲染的方式在前端展示；这样则前后端的工作无法同时进行；后端人员需要等待前端的页面，开发成本高，所以在大多数情况下后端人员即负责前端页面也负责后端逻辑。
前后端分离

相比前后端未分离后端的一些工作分给了前端，后端的占比减少；前端有了自己的框架，例如当下流行的：Vue，可以自行将前端数据渲染，并且监听数据的变化，通过数据来实现动态页面；此时后端人员只需要编写逻辑来从数据库获取数据。响应从前端发送的请求（例如：axios），并返回给前端数据（Json、xml）；

后端向前端发送的数据大多为列表嵌套字典的数据，后端也需要向前端提供一份API接口文档说明，针对前端请求数据的不同，后端执行的逻辑相应不同

1. API

全称：Application Program Interface应用程序接口

API就是接口接口就是API

1.1 接口的分类

硬件接口：例如电脑上的USB就是硬件接口，我们可以通过USB接口扩展电脑的存储，外设等
软件接口：是指对协定进行定义的引用类型，例如在python中引用open函数。这就是python语言的内部接口。
应用程序接口（api）：应用程序接口是相对于物理接口的而言的，而物理接口就是通常所说的硬件接口，比如usb口，而逻辑接口就是程序中预留的接口功能，逻辑接口指能够实现数据交换功能但物理上不存在，例如前后端分离时候，后端提供的就是逻辑接口。

我们作为软件开发的工作人员，其主要研究的重点就是软件接口和逻辑接口。

就前后端未分离后端提供的统一API而讨论来说，我们为什么要使用接口？在开发过程中，请求不同或者不同类型的数据，如果我们自己去定制接口，比如我在请求数据中存放一个‘choice’：1为一的键值对，后端接受到后获取choice的值，判断要获取的数据。而另一个人在开发过程中可能会使用另一种方式来判断，久而久之会越来越混乱。而API就提供了规范（协议），大家都去遵循。

1.2 接口的优缺点

在软件行业接口的优点：

1）制定标准/一种规范

标准规范的制定离不开接口，制定标准的目的就是为了让定义和实现分离，而接口作为完全的抽象，是标准制定的不二之选

辅助理解：例如安卓手机同一的标准：USB-micro Type-C 而不是像5年前那样五花八门

2）提供抽象/软件解耦

除了标准之外，接口还有一个特征就是抽象。正是这样的抽象，得以让接口的调用者和实现者可以完全的解耦，使程序能更好的被维护

pass

1.3 rpc（了解）

当下流行的接口规范有两种，它们分别是：rpc、rest framwork

rpc: 翻译成中文:远程过程调用[远程服务调用].

后端的接口全部是通过函数的形式来构建，用函数处理逻辑。

post请求

action=函数&参数1=xx&参数2=oo

http:www.luffy.com/?action=get_all_student&params=301&sex=1

我们一说action就是调用函数名称的。

缺点：

随着接口增多，函数增多，参数增多，前端请求api接口时，比较难找，容易出现重复的接口。

1.4 restful

restful: 翻译成中文: 资源状态转换.

把后端所有的数据/文件都看成资源.

那么接口请求数据,本质上来说就是对资源的操作了.web项目中操作资源,无非就是增删查改.所以要求在地址栏中声明要操作的资源是什么,然后通过http请求方式不同来说明对资源进行哪一种操作.

get就是获取数据，post就是提交数据，put就是修改数据，delete就是删除数据

2.RESTful API规范

参考文档：http://www.runoob.com/w3cnote/restful-architecture.html

REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。它首次出现在2000年Roy Fielding的博士论文中。

RESTful是一种定义Web API接口的设计风格，尤其适用于前后端分离的应用模式中。

这种风格的理念认为后端开发任务就是提供数据的，对外提供的是数据资源的访问接口，所以在定义接口时，客户端访问的URL路径就表示这种要操作的数据资源。

而对于数据资源分别使用POST、DELETE、GET、UPDATE等请求动作来表达对数据的增删查改。

注意：

前后端分离的项目，要有明确的状态码的配置。
URI：Uniform Resource Identifier,资源在web中的唯一标识。

2.1 域名

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

https://api.example.com  # 大公司

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

https://example.org/api/

2.2 版本（Versioning）

应该将API的版本号放入URL。

http://www.example.com/api/1.0/foo

http://www.example.com/api/1.1/foo

http://www.example.com/api/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

2.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


# 通常我们有五种经常使用的接口：
GET /products ：将返回所有产品清单  获取所有数据
GET /products/4 ：获取单条数据
POST /products ：添加单条数据
PUT /products/4 ：修改单条数据
delete /products/4 删除单条数据

(2) API中的名词应该使用复数。无论子资源或者所有资源。

举例来说，获取产品的API可以这样定义

获取单个产品：http://127.0.0.1:8080/AppName/rest/products/1
获取所有产品: http://127.0.0.1:8080/AppName/rest/products

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

2.5. 过滤信息（Filtering）

如果记录数量很多，服务器不可能都将它们返回给用户。API应该提供参数，过滤返回结果。

下面是一些常见的参数。query_string 查询字符串,地址栏后面问号后面的数据,格式: name=xx&sss=xxx

?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 的含义是相同的。

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

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

2.7. 错误处理（Error handling）

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

{
    error: "Invalid API key"
}

2.8. 返回结果

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

GET /collection：返回资源对象的列表（数组）
GET /collection/ID：返回单个资源对象(json)
POST /collection：返回新生成的资源对象(json)
PUT /collection/ID：返回完整的资源对象(json)
DELETE /collection/ID：返回一个空文档(空字符串)

2.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"
}

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

其他

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

3. Django REST framework

有了drf这个应用，就大大简化了我们写结构的过程

核心思想: 缩减编写api接口的代码 – DRF

Django REST framework是一个建立在Django基础之上的Web 应用开发框架，可以快速的开发REST API接口应用。在REST framework中，提供了序列化器Serialzier的定义，可以帮助我们简化序列化与反序列化的过程，不仅如此，还提供丰富的类视图、扩展类、视图集来简化视图的编写工作。REST framework还提供了认证、权限、限流、过滤、分页、接口文档等功能支持。REST framework提供了一个API 的Web可视化界面来方便查看测试接口。

在这里插入图片描述

英文文档：https://www.django-rest-framework.org/

特点
- 提供了定义序列化器Serializer的方法，可以快速根据 Django ORM 或者其它库自动序列化/反序列化；
- 提供了丰富的类视图、Mixin扩展类，简化视图的编写；
- 丰富的定制层级：函数视图、类视图、视图集合到自动生成 API，满足各种需要；
- 多种身份认证和权限认证方式的支持；[jwt]
- 内置了限流系统；
- 直观的 API web 界面；
  供了一个API 的Web可视化界面来方便查看测试接口。**

英文文档：https://www.django-rest-framework.org/

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