Fixed references to serializer.serialized and serializer.serialized_errors

in part 3 of the tutorial.  Altered part 1 to use blogs/urls.py since it was
specified at the beginning.  Also caught some spelling errors while I was at it.

docs/tutorial/1-serialization.md

@@ -78,7 +78,7 @@ Don't forget to sync the database for the first time.
 
 ## Creating a Serializer class
 
-We're going to create a simple Web API that we can use to edit these comment objects with.  The first thing we need is a way of serializing and deserializing the objects into representations such as `json`.  We do this by declaring serializers, that work very similarly to Django's forms.  Create a file in the project named `serializers.py` and add the following.
+We're going to create a simple Web API that we can use to edit these comment objects with.  The first thing we need is a way of serializing and deserializing the objects into representations such as `json`.  We do this by declaring serializers that work very similarly to Django's forms.  Create a file in the project named `serializers.py` and add the following.
 
     from blog import models
     from rest_framework import serializers
@@ -201,7 +201,7 @@ The root of our API is going to be a view that supports listing all the existing
 
 Note that because we want to be able to POST to this view from clients that won't have a CSRF token we need to mark the view as `csrf_exempt`.  This isn't something that you'd normally want to do, and REST framework views actually use more sensible behavior than this, but it'll do for our purposes right now. 
 
-We'll also need a view which corrosponds to an individual comment, and can be used to retrieve, update or delete the comment.
+We'll also need a view which corresponds to an individual comment, and can be used to retrieve, update or delete the comment.
 
     @csrf_exempt
     def comment_instance(request, pk):
@@ -231,7 +231,7 @@ We'll also need a view which corrosponds to an individual comment, and can be us
             comment.delete()
             return HttpResponse(status=204)
 
-Finally we need to wire these views up, in the `tutorial/urls.py` file.
+Finally we need to wire these views up. Create the `blog/urls.py` file:
 
     from django.conf.urls import patterns, url
 

docs/tutorial/2-requests-and-responses.md

@@ -27,7 +27,7 @@ REST framework provides two wrappers you can use to write API views.
 1. The `@api_view` decorator for working with function based views.
 2. The `APIView` class for working with class based views.
 
-These wrappers provide a few bits of functionality such as making sure you recieve `Request` instances in your view, and adding context to `Response` objects so that content negotiation can be performed.
+These wrappers provide a few bits of functionality such as making sure you receive `Request` instances in your view, and adding context to `Response` objects so that content negotiation can be performed.
 
 The wrappers also provide behaviour such as returning `405 Method Not Allowed` responses when appropriate, and handling any `ParseError` exception that occurs when accessing `request.DATA` with malformed input.
 
@@ -121,7 +121,7 @@ Now update the `urls.py` file slightly, to append a set of `format_suffix_patter
     
     urlpatterns = format_suffix_patterns(urlpatterns)
 
-We don't necessarily need to add these extra url patterns in, but it gives us a simple, clean way of refering to a specific format.
+We don't necessarily need to add these extra url patterns in, but it gives us a simple, clean way of referring to a specific format.
 
 ## How's it looking?
 

docs/tutorial/3-class-based-views.md

@@ -28,10 +28,10 @@ We'll start by rewriting the root view as a class based view.  All this involves
             if serializer.is_valid():
                 comment = serializer.object
                 comment.save()
-                return Response(serializer.serialized, status=status.HTTP_201_CREATED)
-            return Response(serializer.serialized_errors, status=status.HTTP_400_BAD_REQUEST)
+                return Response(serializer.data, status=status.HTTP_201_CREATED)
+            return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
 
-So far, so good.  It looks pretty similar to the previous case, but we've got better seperation between the different HTTP methods.  We'll also need to update the instance view. 
+So far, so good.  It looks pretty similar to the previous case, but we've got better separation between the different HTTP methods.  We'll also need to update the instance view. 
 
     class CommentInstance(APIView):
         """
@@ -145,7 +145,7 @@ Using the mixin classes we've rewritten the views to use slightly less code than
         model = Comment
         serializer_class = CommentSerializer
 
-Wow, that's pretty concise.  We've got a huge amount for free, and our code looks like good, clean, idomatic Django.
+Wow, that's pretty concise.  We've got a huge amount for free, and our code looks like good, clean, idiomatic Django.
 
 Next we'll move onto [part 4 of the tutorial][tut-4], where we'll take a look at how we can  customize the behavior of our views to support a range of authentication, permissions, throttling and other aspects.
 

docs/tutorial/6-resource-orientated-projects.md

@@ -4,8 +4,8 @@ Resource classes are just View classes that don't have any handler methods bound
 
 This allows us to:
 
-* Encapsulate common behaviour accross a class of views, in a single Resource class.
-* Seperate out the actions of a Resource from the specfics of how those actions should be bound to a particular set of URLs.
+* Encapsulate common behaviour across a class of views, in a single Resource class.
+* Separate out the actions of a Resource from the specfics of how those actions should be bound to a particular set of URLs.
 
 ## Refactoring to use Resources, not Views
 
@@ -59,7 +59,7 @@ Right now that hasn't really saved us a lot of code.  However, now that we're us
 
 ## Trade-offs between views vs resources.
 
-Writing resource-orientated code can be a good thing.  It helps ensure that URL conventions will be consistent across your APIs, and minimises the amount of code you need to write.
+Writing resource-oriented code can be a good thing.  It helps ensure that URL conventions will be consistent across your APIs, and minimises the amount of code you need to write.
 
 The trade-off is that the behaviour is less explict.  It can be more difficult to determine what code path is being followed, or where to override some behaviour.