从这一点开始,我们将真正开始覆盖REST框架的核心。我们来介绍几个基本的构建块。
请求对象(Request object)。
REST框架引入了一个扩展了常规HttpRequest
,的Request
对象,并提供了更灵活的请求解析。Request
对象的核心功能是request.data
属性,它与request.POST
类似,但对于使用Web API更为有用。
request.POST # 只能处理表单(form)数据,只适用于“POST”方法. request.data # 处理任意数据.可以处理'POST', 'PUT' 和 'PATCH'方法.
响应对象(Response object)
REST框架还引入了一个Response
对象,这是一种获取未渲染(unrendered)内容的TemplateResponse类型,并使用内容协商来确定返回给客户端的正确内容类型。
return Response(data) # 渲染成客户端请求的内容类型。
状态码(Status codes)
在你的视图(views)中使用纯数字的HTTP 状态码并不总是那么容易被理解。而且如果错误代码出错,很容易被忽略。REST框架为status
模块中的每个状态代码(如HTTP_400_BAD_REQUEST
)提供更明确的标识符。使用它们来代替纯数字的HTTP状态码是个很好的主意。
包装(wrapping )API视图
REST框架提供了两种编写API视图的封装。
@api_view
装饰器,基于方法的视图。继承
APIView
类,基于类的视图。
这些视图封装提供了一些功能,例如确保你的视图能够Request
接收实例,并将上下文添加到Response
对象,使得 内容协商(content negotiation) 可以正常的运作。
试图封装,内置了一些行为,比如:在遇到错误请求时,自动响应405 Method Not Allowed
,在处理request.data
时,因为输入的格式不正确,而发生的任何ParseError
异常,
REST框架提供了两个可用于编写API视图的包装器(wrappers)。
用于基于函数视图的
@api_view
装饰器。用于基于类视图的
类。
这些包装器提供了一些功能,例如确保你在视图中接收到Request
实例,并将上下文添加到Response
对象,以便可以执行内容协商。
包装器还提供了诸如在适当时候返回405 Method Not Allowed
响应,并处理在使用格式错误的输入来访问request.data
时发生的任何ParseError
异常。
组合在一起
好的,我们开始使用这些新的组件来写几个视图。
我们在views.py
文件中不再需要JSONResponse
类了,所以把它删除掉。删除之后,我们就可以开始重构我们的视图了。
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): """ 列出所有的snippets,或者创建一个新的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)
我们的实例视图比前面的示例有所改进。它稍微简洁一点,现在的代码与我们使用Forms API时非常相似。我们还使用了命名状态代码,这使得响应意义更加明显。
以下是模块中单个snippet的视图。
@api_view(['GET', 'PUT', 'DELETE']) def snippet_detail(request, pk): """ 获取,更新或删除一个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)
这对我们来说应该都是非常熟悉的,-它和正常Django视图并没有什么不同。
注意,我们不再显式地将请求或响应绑定到给定的内容类型。request.data
可以处理传入的json
请求,但它也可以处理其他格式。同样,我们返回带有数据的响应对象,但允许REST框架将响应给我们渲染成正确的内容类型。
向我们的网址添加可选的格式后缀
为了充分利用我们的响应不再与单一内容类型连接,我们可以为API路径添加对格式后缀的支持。使用格式后缀给我们明确指定了给定格式的URL,这意味着我们的API将能够处理诸如http://example.com/api/items/4.json之类的URL。
def snippet_list(request, format=None):
还有:
def snippet_detail(request, pk,sans-serif;'>更新urls.py
文件,给现有的URL后面添加一组format_suffix_patterns
from django.conf.urls import url from rest_framework.urlpatterns import format_suffix_patterns from snippets import views urlpatterns = [ url(r'^snippets/$', views.snippet_list), url(r'^snippets/(?P<pk>[0-9]+)$', views.snippet_detail),] urlpatterns = format_suffix_patterns(urlpatterns)给现有的URL后面添加一组
怎么查看结果?
从命令行开始测试API,就像我们在教程第1部分中所做的那样。一切操作都很相似,尽管我们发送无效的请求也会有一些更好的错误处理了。
我们可以像以前一样获取所有snippet的列表
http http://127.0.0.1:8000/snippets/ HTTP/1.1 200 OK ... [ { "id": 1, "title": "", "code": "foo = \"bar\"\n", "linenos": false, "language": "python", "style": "friendly" }, { "id": 2, "code": "print \"hello, world\"\n", "style": "friendly" } ]我们可以通过使用
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://127.0.0.1:8000/snippets.api # 可视化 API 后缀类似地,我们可以使用
Content-Type
头控制我们发送的请求的格式。# POST表单数据 http --form POST http://127.0.0.1:8000/snippets/ code="print 123" { "id": 3, "title": "", "code": "print 123", "linenos": false, "language": "python", "style": "friendly" } # POST表单数据 http --json POST http://127.0.0.1:8000/snippets/ code="print 456" { "id": 4, "code": "print 456", "style": "friendly" }如果您
--debug
向上述http
请求添加切换器,则可以在请求标头中查看请求类型。现在,在Web浏览器中打开API,访问
如果你向上述http请求添加了
--debug
,则可以在http
请求标头中查看请求类型。现在可以在浏览器中访问http://127.0.0.1:8000/snippets/查看API。
浏览功能
由于API根据客户端请求选择响应的内容类型,因此默认情况下,当Web浏览器请求该资源时,它将返回资源的HTML格式表示。这允许API返回完全浏览器可浏览(web-browsable)的HTML表示。
拥有支持浏览器可浏览的API在可用性方面完胜并使开发和使用你的API更容易。它也大大降低了其他开发人员要检查和使用API的障碍。
有关支持浏览器可浏览的API功能以及如何自定义API的更多信息,请参阅可浏览的api主题。
下一步是什么?
在第3部分的教程中,我们将开始使用基于类的视图,并查看通用视图如何减少需要编写的代码量。
Django REST FrameWork中文文档目录:
Django REST FrameWork 中文教程1:序列化
Django REST FrameWork 中文教程2:请求和响应
Django REST FrameWork 中文教程3:基于类的视图
Django REST FrameWork 中文教程4:验证和权限
Django REST FrameWork 中文教程5:关系和超链接API
Django REST FrameWork 中文教程6: ViewSets&Routers
Django REST FrameWork 中文教程7:模式和客户端库
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 [email protected] 举报,一经查实,本站将立刻删除。