DRF-快速入门--请求和响应

博主：多点部落
发布时间：2021 年 01 月 19 日
141次浏览
暂无评论
6276字数
分类： DRF

从现在开始，我们将真正开始接触REST框架的核心。我们来介绍几个基本的构建模块。

一、请求对象(Request objects)

DRF引入了一个扩展Django常规对象的对象，并提供了更灵活的请求解析能力。 Request 对象的核心功能是属性，它与 request.POST 类似，但对于使用Web API更为有用。

request.POST # 只处理表单数据 只适用于'POST'方法
request.data # 处理任意数据 适用于'POST'，'PUT'和'PATCH'等方法

在DRF中，请始终使用 request.data ，不要使用 request.POST 。

二、响应对象(Response objects)

DRF同时还引入了一个 Response 对象，这是一种尚未对内容进行渲染的 TemplateResponse 类型，并使用内容协商的结果来确定返回给客户端正确的内容类型。

return Response(data) # 渲染成客户端请求的内容类型。

三、状态码(Status codes)

在前后端分离的RESTful模式中，我们不能简单、随意地返回响应，而是需要使用HTTP规定的，大家都认可的状态码的形式。

然而，在视图中使用纯数字的HTTP 状态码并不总是那么容易被理解，很容易被忽略。REST框架为 status 模块中的每个状态代码(如 HTTP_400_BAD_REQUEST )提供了更明确的标识符。使用它们来代替纯数字的HTTP状态码是个很好的主意。

四、封装API视图

REST框架提供了三种可用于编写API视图的包装器(wrappers)。

基于函数视图的@api_view装饰器
基于类视图APIView类系列
基于viewset视图集的类系列

这些包装器提供了一些功能，例如确保你在视图中接收到 Request 实例，并将上下文添加到Response ，以便可以执行内容协商的约定。

包装器还提供了诸如在适当的时候返回405 Method Not Allowed之类的响应，并处理在使用格式错误的输入来访问request.data时发生的任何ParseError异常。

视图体系是DRF最复杂，最晦涩的部分，文档写得特别不清晰，各种用法穿插，没有统一的逻辑。每种编写视图的方法，又分别对应不同代码细节，非常难以记忆和理解。

五、修改成真正的API视图

下面我们开始使用新的组件来写几个视图。

首先，我们使用 @api_view 装饰器来将一个传统的Django视图改造成DRF的API视图。删除 views.py 中原来所有的内容，写入下面的代码:

from rest_framework import status
from rest_framework.decorators import api_view
from rest_framework.response import Response
from snippets.models import Snippet
from snippets.serializers import SnippetSerializer


@api_view(['GET', 'POST'])
def snippet_list(request):
    """
    List all code snippets, or create a new snippet.
    """
    if request.method == 'GET':
        snippets = Snippet.objects.all()
        serializer = SnippetSerializer(snippets, many=True)
        return Response(serializer.data)
    elif request.method == 'POST':
        serializer = SnippetSerializer(data=request.data)
        if serializer.is_valid():
            serializer.save()
            return Response(serializer.data, status=status.HTTP_201_CREATED)
        
        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)

当前的视图比前面的示例有所改进，它稍微简洁一点。在装饰器的参数位置指定视图支持的 HTTP方法类型。不需要你额外处理csrf问题，也不使用Django的JSONRsponse方法了，而是使用DRF的Response方法。此外，我们还使用了命名状态代码status，这使得响应意义更加明显。你可以对比一下代码前后的变化，加深理解和印象。

同样，我们重写 views.py 模块中snippet的detail视图。

@api_view(['GET', 'PUT', 'DELETE'])
def snippet_detail(request, pk):
    """
    Retrieve, update or delete a code snippet.
    """
    try:
        snippet = Snippet.objects.get(pk=pk)
    except Snippet.DoesNotExist:
        return Response(status=status.HTTP_404_NOT_FOUND)
    if request.method == 'GET':
        serializer = SnippetSerializer(snippet)
        return Response(serializer.data)
    elif request.method == 'PUT':
        serializer = SnippetSerializer(snippet, data=request.data)
        if serializer.is_valid():
            serializer.save()
            return Response(serializer.data)
        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
    elif request.method == 'DELETE':
        snippet.delete()
        return Response(status=status.HTTP_204_NO_CONTENT)

