Django API 开发:一个 Todo 应用的后端(中)

简介: 在接下来的两章中,我们将构建一个 Todo API 后端,然后将其与 React 前端连接。 我们已经制作了第一个 API,并回顾了 HTTP 和 REST 的抽象工作原理,但是您仍然可能还没有“完全”了解它们如何结合在一起。 在这两章的最后,您将学到。

Dajngo REST 框架

停止本地服务器 Control + c,然后通过 pipenv 安装 Django REST Framework。

(backend) $ pipenv install djangorestframework==3.10.3

然后像其他任何第三方应用程序一样,将 rest_framework 添加到我们的 INSTALLED_APPS 设置中。 我们还希望开始配置所有 REST_FRAMEWORK 下存在的 Django REST Framework 特定设置。 首先,我们将权限明确设置为 AllowAny。 此行位于文件的底部。

# todo_project/settings.py
INSTALLED_APPS = [
    'django.contrib.admin', 
    'django.contrib.auth', 
    'django.contrib.contenttypes',
    'django.contrib.sessions', 
    'django.contrib.messages',
    'django.contrib.staticfiles',
    # 3rd party 
    'rest_framework',  # new
    # Local
    'todos.apps.TodosConfig', 
]
# new
REST_FRAMEWORK = { 
    'DEFAULT_PERMISSION_CLASSES': [
        'rest_framework.permissions.AllowAny', 
    ]
}


Django REST Framework 包含冗长的隐式设置默认设置列表。 您可以在此处查看完整列表。 AllowAny 是其中之一,这意味着当我们像上面所做的那样显式设置它时,其效果与没有设置 DEFAULT_PERMISSION_CLASSES 的配置完全相同。


学习默认设置需要花费一些时间。 在本书学习过程中,我们将对其中的一些熟悉。 要记住的主要内容是,隐式默认设置的设计旨在使开发人员可以进入并开始在本地开发环境中快速工作。 但是,默认设置不适用于生产。 因此,通常我们会在项目过程中对它们进行一些更改。


好的,这样就安装了 Django REST Framework。 接下来是什么?与上一章中我们同时构建网页和 API 的 Library 项目不同,在这里我们仅构建 API。 因此,我们不需要创建任何模板文件或传统的 Django 视图。


相反,我们将更新三个特定于 Django REST 框架的文件,以将数据库模型转换为 Web API:urls.py,views.py 和 serializers.py。

URLs

我喜欢先从 URL 开始,因为它们是我们 API 端点的入口点。 就像在传统的 Django 项目中一样,urls.py 文件使我们可以配置路由。


从 Django 项目级文件 todo_project / urls.py 开始。 我们在第二行导入 include,并在 api /为我们的 todos 应用添加一条路线。

# todo_project/urls.py
from django.contrib import admin
from django.urls import include, path  # new
urlpatterns = [
    path('admin/', admin.site.urls),  
    path('api/', include('todos.urls')), # new
]


接下来,创建我们的应用程序级别的 todos / urls.py 文件。

(backend) $ touch todos/urls.py


并使用以下代码对其进行更新。

# todos/urls.py
from django.urls import path
from .views import ListTodo, DetailTodo
urlpatterns = [
    path('<int:pk>/', DetailTodo.as_view()), 
    path('', ListTodo.as_view()),
]


请注意,我们引用的还有两个尚未创建的视图:ListTodo 和 DetailTodo。 但是,路由现已完成。 api/有所有待办事项的列表位于空字符串 '',即。 每个待办事项都将在其主键上可用,这是 Django 在每个数据库表中自动设置的值。 第一个条目是 1,第二个条目是 2,依此类推。 因此,我们的第一个待办事项最终将位于 API 端点api/1/

Serializers

让我们回顾一下到目前为止。 我们从一个传统的 Django 项目和应用程序开始,我们创建了数据库模型并添加了数据。 然后,我们安装了 Django REST Framework 并配置了 URL。 现在,我们需要将模型中的数据转换为将在 URL 输出的 JSON。 因此,我们需要一个序列化器。


Django REST Framework 附带了一个强大的内置序列化程序类,我们可以使用少量代码快速扩展它们。 这就是我们在这里要做的。


首先在 todos 应用中创建一个新的 serializers.py 文件。

(backend) $ touch todos/serializers.py

然后更新代码,如下所示:

# todos/serializers.py
from rest_framework import serializers 
from .models import Todo
class TodoSerializer(serializers.ModelSerializer): 
    class Meta:
        model = Todo
        fields = ('id', 'title', 'body',)


在顶部,我们从 Django REST Framework 以及我们的 models.py 文件导入了序列化器。 接下来,我们创建一个类 TodoSerializer。 这里的格式与我们在 Django 本身中创建模型类或表单的方式非常相似。 我们正在指定要使用的模型以及我们要公开的特定字段。 请记住,id 是 Django 自动创建的,因此我们不必在 Todo 模型中定义它,但是我们将在细节视图中使用它。


就是这样。 Django REST Framework 现在将神奇地将我们的数据转换为 JSON,从而公开来自 Todo 模型的 id,title 和 body 字段。


我们需要做的最后一件事是配置我们的 views.py 文件。

Views

在传统的 Django 中,视图用于自定义要发送到模板的数据。 在 Django REST Framework 中,视图执行相同的操作,但对序列化的数据而言。


Django REST Framework 视图的语法故意与常规 Django 视图非常相似,就像常规 Django 一样,Django REST Framework 随附了通用视图以用于常见用例。 这就是我们在这里使用的。


更新 todos / views.py 文件,如下所示:

# todos/views.py
from rest_framework import generics
from .models import Todo
from .serializers import TodoSerializer
class ListTodo(generics.ListAPIView): 
    queryset = Todo.objects.all() 
    serializer_class = TodoSerializer
class DetailTodo(generics.RetrieveAPIView): 
    queryset = Todo.objects.all() 
    serializer_class = TodoSerializer


在顶部,我们导入 Django REST Framework 的泛型视图以及我们的 models.py 和 serializers.py 文件。


从我们的 todos / urls.py 文件中调用,我们有两条路线,因此有两个不同的视图。 我们将使用 ListAPIView 显示所有待办事项,并使用 RetrieveAPIView 显示单个模型实例。


精明的读者会注意到这里的代码有些冗余。 即使扩展的通用视图有所不同,我们实质上还是为每个视图重复使用 queryset 和 serializer_class。 在本书的后面,我们将学习有关解决此问题的视图集和路由器,并允许我们使用更少的代码来创建相同的 API 视图和 URL。


但是现在我们完成了! 我们的 API 已准备就绪,可以使用。 如您所见,Django REST Framework 和 Django 之间的唯一真正区别是,使用 Django REST Framework,我们需要添加 serializers.py 文件,而无需模板文件。 否则,urls.py 和 views.py 文件的行为类似。

相关文章
|
3天前
|
人工智能 自然语言处理 测试技术
Apipost 与 Apifox 深度对比:谁是 API 开发的最佳拍档?
在 API 开发中,Apipost 与 Apifox 是两款流行的国产工具。本文通过实际项目的对比发现,Apipost 在 AI 功能方面表现突出,如 AI 自动生成文档、测试用例、脚本等,显著提升开发效率。基础功能上,Apipost 也更全面,支持离线使用、OpenAPI 格式导出、多种协议及数据库字典导入,界面简洁易用,综合性能优于 Apifox。
37 5
|
6天前
|
运维 数据可视化 测试技术
从混乱到清晰:API开发追踪工具实用技巧与工具配置完整拆解
API开发追踪工具是提升团队协作效率、实现接口全流程管理的关键。它整合任务看板、文档同步、版本控制与多角色协作,助力前后端及第三方高效对接。本文详解其核心功能、选型建议与落地实践,助你打造透明、规范的API协作体系。
|
3天前
|
数据采集 缓存 JSON
1688商品API全链路开发实践
本文介绍了对接1688开放平台的核心要点,涵盖OAuth2.0认证流程、商品列表接口调用技巧、高并发优化策略及异常处理清单。内容包含获取access_token示例、隐藏参数解析、数据清洗方案与缓存设计,并强调合规调用注意事项。
1688商品API全链路开发实践
|
人工智能 前端开发 测试技术
Apipost 与 Apifox 深度对比:2025全方位解析助力 API 开发的利器
本文对比了Apipost与Apifox两款API开发与管理工具在功能、使用场景及用户评价等方面的差异。Apipost在API设计、调试、文档管理、Mock服务、离线支持及AI能力方面表现更优,尤其适合大型企业级项目和高效率需求的团队。而Apifox则适用于小型项目或对功能要求较低的团队。综合来看,Apipost在多方面具备明显优势,是高效、高质量API开发的理想选择。
115 24
|
3天前
|
消息中间件 缓存 JSON
亚马逊SP-API开发实战:商品数据获取与操作
本文介绍了亚马逊SP-API接入流程,包括开发者注册、OAuth2.0认证示例及核心商品接口的使用。涵盖商品信息查询、批量查询、限流规则与错误处理,并提供最佳实践建议,如使用AWS Lambda与SQS实现高效数据同步。
亚马逊SP-API开发实战:商品数据获取与操作
|
13天前
|
人工智能 前端开发 jenkins
2025 API 开发管理工具 Apipost 与 Apifox 全维度对比
本文深入对比了 Apipost 与 Apifox 两款 API 开发管理工具在设计、调试、文档管理、Mock 服务、离线支持、AI 能力及 CI/CD 集成等方面的优劣,全面评估其适用场景,为研发测试团队提供选型参考。
120 5
|
24天前
|
人工智能 安全 测试技术
Apipost vs Apifox:AI 能力决定 API 开发管理工具的真正价值
2025年,AI技术深度融入企业运营,提升生产力与竞争力。在API开发工具领域,Apipost与Apifox在AI能力上有显著差异。Apipost实现AI全流程覆盖,从文档生成、测试、开发辅助到协作优化,大幅提升效率并降低维护成本;而Apifox主要聚焦文档优化,功能较基础。在团队协作、安全合规、企业适配等方面,Apipost亦表现更优,尤其适合追求高效、安全与全流程自动化的团队。
55 1
|
25天前
|
Java API 网络架构
基于 Spring Boot 框架开发 REST API 接口实践指南
本文详解基于Spring Boot 3.x构建REST API的完整开发流程,涵盖环境搭建、领域建模、响应式编程、安全控制、容器化部署及性能优化等关键环节,助力开发者打造高效稳定的后端服务。
108 1
|
19天前
|
缓存 JSON 算法
电商数据API开发实战经验分享(实操)
本文分享了一位电商开发者在API实战中的经验总结,涵盖签名生成、数据解析、缓存策略及测试方案,附完整代码示例,助你避开开发“深坑”。
|
25天前
|
JavaScript API 开发者
Uniapp开发鸿蒙应用教程之选项式api和组合式api
本文介绍了在Uniapp开发鸿蒙应用时,如何通过选项式API和组合式API进行数据操作。以修改年龄值为例,对比展示了两种API的代码结构与区别,并重点演示了组合式API中更简洁、灵活的写法,帮助开发者理解并掌握现代Vue开发模式。#鸿蒙三方框架 #Uniapp

热门文章

最新文章