Added the api_view decorator

1 files changed, 18 insertions, 13 deletions

diff --git a/docs/tutorial/2-requests-and-responses.md b/docs/tutorial/2-requests-and-responses.md
index 2bb6c20e..9309f6e0 100644
--- a/docs/tutorial/2-requests-and-responses.md
+++ b/docs/tutorial/2-requests-and-responses.md
@@ -36,14 +36,19 @@ The wrappers also provide behaviour such as returning `405 Method Not Allowed` r
 
 Okay, let's go ahead and start using these new components to write a few views. 
 
+We don't need our `JSONResponse` class anymore, so go ahead and delete that.  Once that's done we can start refactoring our views slightly.
+
+    from blog.models import Comment
+    from blog.serializers import CommentSerializer
+    from djangorestframework import status
     from djangorestframework.decorators import api_view
-    from djangorestframework.status import *
+    from djangorestframework.response import Response
 
-    @api_view(allow=['GET', 'POST'])
+    @api_view(['GET', 'POST'])
     def comment_root(request):
         """
         List all comments, or create a new comment.
-        """ 
+        """
         if request.method == 'GET':
             comments = Comment.objects.all()
             serializer = CommentSerializer(instance=comments)
@@ -54,14 +59,14 @@ Okay, let's go ahead and start using these new components to write a few views.
             if serializer.is_valid():
                 comment = serializer.object
                 comment.save()
-                return Response(serializer.data, status=HTTP_201_CREATED)
+                return Response(serializer.data, status=status.HTTP_201_CREATED)
             else:
-                return Response(serializer.error_data, status=HTTP_400_BAD_REQUEST)
+                return Response(serializer.error_data, status=status.HTTP_400_BAD_REQUEST)
 
 
-Our instance view is an improvement over the previous example.  It's slightly more concise, and the code now feels very similar to if we were working with the Forms API.
+Our instance view is an improvement over the previous example.  It's a little more concise, and the code now feels very similar to if we were working with the Forms API.  We're also using named status codes, which makes the response meanings more obvious.
 
-    @api_view(allow=['GET', 'PUT', 'DELETE'])
+    @api_view(['GET', 'PUT', 'DELETE'])
     def comment_instance(request, pk):
         """
         Retrieve, update or delete a comment instance.
@@ -69,7 +74,7 @@ Our instance view is an improvement over the previous example.  It's slightly mo
         try:
             comment = Comment.objects.get(pk=pk)
         except Comment.DoesNotExist:
-            return Response(status=HTTP_404_NOT_FOUND)
+            return Response(status=status.HTTP_404_NOT_FOUND)
  
         if request.method == 'GET':
             serializer = CommentSerializer(instance=comment)
@@ -82,19 +87,19 @@ Our instance view is an improvement over the previous example.  It's slightly mo
                 comment.save()
                 return Response(serializer.data)
             else:
-                return Response(serializer.error_data, status=HTTP_400_BAD_REQUEST)
+                return Response(serializer.error_data, status=status.HTTP_400_BAD_REQUEST)
 
         elif request.method == 'DELETE':
             comment.delete()
-            return Response(status=HTTP_204_NO_CONTENT)
+            return Response(status=status.HTTP_204_NO_CONTENT)
 
-This should all feel very familiar - it looks a lot like working with forms in regular Django views.
+This should all feel very familiar - there's not a lot different to working with regular Django views.
 
 Notice that we're no longer explicitly tying our requests or responses to a given content type.  `request.DATA` can handle incoming `json` requests, but it can also handle `yaml` and other formats.  Similarly we're returning response objects with data, but allowing REST framework to render the response into the correct content type for us.
 
 ## Adding optional format suffixes to our URLs
 
-To take advantage of that, let's add support for format suffixes to our API endpoints, so that we can use URLs that explicitly refer to a given format.  That means our API will be able to handle URLs such as [http://example.com/api/items/4.json][1].
+To take advantage of the fact that our responses are no longer hardwired to a single content type let's add support for format suffixes to our API endpoints. Using format suffixes gives us URLs that explicitly refer to a given format, and means our API will be able to handle URLs such as [http://example.com/api/items/4.json][json-url].
 
 Start by adding a `format` keyword argument to both of the views, like so.
 
@@ -131,7 +136,7 @@ Now go and open the API in a web browser, by visiting [http://127.0.0.1:8000/][3
 
 In [tutorial part 3][4], we'll start using class based views, and see how generic views reduce the amount of code we need to write.
 
-[1]: http://example.com/api/items/4.json
+[json-url]: http://example.com/api/items/4.json
 [2]: 1-serialization.md
 [3]: http://127.0.0.1:8000/
 [4]: 3-class-based-views.md
\ No newline at end of file