11 files changed, 119 insertions, 46 deletions
diff --git a/docs/api-guide/fields.md b/docs/api-guide/fields.md
index 1d4c34cb..50a09701 100644
--- a/docs/api-guide/fields.md
+++ b/docs/api-guide/fields.md
@@ -293,6 +293,7 @@ By default these fields are read-write, although you can change this behaviour u
 **Arguments**:
 
 * `queryset` - By default `ModelSerializer` classes will use the default queryset for the relationship.  `Serializer` classes must either set a queryset explicitly, or set `read_only=True`.
+* `null` - If set to `True`, the field will accept values of `None` or the emptystring for nullable relationships.
 
 ## SlugRelatedField / ManySlugRelatedField
 
@@ -304,6 +305,7 @@ By default these fields read-write, although you can change this behaviour using
 
 * `slug_field` - The field on the target that should be used to represent it.  This should be a field that uniquely identifies any given instance.  For example, `username`.
 * `queryset` - By default `ModelSerializer` classes will use the default queryset for the relationship.  `Serializer` classes must either set a queryset explicitly, or set `read_only=True`.
+* `null` - If set to `True`, the field will accept values of `None` or the emptystring for nullable relationships.
 
 ## HyperlinkedRelatedField / ManyHyperlinkedRelatedField
 
@@ -319,6 +321,7 @@ By default, `HyperlinkedRelatedField` is read-write, although you can change thi
 * `slug_field` - The field on the target that should be used for the lookup. Default is `'slug'`.
 * `pk_url_kwarg` - The named url parameter for the pk field lookup. Default is `pk`.
 * `slug_url_kwarg` - The named url parameter for the slug field lookup. Default is to use the same value as given for `slug_field`.
+* `null` - If set to `True`, the field will accept values of `None` or the emptystring for nullable relationships.
 
 ## HyperLinkedIdentityField
 