目前为止，我们写的API视图和普通的Django视图没有什么太大区别，还是很好理解的。

注意，我们不再显式地将请求或响应绑定到给定的内容类型。 request.data 可以处理传入的 json 请求，也可以处理其他格式。同样，我们返回带有数据的响应对象，但允许REST框架将响应给渲染成正确的内容类型，比如json。

六、为url添加可选的后缀

其实这部分内容不应该出现在这里，它是和主干无关的细节。

在DRF的机制中，响应数据的格式不再与单一内容类型连接，可以同时响应json格式或HTML格式。我们可以为API路径添加对格式后缀的支持。使用格式后缀给我们明确指定了给定格式的 URL，这意味着我们的API将能够处理诸如 http://example.com/api/items/4.json 之类的 URL。

像下面这样在这两个视图中添加一个 format 关键字参数。

def snippet_list(request, format=None):

和

def snippet_detail(request, pk, format=None):

仅仅在视图中添加format参数还不够，还需要在路由中进行设置。现在更新 snippets/urls.py 文件，为现有的URL后面添加一组 format_suffix_patterns 。

from django.urls import path
from rest_framework.urlpatterns import format_suffix_patterns
from snippets import views

urlpatterns = [
    path('snippets/', views.snippet_list),
    path('snippets/<int:pk>', views.snippet_detail),
]
urlpatterns = format_suffix_patterns(urlpatterns)

注意上面最后一句代码，它的意思是用 format_suffix_patterns 来封装urlpatterns，这样每一个带有 .json 等后缀的url都能被正确解析。

以上操作都是可选的，我们不一定需要添加这些额外的url模式，但它给了我们一个简单，清晰的方式来引用特定的格式。

七、测试我们的工作

从命令行开始测试API，就像我们在前面所做的那样。

可以像以前一样获取所有snippet的列表。

执行命令:http http://127.0.0.1:8000/snippets/


HTTP/1.1 200 OK
Allow: OPTIONS, POST, GET
Content-Length: 319
Content-Type: application/json
Date: Tue, 19 Jan 2021 08:25:34 GMT
Referrer-Policy: same-origin
Server: WSGIServer/0.2 CPython/3.6.7
Vary: Accept, Cookie
X-Content-Type-Options: nosniff
X-Frame-Options: DENY

[
    {
        "code": "foo = \"bar\"\n",
        "id": 1,
        "language": "python",
        "linenos": false,
        "style": "friendly",
        "title": ""
    },
    {
        "code": "print(\"hello, world\")\n",
        "id": 2,
        "language": "python",
        "linenos": false,
        "style": "friendly",
        "title": ""
    },
    {
        "code": "print(\"hello, world\")",
        "id": 3,
        "language": "python",
        "linenos": false,
        "style": "friendly",
        "title": ""
    }
]

可以通过使用Accept 标头来控制我们回复的响应格式:

http http://127.0.0.1:8000/snippets/ Accept:application/json # 请求JSON 
http http://127.0.0.1:8000/snippets/ Accept:text/html # 请求HTML

或者通过附加后缀的方式:

http http://127.0.0.1:8000/snippets.json # JSON后缀 
http http://127.0.0.1:8000/snippets.api # 可浏览API后缀

如果觉得麻烦那就直接在浏览器中查看

并且下面还可以创建一个新的的sinppet表单

同样，访问 http://127.0.0.1:8000/snippets/1/ ，会看到下面的序号为1的snippet的具体内容:

你可能会疑惑，这么高端大气的页面怎么来的，我们没有编写这个页面HTML啊。这是DRF安利给我们的，内置的。

DRF的API视图会根据客户端请求的响应内容类型返回对应类型的数据，因此当Web浏览器请求 snippets时，它实际请求的是HTML格式，而不是json等格式，API会按要求返回HTML格式的表示，这个过程是DRF早就写好了的，在源码中实现了的。

DRF的这个功能，比较类似Django的admin后台的理念，大大降低了开发人员检查和使用API的障碍，可视化后更直接、更清晰、更便捷。

本文作者：多点部落
文章标题：DRF-快速入门--请求和响应
本文地址：https://wouldmissyou.com/archives/41/
版权说明：若无注明，本文皆为“多点部落”原创，转载请保留文章出处。

