|
从这一点开始，我们将真正开始覆盖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。
像下面这样在这两个视图中添加一个format关键字参数。
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：模式和客户端库
（编辑：李大同）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