diff --git a/docs/api-guide/permissions.md b/docs/api-guide/permissions.md
index 1a746fb6..fce68f6d 100644
--- a/docs/api-guide/permissions.md
+++ b/docs/api-guide/permissions.md
@@ -53,7 +53,7 @@ You can also set the authentication policy on a per-view basis, using the `APIVi
 Or, if you're using the `@api_view` decorator with function based views.
 
     @api_view('GET')
-    @permission_classes(IsAuthenticated)
+    @permission_classes((IsAuthenticated, ))
     def example_view(request, format=None):
         content = {
             'status': 'request was permitted'
diff --git a/docs/topics/credits.md b/docs/topics/credits.md
index f2f09c0e..ba37ce11 100644
--- a/docs/topics/credits.md
+++ b/docs/topics/credits.md
@@ -71,6 +71,14 @@ The following people have helped make REST framework great.
 * Fabian Buechler - [fabianbuechler]
 * Mark Hughes - [mhsparks]
 * Michael van de Waeter - [mvdwaeter]
+* Reinout van Rees - [reinout]
+* Michael Richards - [justanotherbody]
+* Ben Roberts - [roberts81]
+* Venkata Subramanian Mahalingam - [annacoder]
+* George Kappel - [gkappel]
+* Colin Murtaugh - [cmurtaugh]
+* Simon Pantzare - [pilt]
+* Szymon Teżewski - [sunscrapers]
 
 Many thanks to everyone who's contributed to the project.
 
@@ -177,3 +185,11 @@ To contact the author directly:
 [fabianbuechler]: https://github.com/fabianbuechler
 [mhsparks]: https://github.com/mhsparks
 [mvdwaeter]: https://github.com/mvdwaeter
+[reinout]: https://github.com/reinout
+[justanotherbody]: https://github.com/justanotherbody
+[roberts81]: https://github.com/roberts81
+[annacoder]: https://github.com/annacoder
+[gkappel]: https://github.com/gkappel
+[cmurtaugh]: https://github.com/cmurtaugh
+[pilt]: https://github.com/pilt
+[sunscrapers]: https://github.com/sunscrapers
diff --git a/docs/topics/release-notes.md b/docs/topics/release-notes.md
index 867b138b..66d6f7f3 100644
--- a/docs/topics/release-notes.md
+++ b/docs/topics/release-notes.md
@@ -4,19 +4,55 @@
 >
 > &mdash; Eric S. Raymond, [The Cathedral and the Bazaar][cite].
 
-## 2.1.6
+## 2.1.x series
+
+### 2.1.10
+
+**Date**: 17th Dec 2012
+
+* Bugfix: Ensure read-only fields don't have model validation applied.
+* Bugfix: Fix hyperlinked fields in paginated results.
+
+### 2.1.9
+
+**Date**: 11th Dec 2012
+
+* Bugfix: Fix broken nested serialization.
+* Bugfix: Fix `Meta.fields` only working as tuple not as list.
+* Bugfix: Edge case if unnecessarily specifying `required=False` on read only field.
+
+### 2.1.8
+
+**Date**: 8th Dec 2012
+
+* Fix for creating nullable Foreign Keys with `''` as well as `None`.
+* Added `null=<bool>` related field option.
+
+### 2.1.7
+
+**Date**: 7th Dec 2012
+
+* Serializers now properly support nullable Foreign Keys.
+* Serializer validation now includes model field validation, such as uniqueness constraints.
+* Support 'true' and 'false' string values for BooleanField.
+* Added pickle support for serialized data.
+* Support `source='dotted.notation'` style for nested serializers.
+* Make `Request.user` settable.
+* Bugfix: Fix `RegexField` to work with `BrowsableAPIRenderer`.
+
+### 2.1.6
 
 **Date**: 23rd Nov 2012
 
 * Bugfix: Unfix DjangoModelPermissions.  (I am a doofus.)
 
-## 2.1.5
+### 2.1.5
 
 **Date**: 23rd Nov 2012
 
 * Bugfix: Fix DjangoModelPermissions.
 
-## 2.1.4
+### 2.1.4
 
 **Date**: 22nd Nov 2012
 
@@ -27,7 +63,7 @@
 * Added `obtain_token_view` to get tokens when using `TokenAuthentication`.
 * Bugfix: Django 1.5 configurable user support for `TokenAuthentication`.
 
-## 2.1.3
+### 2.1.3
 
 **Date**: 16th Nov 2012
 
@@ -38,14 +74,14 @@
 * 201 Responses now return a 'Location' header.
 * Bugfix: Serializer fields now respect `max_length`.
 
-## 2.1.2
+### 2.1.2
 
 **Date**: 9th Nov 2012
 
 * **Filtering support.**
 * Bugfix: Support creation of objects with reverse M2M relations.
 
-## 2.1.1
+### 2.1.1
 
 **Date**: 7th Nov 2012
 
@@ -55,7 +91,7 @@
 * Bugfix: Make textareas same width as other fields in browsable API.
 * Private API change: `.get_serializer` now uses same `instance` and `data` ordering as serializer initialization.
 
-## 2.1.0
+### 2.1.0
 
 **Date**: 5th Nov 2012
 
@@ -69,13 +105,17 @@
 * Bugfix: Support choice field in Browseable API.
 * Bugfix: Related fields with `read_only=True` do not require a `queryset` argument.
 
-## 2.0.2
+---
+
+## 2.0.x series
+
+### 2.0.2
 
 **Date**: 2nd Nov 2012
 
 * Fix issues with pk related fields in the browsable API.
 
-## 2.0.1
+### 2.0.1
 
 **Date**: 1st Nov 2012
 
@@ -83,7 +123,7 @@
 * Added SlugRelatedField and ManySlugRelatedField.
 * If PUT creates an instance return '201 Created', instead of '200 OK'.
 
-## 2.0.0
+### 2.0.0
 
 **Date**: 30th Oct 2012
 
@@ -92,7 +132,9 @@
 
 ---
 
-## 0.4.0
+## 0.4.x series
+
+### 0.4.0
 
 * Supports Django 1.5.
 * Fixes issues with 'HEAD' method.
@@ -104,7 +146,11 @@
 * Improve setup (eg use staticfiles, not the defunct ADMIN_MEDIA_PREFIX)
 * Sensible absolute URL generation, not using hacky set_script_prefix
 
-## 0.3.3
+---
+
+## 0.3.x series
+
+### 0.3.3
 
 * Added DjangoModelPermissions class to support `django.contrib.auth` style permissions.
 * Use `staticfiles` for css files.
@@ -119,7 +165,7 @@
 * Bugfixes:
   - Bug with PerUserThrottling when user contains unicode chars.
 
-## 0.3.2
+### 0.3.2
 
 * Bugfixes:
   * Fix 403 for POST and PUT from the UI with UserLoggedInAuthentication (#115)
@@ -131,37 +177,41 @@
 * get_name, get_description become methods on the view - makes them overridable.
 * Improved model mixin API - Hooks for build_query, get_instance_data, get_model, get_queryset, get_ordering
 
-## 0.3.1
+### 0.3.1
 
 * [not documented]
 
-## 0.3.0
+### 0.3.0
 
 * JSONP Support
 * Bugfixes, including support for latest markdown release
 
-## 0.2.4
+---
+
+## 0.2.x series
+
+### 0.2.4
 
 * Fix broken IsAdminUser permission.
 * OPTIONS support.
 * XMLParser.
 * Drop mentions of Blog, BitBucket.
 
-## 0.2.3
+### 0.2.3
 
 * Fix some throttling bugs.
 * ``X-Throttle`` header on throttling.
 * Support for nesting resources on related models.
 
-## 0.2.2
+### 0.2.2
 
 * Throttling support complete.
 
-## 0.2.1
+### 0.2.1
 
 * Couple of simple bugfixes over 0.2.0
 
-## 0.2.0
+### 0.2.0
 
 * Big refactoring changes since 0.1.0, ask on the discussion group if anything isn't clear.
   The public API has been massively cleaned up.  Expect it to be fairly stable from here on in.
@@ -185,11 +235,15 @@
 * The mixin classes have been nicely refactored, the basic mixins are now ``RequestMixin``, ``ResponseMixin``, ``AuthMixin``, and ``ResourceMixin``
   You can reuse these mixin classes individually without using the ``View`` class.
 
-## 0.1.1
+---
+
+## 0.1.x series
+
+### 0.1.1
 
 * Final build before pulling in all the refactoring changes for 0.2, in case anyone needs to hang on to 0.1.
 
-## 0.1.0
+### 0.1.0
 
 * Initial release.
 
diff --git a/docs/topics/rest-hypermedia-hateoas.md b/docs/topics/rest-hypermedia-hateoas.md
index d7646892..10ab9dfe 100644
--- a/docs/topics/rest-hypermedia-hateoas.md
+++ b/docs/topics/rest-hypermedia-hateoas.md
@@ -32,7 +32,7 @@ REST framework also includes [serialization] and [parser]/[renderer] components
 
 ## What REST framework doesn't provide.
 
-What REST framework doesn't do is give you is machine readable hypermedia formats such as [Collection+JSON][collection] or HTML [microformats] by default, or the ability to auto-magically create fully HATEOAS style APIs that include hypermedia-based form descriptions and semantically labelled hyperlinks.  Doing so would involve making opinionated choices about API design that should really remain outside of the framework's scope.
+What REST framework doesn't do is give you is machine readable hypermedia formats such as [HAL][hal], [Collection+JSON][collection] or HTML [microformats] by default, or the ability to auto-magically create fully HATEOAS style APIs that include hypermedia-based form descriptions and semantically labelled hyperlinks.  Doing so would involve making opinionated choices about API design that should really remain outside of the framework's scope.
 
 [cite]: http://vimeo.com/channels/restfest/page:2
 [dissertation]: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
@@ -44,6 +44,7 @@ What REST framework doesn't do is give you is machine readable hypermedia format
 [readinglist]: http://blog.steveklabnik.com/posts/2012-02-27-hypermedia-api-reading-list
 [maturitymodel]: http://martinfowler.com/articles/richardsonMaturityModel.html
 
+[hal]: http://stateless.co/hal_specification.html
 [collection]: http://www.amundsen.com/media-types/collection/
 [microformats]: http://microformats.org/wiki/Main_Page
 [serialization]: ../api-guide/serializers.md
diff --git a/docs/tutorial/1-serialization.md b/docs/tutorial/1-serialization.md
index ba64f2aa..e61fb946 100644
--- a/docs/tutorial/1-serialization.md
+++ b/docs/tutorial/1-serialization.md
@@ -14,7 +14,7 @@ The tutorial is fairly in-depth, so you should probably get a cookie and a cup o
 
 ## Setting up a new environment
 
-Before we do anything else we'll create a new virtual environment, using [virtualenv].  This will make sure our package configuration is keep nicely isolated from any other projects we're working on.
+Before we do anything else we'll create a new virtual environment, using [virtualenv].  This will make sure our package configuration is kept nicely isolated from any other projects we're working on.
 
     :::bash
     mkdir ~/env
@@ -39,7 +39,6 @@ To get started, let's create a new project to work with.
     cd tutorial
 
 Once that's done we can create an app that we'll use to create a simple Web API.
-We're going to create a project that 
 
     python manage.py startapp snippets
 
@@ -64,7 +63,7 @@ We'll also need to add our new `snippets` app and the `rest_framework` app to `I
         'snippets'
     )
 
