diff --git a/docs/tutorial/1-serialization.md b/docs/tutorial/1-serialization.md index cd4b75584..5d8303150 100644 --- a/docs/tutorial/1-serialization.md +++ b/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 diff --git a/docs/tutorial/2-requests-and-responses.md b/docs/tutorial/2-requests-and-responses.md index d889b1e00..13feb2546 100644 --- a/docs/tutorial/2-requests-and-responses.md +++ b/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? diff --git a/docs/tutorial/3-class-based-views.md b/docs/tutorial/3-class-based-views.md index 25d5773f1..b2b6443c5 100644 --- a/docs/tutorial/3-class-based-views.md +++ b/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. diff --git a/docs/tutorial/6-resource-orientated-projects.md b/docs/tutorial/6-resource-orientated-projects.md index 3c3e7fedc..e7190a772 100644 --- a/docs/tutorial/6-resource-orientated-projects.md +++ b/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.