最后修改：2021 年 01 月 20 日 09 : 07 AM

如果觉得我的文章对你有用，请随意赞赏

发表评论取消回复

评论 *

私密评论

名称 *

邮箱 *

地址

Luck
该评论仅登录用户及评论双方可见
Dmall
空白占位符
卡卡西
看一下
大头
踩点。。。
敲可爱的人呐
请说出你服务器出故障的故事OωO

DRF-快速入门--请求和响应

多点部落 • 2021 年 01 月 19 日

从现在开始，我们将真正开始接触REST框架的核心。我们来介绍几个基本的构建模块。

一、请求对象(Request objects)

request.POST # 只处理表单数据 只适用于'POST'方法
request.data # 处理任意数据 适用于'POST'，'PUT'和'PATCH'等方法

在DRF中，请始终使用 request.data ，不要使用 request.POST 。

二、响应对象(Response objects)

DRF同时还引入了一个 Response 对象，这是一种尚未对内容进行渲染的 TemplateResponse 类型，并使用内容协商的结果来确定返回给客户端正确的内容类型。

return Response(data) # 渲染成客户端请求的内容类型。

三、状态码(Status codes)

在前后端分离的RESTful模式中，我们不能简单、随意地返回响应，而是需要使用HTTP规定的，大家都认可的状态码的形式。

四、封装API视图

REST框架提供了三种可用于编写API视图的包装器(wrappers)。

基于函数视图的@api_view装饰器
基于类视图APIView类系列
基于viewset视图集的类系列

这些包装器提供了一些功能，例如确保你在视图中接收到 Request 实例，并将上下文添加到Response ，以便可以执行内容协商的约定。

包装器还提供了诸如在适当的时候返回405 Method Not Allowed之类的响应，并处理在使用格式错误的输入来访问request.data时发生的任何ParseError异常。

视图体系是DRF最复杂，最晦涩的部分，文档写得特别不清晰，各种用法穿插，没有统一的逻辑。每种编写视图的方法，又分别对应不同代码细节，非常难以记忆和理解。

五、修改成真正的API视图

下面我们开始使用新的组件来写几个视图。

首先，我们使用 @api_view 装饰器来将一个传统的Django视图改造成DRF的API视图。删除 views.py 中原来所有的内容，写入下面的代码:

from rest_framework import status
from rest_framework.decorators import api_view
from rest_framework.response import Response
from snippets.models import Snippet
from snippets.serializers import SnippetSerializer


@api_view(['GET', 'POST'])
def snippet_list(request):
    """
    List all code snippets, or create a new snippet.
    """
    if request.method == 'GET':
        snippets = Snippet.objects.all()
        serializer = SnippetSerializer(snippets, many=True)
        return Response(serializer.data)
    elif request.method == 'POST':
        serializer = SnippetSerializer(data=request.data)
        if serializer.is_valid():
            serializer.save()
            return Response(serializer.data, status=status.HTTP_201_CREATED)
        
        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)

同样，我们重写 views.py 模块中snippet的detail视图。

@api_view(['GET', 'PUT', 'DELETE'])
def snippet_detail(request, pk):
    """
    Retrieve, update or delete a code snippet.
    """
    try:
        snippet = Snippet.objects.get(pk=pk)
    except Snippet.DoesNotExist:
        return Response(status=status.HTTP_404_NOT_FOUND)
    if request.method == 'GET':
        serializer = SnippetSerializer(snippet)
        return Response(serializer.data)
    elif request.method == 'PUT':
        serializer = SnippetSerializer(snippet, data=request.data)
        if serializer.is_valid():
            serializer.save()
            return Response(serializer.data)
        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
    elif request.method == 'DELETE':
        snippet.delete()
        return Response(status=status.HTTP_204_NO_CONTENT)

目前为止，我们写的API视图和普通的Django视图没有什么太大区别，还是很好理解的。

六、为url添加可选的后缀

其实这部分内容不应该出现在这里，它是和主干无关的细节。

像下面这样在这两个视图中添加一个 format 关键字参数。

def snippet_list(request, format=None):

和

def snippet_detail(request, pk, format=None):