-We also need to wire up the root urlconf, in the `tutorial/urls.py` file, to include our snippet views.
+We also need to wire up the root urlconf, in the `tutorial/urls.py` file, to include our snippet app's URLs.
 
     urlpatterns = patterns('',
         url(r'^', include('snippets.urls')),
@@ -105,7 +104,7 @@ Don't forget to sync the database for the first time.
 
 ## Creating a Serializer class
 
-The first thing we need to get started on our Web API is provide a way of serializing and deserializing the snippet instances into representations such as `json`.  We can do this by declaring serializers that work very similarly to Django's forms.  Create a file in the `snippets` directory named `serializers.py` and add the following.
+The first thing we need to get started on our Web API is provide a way of serializing and deserializing the snippet instances into representations such as `json`.  We can do this by declaring serializers that work very similar to Django's forms.  Create a file in the `snippets` directory named `serializers.py` and add the following.
 
     from django.forms import widgets
     from rest_framework import serializers
@@ -146,7 +145,7 @@ We can actually also save ourselves some time by using the `ModelSerializer` cla
 
 ## Working with Serializers
 
-Before we go any further we'll familiarise ourselves with using our new Serializer class.  Let's drop into the Django shell.
+Before we go any further we'll familiarize ourselves with using our new Serializer class.  Let's drop into the Django shell.
 
     python manage.py shell
 
@@ -166,7 +165,7 @@ We've now got a few snippet instances to play with.  Let's take a look at serial
     serializer.data
     # {'pk': 1, 'title': u'', 'code': u'print "hello, world"\n', 'linenos': False, 'language': u'python', 'style': u'friendly'}
 
-At this point we've translated the model instance into python native datatypes.  To finalise the serialization process we render the data into `json`.
+At this point we've translated the model instance into python native datatypes.  To finalize the serialization process we render the data into `json`.
 
     content = JSONRenderer().render(serializer.data)
     content
@@ -292,7 +291,7 @@ Finally we need to wire these views up. Create the `snippets/urls.py` file:
         url(r'^snippets/(?P<pk>[0-9]+)/$', 'snippet_detail')
     )
 
