前言
在上一篇文章，已经实现了访问指定URL就返回了指定的数据，这也体现了RESTful API的一个理念，每个URL表明着一个资源。固然咱们还知道RESTful API的另外一个特性就是，发送不一样的请求动做，会返还不一样的响应，这篇文章就讲一下django-rest-framework这个工具在这方面给咱们带来的便捷操做。django
Request对象
平时咱们在写Django的视图函数的时候，都会带上一个request参数，这样就能处理平时搭建网站时，浏览器访问网页时发出的常规的HttpRequest。可是如今咱们导入了django-rest-framework，它可以对request进行拓展，而且提供更灵活的请求解析。这个特性体如今哪呢？请看下面这个例子：json
request.POST #只能处理表单数据.只能处理POST请求
request.data #能处理各类数据。 能够处理'POST', 'PUT' 和 'PATCH'模式的请求
这个例子里面的注释已经说得很清楚，拓展后的request使用request.data就能够处理各类各样的请求了，而本来的request在处理时须要指定请求模式。api
Response对象
和request对象同样，django-rest-framework也对其进行了很实用的拓展，在我上一篇文章的snippets/views.py中，咱们导入了JsonResponse用于返回json格式的响应，在视图函数中是这样的：浏览器
@csrf_exemptdefsnippet_list(request):"""列出全部已经存在的snippet或者建立一个新的snippet"""
if request.method == 'GET':
snippets=Snippet.objects.all()
serializer= SnippetSerializer(snippets, many=True)return JsonResponse(serializer.data, safe=False)elif request.method == 'POST':
data=JSONParser().parse(request)
serializer= SnippetSerializer(data=data)ifserializer.is_valid():
serializer.save()return JsonResponse(serializer.data, status=201)return JsonResponse(serializer.errors, status=400)
也就是说，在return的时候就须要指明json格式，这样显得很不实用并且很单一，因此通过拓展后的Reponse对象就很方便了，它会根据客户端的请求头部信息来肯定正确的内容类型以返回给客户端。只需以下代码：restful
return Response(data)
稍后会改进上一篇文章的程序对此进一步的具体讲解。app
状态码
咱们知道发送http请求时会返回各类各样的状态吗，可是都是简单的数字，好比200、404等，这些纯数字标识符有时候可能不够明确或者客户端在使用的时候不清楚错误信息甚至是没注意看不到，因此django-rest-framework也对此进行了优化，状态码会是HTTP_400_BAD_REQUEST、HTTP_404_NOT_FOUND这种，极大的提升可读性。框架
装饰API视图
REST框架还提供了一个装饰器和一个类来包装视图函数，可使用它们来写API视图，让程序能处理的状况更多。函数
@api_view装饰器用在基于视图的方法上。
APIView类用在基于视图的类上。
注意：本文使用的是基于视图方法，因此使用的是装饰器@api_view，APIview这个类暂时不会说起。工具
这两个东西提供的一些功能，让咱们省去不少工做，好比说确保你在视图中收到Request对象或在你的Response对象中添加上下文，这样就能实现内容通讯。
另外装饰器能够在接收到输入错误的request.data时抛出ParseError异常，或者在适当的时候返回405 Method Not Allowed状态码。
把这些都使用起来
上面说了这么多拓展和优化，接下来就把它们都使用起来，改进一下本来的snippets/views.py，程序以下：
from rest_framework importstatusfrom rest_framework.decorators importapi_viewfrom rest_framework.response importResponsefrom snippets.models importSnippetfrom snippets.serializers importSnippetSerializer
@api_view(['GET', 'POST'])defsnippet_list(request):"""列出全部已经存在的snippet或者建立一个新的snippet"""
if request.method == 'GET':
snippets=Snippet.objects.all()
serializer= SnippetSerializer(snippets, many=True)returnResponse(serializer.data)elif request.method == 'POST':
serializer= SnippetSerializer(data=request.data)ifserializer.is_valid():
serializer.save()return Response(serializer.data, status=status.HTTP_201_CREATED)return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
能够看出，通过改进的代码已经把上面所说的几个django-rest-framework带来的特性都应用起来了，咱们能够看出程序代码量变少，而且能处理的状况更多了。 好比说，在本来的视图函数snippet_detail中，处理'PUT'请求的时候，须要先解析json格式的数据再进一步处理：
data =JSONParser().parse(request)
serializer= SnippetSerializer(snippet, data=data)
也就是说须要分红两步实现，并且这里有一个限制就是只能解析json格式的数据流。而改进后的程序只需一行代码：
serializer = SnippetSerializer(data=request.data)
直接使用以前说的request.data就能够获取到提交过来的数据了，而且能够处理各类数据和各类请求动做，方便了开发。
还有在return的时候也不须要指定json格式了，由本来的
return JsonResponse(serializer.data, status=201)
改为了
return Response(serializer.data,status=status.HTTP_201_CREATED)
这也意味着返回给客户端的能够是json或者html等格式的内容，返回HTML格式的内容的话，会在浏览器返回通过渲染的、更美观的页面。同时能够看出状态码也改进成了django-rest-framework给咱们带来的可读性更高的状态标识码，以上这些措施都很大程度的提升了对客户的友好度。
对于另外一个视图函数的修改也是一样的原理，这里就不作一样的讲解了，代码以下：
@api_view(['GET', 'PUT', 'DELETE'])defsnippet_detail(request, pk):"""Retrieve, update or delete a snippet instance."""
try:
snippet= Snippet.objects.get(pk=pk)exceptSnippet.DoesNotExist:return Response(status=status.HTTP_404_NOT_FOUND)if request.method == 'GET':
serializer=SnippetSerializer(snippet)returnResponse(serializer.data)elif request.method == 'PUT':
serializer= SnippetSerializer(snippet, data=request.data)ifserializer.is_valid():
serializer.save()returnResponse(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提交过来的数据不须要必定是json格式的数据，返回的响应也不须要必定是json数据，也能够是通过渲染的HTML页面。稍后就会示范使用。
向URL添加可选的格式后缀
既然上面已经说了返回给客户端的Response但是json或者是HTML等格式的内容，那么用户在使用的时候是如何指定返回哪一种格式的内容呢，那就是在URL的最后加上后缀。好比http://127.0.0.1:8000/snippets.json，这样就是用户本身指定了返回json格式的Response，而不是咱们在后台指定返回固定的格式。
只需对咱们的程序稍加改进就能够了，在两个视图函数添加关键词参数format：
def snippet_list(request, format=None):
以及
def snippet_detail(request, pk, format=None):
再修改一下snippets/urls.py，导入format_suffix_patterns(格式后缀模式)：
from django.conf.urls importurlfrom rest_framework.urlpatterns importformat_suffix_patternsfrom snippets importviews
urlpatterns=[
url(r'^snippets/$', views.snippet_list),
url(r'^snippets/(?P[0-9]+)$', views.snippet_detail),
]
urlpatterns= format_suffix_patterns(urlpatterns)
改进后的使用
首先固然仍是能够像上一篇文章中那样的使用：
也能够经过设置Accept头部信息来控制返回的格式：
http http://127.0.0.1:8000/snippets/ Accept:application/json #Request JSON
http http://127.0.0.1:8000/snippets/ Accept:text/html #Request HTML
效果以下(返回的是页面的HTML代码，只展现了一部分)：
还能够直接加格式后缀：
http http://127.0.0.1:8000/snippets.json #JSON suffix
http http://127.0.0.1:8000/snippets.api #Browsable API suffix
固然啦，在命令行查看HTML代码就没啥意思了，咱们能够直接在浏览器输入 http://127.0.0.1:8000/snippets.api 进行查看，会获得一个美观的页面：
若是咱们要增添数据怎么办？咱们能够控制 Content-Type 头部信息来提交POST请求：
http --form POST http://127.0.0.1:8000/snippets/ code="print 123"http--json POST http://127.0.0.1:8000/snippets/ code="print 456"
它会自动在原有的数据后面添加你提交过去的数据，效果以下：
上面说了，改进后能够处理错误的提交，好比把code改为了codes，就会给出错误信息：
图中给出的错误信息是 400 Bad Request，这和咱们在视图函数中定义的是同样的：
return Response(serializer.data,status=status.HTTP_400_BAD_REQUEST)
在请求中若是加入了--debug能够查看到详细的请求信息和类型：
在上面介绍@api_view和APIView的时候，提到了在适当的时候返回405 Method Not Allowed状态码。这个所谓适当的时候就要回看到刚才写视图函数的时候，修饰器的代码：
@api_view(['GET','POST'])
以及
@api_view(['GET','PUT','DELETE'])
这两行代码就规定了在调用这两个函数，也就是访问到相关的URL时，只能使用指定的请求动做，不然就会报出405 Method Not Allowed错误。例如访问 http://127.0.0.1:8000/snippets.json 时用了PUT请求就会报这个错：
正确的更改数据应该以下：
http --json PUT http://127.0.0.1:8000/snippets/1.json code="hello world"
这样就把 id=1 的数据修改了。想要删除也是同样的：
这样就能够把 id=3 的数据删除掉了。
OK，关于Django RESTful API的请求和响应部分的处理就先讲到这了。下一篇会介绍基于类的视图，多谢支持~
本文地址：http://www.cnblogs.com/zivwong/p/7427394.html
做者博客：ziv
欢迎转载，请在明显位置给出出处及连接