仅仅在视图中添加format参数还不够，还需要在路由中进行设置。现在更新 snippets/urls.py 文件，为现有的URL后面添加一组 format_suffix_patterns 。

from django.urls import path
from rest_framework.urlpatterns import format_suffix_patterns
from snippets import views

urlpatterns = [
    path('snippets/', views.snippet_list),
    path('snippets/<int:pk>', views.snippet_detail),
]
urlpatterns = format_suffix_patterns(urlpatterns)

注意上面最后一句代码，它的意思是用 format_suffix_patterns 来封装urlpatterns，这样每一个带有 .json 等后缀的url都能被正确解析。

以上操作都是可选的，我们不一定需要添加这些额外的url模式，但它给了我们一个简单，清晰的方式来引用特定的格式。

七、测试我们的工作

从命令行开始测试API，就像我们在前面所做的那样。

可以像以前一样获取所有snippet的列表。

执行命令:http http://127.0.0.1:8000/snippets/


HTTP/1.1 200 OK
Allow: OPTIONS, POST, GET
Content-Length: 319
Content-Type: application/json
Date: Tue, 19 Jan 2021 08:25:34 GMT
Referrer-Policy: same-origin
Server: WSGIServer/0.2 CPython/3.6.7
Vary: Accept, Cookie
X-Content-Type-Options: nosniff
X-Frame-Options: DENY

[
    {
        "code": "foo = \"bar\"\n",
        "id": 1,
        "language": "python",
        "linenos": false,
        "style": "friendly",
        "title": ""
    },
    {
        "code": "print(\"hello, world\")\n",
        "id": 2,
        "language": "python",
        "linenos": false,
        "style": "friendly",
        "title": ""
    },
    {
        "code": "print(\"hello, world\")",
        "id": 3,
        "language": "python",
        "linenos": false,
        "style": "friendly",
        "title": ""
    }
]

可以通过使用Accept 标头来控制我们回复的响应格式:

http http://127.0.0.1:8000/snippets/ Accept:application/json # 请求JSON 
http http://127.0.0.1:8000/snippets/ Accept:text/html # 请求HTML

或者通过附加后缀的方式:

http http://127.0.0.1:8000/snippets.json # JSON后缀 
http http://127.0.0.1:8000/snippets.api # 可浏览API后缀

如果觉得麻烦那就直接在浏览器中查看

并且下面还可以创建一个新的的sinppet表单

同样，访问 http://127.0.0.1:8000/snippets/1/ ，会看到下面的序号为1的snippet的具体内容:

你可能会疑惑，这么高端大气的页面怎么来的，我们没有编写这个页面HTML啊。这是DRF安利给我们的，内置的。

DRF的这个功能，比较类似Django的admin后台的理念，大大降低了开发人员检查和使用API的障碍，可视化后更直接、更清晰、更便捷。

DRF-快速入门--请求和响应

一、请求对象(Request objects)

二、响应对象(Response objects)

三、状态码(Status codes)

四、封装API视图

五、修改成真正的API视图

六、为url添加可选的后缀

七、测试我们的工作

发表评论取消回复

djangorestframework-jwt登录方式和手写jwt登录方式

Django(一)-虚拟环境

Django(七)-常用标签

Django(九)-自定义过滤器和模板结构

Django(三)-django介绍

Django DRF(十八)-版本控制（Versioning）

Django DRF(十三)-认证

Django(三)-django介绍

django分页-用django-pure-pagination进行分页

Django(四)-url和视图

DRF-快速入门--请求和响应

一、请求对象(Request objects)

二、响应对象(Response objects)

三、状态码(Status codes)

四、封装API视图

五、修改成真正的API视图

六、为url添加可选的后缀

七、测试我们的工作

一、请求对象(Request objects)

二、响应对象(Response objects)

三、状态码(Status codes)

四、封装API视图

五、修改成真正的API视图

六、 为url添加可选的后缀

七、测试我们的工作

发表评论 取消回复

DRF-快速入门--请求和响应

一、请求对象(Request objects)

二、响应对象(Response objects)

三、状态码(Status codes)

四、封装API视图

五、修改成真正的API视图

六、 为url添加可选的后缀

七、测试我们的工作

六、为url添加可选的后缀

发表评论取消回复

六、为url添加可选的后缀