-It's worth noting that there's a couple of edge cases we're not dealing with properly at the moment.  If we send malformed `json`, or if a request is made with a method that the view doesn't handle, then we'll end up with a 500 "server error" response.  Still, this'll do for now.
+It's worth noting that there are a couple of edge cases we're not dealing with properly at the moment.  If we send malformed `json`, or if a request is made with a method that the view doesn't handle, then we'll end up with a 500 "server error" response.  Still, this'll do for now.
 
 ## Testing our first attempt at a Web API
 
@@ -304,7 +303,7 @@ It's worth noting that there's a couple of edge cases we're not dealing with pro
 
 We're doing okay so far, we've got a serialization API that feels pretty similar to Django's Forms API, and some regular Django views.
 
-Our API views don't do anything particularly special at the moment, beyond serve `json` responses, and there's some error handling edge cases we'd still like to clean up, but it's a functioning Web API.
+Our API views don't do anything particularly special at the moment, beyond serving `json` responses, and there are some error handling edge cases we'd still like to clean up, but it's a functioning Web API.
 
 We'll see how we can start to improve things in [part 2 of the tutorial][tut-2].
 
diff --git a/docs/tutorial/2-requests-and-responses.md b/docs/tutorial/2-requests-and-responses.md
index 187effb9..08cf91cd 100644
--- a/docs/tutorial/2-requests-and-responses.md
+++ b/docs/tutorial/2-requests-and-responses.md
@@ -66,6 +66,8 @@ We don't need our `JSONResponse` class anymore, so go ahead and delete that.  On
 
 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.
 
+Here is the view for an individual snippet.
+
     @api_view(['GET', 'PUT', 'DELETE'])
     def snippet_detail(request, pk):
         """
@@ -92,7 +94,7 @@ Our instance view is an improvement over the previous example.  It's a little mo
             snippet.delete()
             return Response(status=status.HTTP_204_NO_CONTENT)
 
-This should all feel very familiar - there's not a lot different to working with regular Django views.
+This should all feel very familiar - it is not a lot different from 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.
 
@@ -128,7 +130,7 @@ Go ahead and test the API from the command line, as we did in [tutorial part 1][
 
 **TODO: Describe using accept headers, content-type headers, and format suffixed URLs**
 
-Now go and open the API in a web browser, by visiting [http://127.0.0.1:8000/snippets/][devserver]."
+Now go and open the API in a web browser, by visiting [http://127.0.0.1:8000/snippets/][devserver].
 
 ### Browsability
 
diff --git a/docs/tutorial/3-class-based-views.md b/docs/tutorial/3-class-based-views.md
index d87d2046..b115b022 100644
--- a/docs/tutorial/3-class-based-views.md
+++ b/docs/tutorial/3-class-based-views.md
@@ -102,14 +102,14 @@ Let's take a look at how we can compose our views by using the mixin classes.
         def post(self, request, *args, **kwargs):
             return self.create(request, *args, **kwargs)
 
-We'll take a moment to examine exactly what's happening here - We're building our view using `MultipleObjectAPIView`, and adding in `ListModelMixin` and `CreateModelMixin`.
+We'll take a moment to examine exactly what's happening here. We're building our view using `MultipleObjectAPIView`, and adding in `ListModelMixin` and `CreateModelMixin`.
 
 The base class provides the core functionality, and the mixin classes provide the `.list()` and `.create()` actions.  We're then explicitly binding the `get` and `post` methods to the appropriate actions.  Simple enough stuff so far.
 
     class SnippetDetail(mixins.RetrieveModelMixin,
                         mixins.UpdateModelMixin,
                         mixins.DestroyModelMixin,
-                        generics.SingleObjectBaseView):
+                        generics.SingleObjectAPIView):
         model = Snippet
         serializer_class = SnippetSerializer
 
@@ -122,7 +122,7 @@ The base class provides the core functionality, and the mixin classes provide th
         def delete(self, request, *args, **kwargs):
             return self.destroy(request, *args, **kwargs)
 
-Pretty similar.  This time we're using the `SingleObjectBaseView` class to provide the core functionality, and adding in mixins to provide the `.retrieve()`, `.update()` and `.destroy()` actions.
+Pretty similar.  This time we're using the `SingleObjectAPIView` class to provide the core functionality, and adding in mixins to provide the `.retrieve()`, `.update()` and `.destroy()` actions.
 
 ## Using generic class based views
 
@@ -142,7 +142,7 @@ Using the mixin classes we've rewritten the views to use slightly less code than
         model = Snippet
         serializer_class = SnippetSerializer
 
-Wow, that's pretty concise.  We've got a huge amount for free, and our code looks like good, clean, idiomatic Django.
+Wow, that's pretty concise.  We've gotten 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 deal with authentication and permissions for our API.
 
diff --git a/docs/tutorial/4-authentication-and-permissions.md b/docs/tutorial/4-authentication-and-permissions.md
index f85250be..9576a7f0 100644
--- a/docs/tutorial/4-authentication-and-permissions.md
+++ b/docs/tutorial/4-authentication-and-permissions.md
@@ -61,7 +61,7 @@ Now that we've got some users to work with, we'd better add representations of t
             model = User
             fields = ('id', 'username', 'snippets')
 
-Because `'snippets'` is a *reverse* relationship on the User model, it will not be included by default when using the `ModelSerializer` class, so we've needed to add an explicit field for it.
+Because `'snippets'` is a *reverse* relationship on the User model, it will not be included by default when using the `ModelSerializer` class, so we needed to add an explicit field for it.
 
 We'll also add a couple of views.  We'd like to just use read-only views for the user representations, so we'll use the `ListAPIView` and `RetrieveAPIView` generic class based views.
 
@@ -92,9 +92,7 @@ On **both** the `SnippetList` and `SnippetDetail` view classes, add the followin
 
 ## Updating our serializer
 
-Now that snippets are associated with the user that created them, let's update our SnippetSerializer to reflect that.
-
-Add the following field to the serializer definition:
+Now that snippets are associated with the user that created them, let's update our `SnippetSerializer` to reflect that. Add the following field to the serializer definition:
 
     owner = serializers.Field(source='owner.username')
 
@@ -108,7 +106,7 @@ The field we've added is the untyped `Field` class, in contrast to the other typ
 
 ## Adding required permissions to views
 
-Now that code snippets are associated with users we want to make sure that only authenticated users are able to create, update and delete code snippets.
+Now that code snippets are associated with users, we want to make sure that only authenticated users are able to create, update and delete code snippets.
 
 REST framework includes a number of permission classes that we can use to restrict who can access a given view.  In this case the one we're looking for is `IsAuthenticatedOrReadOnly`, which will ensure that authenticated requests get read-write access, and unauthenticated requests get read-only access.
 
diff --git a/docs/tutorial/5-relationships-and-hyperlinked-apis.md b/docs/tutorial/5-relationships-and-hyperlinked-apis.md
index 98c45b82..b5d37875 100644
--- a/docs/tutorial/5-relationships-and-hyperlinked-apis.md
+++ b/docs/tutorial/5-relationships-and-hyperlinked-apis.md
@@ -25,7 +25,7 @@ Notice that we're using REST framework's `reverse` function in order to return f
 
 The other obvious thing that's still missing from our pastebin API is the code highlighting endpoints.
 
-Unlike all our other API endpoints, we don't want to use JSON, but instead just present an HTML representation.  There are two style of HTML renderer provided by REST framework, one for dealing with HTML rendered using templates, the other for dealing with pre-rendered HTML.  The second renderer is the one we'd like to use for this endpoint.
+Unlike all our other API endpoints, we don't want to use JSON, but instead just present an HTML representation.  There are two styles of HTML renderer provided by REST framework, one for dealing with HTML rendered using templates, the other for dealing with pre-rendered HTML.  The second renderer is the one we'd like to use for this endpoint.
 
 The other thing we need to consider when creating the code highlight view is that there's no existing concrete generic view that we can use.  We're not returning an object instance, but instead a property of an object instance.
 
@@ -151,7 +151,7 @@ We could also customize the pagination style if we needed too, but in this case
 
 If we open a browser and navigate to the browseable API, you'll find that you can now work your way around the API simply by following links.
 
-You'll also be able to see the 'highlight' links on the snippet instances, that will take you to the hightlighted code HTML representations.
+You'll also be able to see the 'highlight' links on the snippet instances, that will take you to the highlighted code HTML representations.
 
 We've now got a complete pastebin Web API, which is fully web browseable, and comes complete with authentication, per-object permissions, and multiple renderer formats.
 
diff --git a/docs/tutorial/quickstart.md b/docs/tutorial/quickstart.md
index 9a36a2b0..74084541 100644
--- a/docs/tutorial/quickstart.md
+++ b/docs/tutorial/quickstart.md
@@ -137,7 +137,7 @@ We'd also like to set a few global settings.  We'd like to turn on pagination, a
         'PAGINATE_BY': 10
     }
 
-Okay, that's us done.
+Okay, we're done.
 
 ---