15 files changed, 94 insertions, 59 deletions
diff --git a/docs/api-guide/authentication.md b/docs/api-guide/authentication.md
index c2f73901..6888ac4e 100755
--- a/docs/api-guide/authentication.md
+++ b/docs/api-guide/authentication.md
@@ -86,7 +86,7 @@ Note that when a request may successfully authenticate, but still be denied perm
 
 Note that if deploying to [Apache using mod_wsgi][mod_wsgi_official], the authorization header is not passed through to a WSGI application by default, as it is assumed that authentication will be handled by Apache, rather than at an application level.
 
-If you are deploying to Apache, and using any non-session based authentication, you will need to explicitly configure mod_wsgi to pass the required headers through to the application. This can be done by specifying the `WSGIPassAuthorization` directive in the appropriate context and setting it to `'On'`.
+If you are deploying to Apache, and using any non-session based authentication, you will need to explicitly configure mod_wsgi to pass the required headers through to the application.  This can be done by specifying the `WSGIPassAuthorization` directive in the appropriate context and setting it to `'On'`.
 
     # this can go in either server config, virtual host, directory or .htaccess 
     WSGIPassAuthorization On
@@ -216,9 +216,9 @@ If you're using an AJAX style API with SessionAuthentication, you'll need to mak
 
 ## OAuthAuthentication
 
-This authentication uses [OAuth 1.0a][oauth-1.0a] authentication scheme. OAuth 1.0a provides signature validation which provides a reasonable level of security over plain non-HTTPS connections.  However, it may also be considered more complicated than OAuth2, as it requires clients to sign their requests.
+This authentication uses [OAuth 1.0a][oauth-1.0a] authentication scheme.  OAuth 1.0a provides signature validation which provides a reasonable level of security over plain non-HTTPS connections.  However, it may also be considered more complicated than OAuth2, as it requires clients to sign their requests.
 
-This authentication class depends on the optional `django-oauth-plus` and `oauth2` packages. In order to make it work you must install these packages and add `oauth_provider` to your `INSTALLED_APPS`:
+This authentication class depends on the optional `django-oauth-plus` and `oauth2` packages.  In order to make it work you must install these packages and add `oauth_provider` to your `INSTALLED_APPS`:
 
     INSTALLED_APPS = (
         ...
@@ -231,7 +231,7 @@ Don't forget to run `syncdb` once you've added the package.
 
 #### Getting started with django-oauth-plus
 
-The OAuthAuthentication class only provides token verification and signature validation for requests. It doesn't provide authorization flow for your clients. You still need to implement your own views for accessing and authorizing tokens.
+The OAuthAuthentication class only provides token verification and signature validation for requests.  It doesn't provide authorization flow for your clients.  You still need to implement your own views for accessing and authorizing tokens.
 
 The `django-oauth-plus` package provides simple foundation for classic 'three-legged' oauth flow.  Please refer to [the documentation][django-oauth-plus] for more details.
 
@@ -239,7 +239,7 @@ The `django-oauth-plus` package provides simple foundation for classic 'three-le
 
 This authentication uses [OAuth 2.0][rfc6749] authentication scheme.  OAuth2 is more simple to work with than OAuth1, and provides much better security than simple token authentication.  It is an unauthenticated scheme, and requires you to use an HTTPS connection.
 
-This authentication class depends on the optional [django-oauth2-provider][django-oauth2-provider] project. In order to make it work you must install this package and add `provider` and `provider.oauth2` to your `INSTALLED_APPS`:
+This authentication class depends on the optional [django-oauth2-provider][django-oauth2-provider] project.  In order to make it work you must install this package and add `provider` and `provider.oauth2` to your `INSTALLED_APPS`:
 
     INSTALLED_APPS = (
         ...
@@ -266,9 +266,9 @@ Finally, sync your database.
 
 #### Getting started with django-oauth2-provider
 
-The `OAuth2Authentication` class only provides token verification for requests. It doesn't provide authorization flow for your clients.
+The `OAuth2Authentication` class only provides token verification for requests.  It doesn't provide authorization flow for your clients.
 
-The OAuth 2 authorization flow is taken care by the [django-oauth2-provider][django-oauth2-provider] dependency. A walkthrough is given here, but for more details you should refer to [the documentation][django-oauth2-provider-docs]. 
+The OAuth 2 authorization flow is taken care by the [django-oauth2-provider][django-oauth2-provider] dependency.  A walkthrough is given here, but for more details you should refer to [the documentation][django-oauth2-provider-docs].
 
 To get started:
 
@@ -276,7 +276,7 @@ To get started:
 
 You can create a client, either through the shell, or by using the Django admin.
 
-Go to the admin panel and create a new `Provider.Client` entry. It will create the `client_id` and `client_secret` properties for you.
+Go to the admin panel and create a new `Provider.Client` entry.  It will create the `client_id` and `client_secret` properties for you.
 
 ##### 2. Request an access token
 
diff --git a/docs/api-guide/fields.md b/docs/api-guide/fields.md
index e117c370..c7db32ed 100644
--- a/docs/api-guide/fields.md
+++ b/docs/api-guide/fields.md
@@ -16,7 +16,7 @@ Serializer fields handle converting between primitive values and internal dataty
 
 ## Core arguments
 
-Each serializer field class constructor takes at least these arguments. Some Field classes take additional, field-specific arguments, but the following should always be accepted:
+Each serializer field class constructor takes at least these arguments.  Some Field classes take additional, field-specific arguments, but the following should always be accepted:
 
 ### `source`
 
@@ -41,7 +41,9 @@ Defaults to `True`.
 
 ### `default`
 
-If set, this gives the default value that will be used for the field if none is supplied.  If not set the default behavior is to not populate the attribute at all.
+If set, this gives the default value that will be used for the field if none is supplied.  If not set the default behavior is to not populate the attribute at all. 
+
+May be set to a function or other callable, in which case the value will be evaluated each time it is used.
 
 ### `validators`
 
@@ -56,6 +58,13 @@ A dictionary of error codes to error messages.
 Used only if rendering the field to HTML.
 This argument sets the widget that should be used to render the field.
 
+### `label`
+
+A short text string that may be used as the name of the field in HTML form fields or other descriptive elements.
+
+### `help_text`
+
+A text string that may be used as a description of the field in HTML form fields or other descriptive elements.
 
 ---
 
@@ -112,7 +121,7 @@ A generic field that can be tied to any arbitrary model field.  The `ModelField`
 
 ## SerializerMethodField
 
-This is a read-only field. It gets its value by calling a method on the serializer class it is attached to. It can be used to add any sort of data to the serialized representation of your object. The field's constructor accepts a single argument, which is the name of the method on the serializer to be called. The method should accept a single argument (in addition to `self`), which is the object being serialized. It should return whatever you want to be included in the serialized representation of the object. For example:
+This is a read-only field.  It gets its value by calling a method on the serializer class it is attached to.  It can be used to add any sort of data to the serialized representation of your object.  The field's constructor accepts a single argument, which is the name of the method on the serializer to be called.  The method should accept a single argument (in addition to `self`), which is the object being serialized.  It should return whatever you want to be included in the serialized representation of the object.  For example:
 
     from rest_framework import serializers
     from django.contrib.auth.models import User
@@ -151,7 +160,7 @@ or `django.db.models.fields.TextField`.
 
 ## URLField
 
-Corresponds to `django.db.models.fields.URLField`. Uses Django's `django.core.validators.URLValidator` for validation.
+Corresponds to `django.db.models.fields.URLField`.  Uses Django's `django.core.validators.URLValidator` for validation.
 
 **Signature:** `CharField(max_length=200, min_length=None)`
 
@@ -197,16 +206,16 @@ If you want to override this behavior, you'll need to declare the `DateTimeField
         class Meta:
             model = Comment
 
-Note that by default, datetime representations are deteremined by the renderer in use, although this can be explicitly overridden as detailed below.
+Note that by default, datetime representations are determined by the renderer in use, although this can be explicitly overridden as detailed below.
 
 In the case of JSON this means the default datetime representation uses the [ECMA 262 date time string specification][ecma262].  This is a subset of ISO 8601 which uses millisecond precision, and includes the 'Z' suffix for the UTC timezone, for example: `2013-01-29T12:34:56.123Z`.
 
 **Signature:** `DateTimeField(format=None, input_formats=None)`
 
 * `format` - A string representing the output format.  If not specified, this defaults to `None`, which indicates that python `datetime` objects should be returned by `to_native`.  In this case the datetime encoding will be determined by the renderer. 
-* `input_formats` - A list of strings representing the input formats which may be used to parse the date. If not specified, the `DATETIME_INPUT_FORMATS` setting will be used, which defaults to `['iso-8601']`.
+* `input_formats` - A list of strings representing the input formats which may be used to parse the date.  If not specified, the `DATETIME_INPUT_FORMATS` setting will be used, which defaults to `['iso-8601']`.
 
-DateTime format strings may either be [python strftime formats][strftime] which explicitly specifiy the format, or the special string `'iso-8601'`, which indicates that [ISO 8601][iso8601] style datetimes should be used. (eg `'2013-01-29T12:34:56.000000Z'`)
+DateTime format strings may either be [python strftime formats][strftime] which explicitly specify the format, or the special string `'iso-8601'`, which indicates that [ISO 8601][iso8601] style datetimes should be used. (eg `'2013-01-29T12:34:56.000000Z'`)
 
 ## DateField
 
@@ -217,9 +226,9 @@ Corresponds to `django.db.models.fields.DateField`
 **Signature:** `DateField(format=None, input_formats=None)`
 
 * `format` - A string representing the output format.  If not specified, this defaults to `None`, which indicates that python `date` objects should be returned by `to_native`.  In this case the date encoding will be determined by the renderer.
-* `input_formats` - A list of strings representing the input formats which may be used to parse the date. If not specified, the `DATE_INPUT_FORMATS` setting will be used, which defaults to `['iso-8601']`. 
+* `input_formats` - A list of strings representing the input formats which may be used to parse the date.  If not specified, the `DATE_INPUT_FORMATS` setting will be used, which defaults to `['iso-8601']`.
 
-Date format strings may either be [python strftime formats][strftime] which explicitly specifiy the format, or the special string `'iso-8601'`, which indicates that [ISO 8601][iso8601] style dates should be used. (eg `'2013-01-29'`)
+Date format strings may either be [python strftime formats][strftime] which explicitly specify the format, or the special string `'iso-8601'`, which indicates that [ISO 8601][iso8601] style dates should be used. (eg `'2013-01-29'`)
 
 ## TimeField
 
@@ -232,9 +241,9 @@ Corresponds to `django.db.models.fields.TimeField`
 **Signature:** `TimeField(format=None, input_formats=None)`
 
 * `format` - A string representing the output format.  If not specified, this defaults to `None`, which indicates that python `time` objects should be returned by `to_native`.  In this case the time encoding will be determined by the renderer.
-* `input_formats` - A list of strings representing the input formats which may be used to parse the date. If not specified, the `TIME_INPUT_FORMATS` setting will be used, which defaults to `['iso-8601']`.
+* `input_formats` - A list of strings representing the input formats which may be used to parse the date.  If not specified, the `TIME_INPUT_FORMATS` setting will be used, which defaults to `['iso-8601']`.
 
-Time format strings may either be [python strftime formats][strftime] which explicitly specifiy the format, or the special string `'iso-8601'`, which indicates that [ISO 8601][iso8601] style times should be used. (eg `'12:34:56.000000'`)
+Time format strings may either be [python strftime formats][strftime] which explicitly specify the format, or the special string `'iso-8601'`, which indicates that [ISO 8601][iso8601] style times should be used. (eg `'12:34:56.000000'`)
 
 ## IntegerField
 
@@ -256,7 +265,7 @@ Corresponds to `django.db.models.fields.DecimalField`.
 
 ## FileField
 
-A file representation. Performs Django's standard FileField validation. 
+A file representation.  Performs Django's standard FileField validation.
 
 Corresponds to `django.forms.fields.FileField`.
 
@@ -285,7 +294,7 @@ Django's regular [FILE_UPLOAD_HANDLERS] are used for handling uploaded files.
 
 # Custom fields
 
-If you want to create a custom field, you'll probably want to override either one or both of the `.to_native()` and `.from_native()` methods.  These two methods are used to convert between the intial datatype, and a primative, serializable datatype.  Primative datatypes may be any of a number, string, date/time/datetime or None.  They may also be any list or dictionary like object that only contains other primative objects.
+If you want to create a custom field, you'll probably want to override either one or both of the `.to_native()` and `.from_native()` methods.  These two methods are used to convert between the initial datatype, and a primative, serializable datatype.  Primative datatypes may be any of a number, string, date/time/datetime or None.  They may also be any list or dictionary like object that only contains other primative objects.
 
 The `.to_native()` method is called to convert the initial datatype into a primative, serializable datatype.  The `from_native()` method is called to restore a primative datatype into it's initial representation.
 
diff --git a/docs/api-guide/filtering.md b/docs/api-guide/filtering.md
index dd4cf8d7..05c997a3 100644
--- a/docs/api-guide/filtering.md
+++ b/docs/api-guide/filtering.md
@@ -2,7 +2,7 @@
 
 # Filtering
 
-> The root QuerySet provided by the Manager describes all objects in the database table. Usually, though, you'll need to select only a subset of the complete set of objects.
+> The root QuerySet provided by the Manager describes all objects in the database table.  Usually, though, you'll need to select only a subset of the complete set of objects.
 >
 > &mdash; [Django documentation][cite]
 
@@ -231,7 +231,7 @@ Multiple orderings may also be specified:
 
 If an `ordering` attribute is set on the view, this will be used as the default ordering.
 
-Typicaly you'd instead control this by setting `order_by` on the initial queryset, but using the `ordering` parameter on the view allows you to specify the ordering in a way that it can then be passed automatically as context to a rendered template.  This makes it possible to automatically render column headers differently if they are being used to order the results.
+Typically you'd instead control this by setting `order_by` on the initial queryset, but using the `ordering` parameter on the view allows you to specify the ordering in a way that it can then be passed automatically as context to a rendered template.  This makes it possible to automatically render column headers differently if they are being used to order the results.
 
     class UserListView(generics.ListAPIView):
         queryset = User.objects.all()
diff --git a/docs/api-guide/format-suffixes.md b/docs/api-guide/format-suffixes.md
index dae3dea3..529738e3 100644
--- a/docs/api-guide/format-suffixes.md
+++ b/docs/api-guide/format-suffixes.md
@@ -58,11 +58,11 @@ Also note that `format_suffix_patterns` does not support descending into `includ
         
 ## Accept headers vs. format suffixes
 
-There seems to be a view among some of the Web community that filename extensions are not a RESTful pattern, and that `HTTP Accept` headers should always be used instead.  
+There seems to be a view among some of the Web community that filename extensions are not a RESTful pattern, and that `HTTP Accept` headers should always be used instead.
 
 It is actually a misconception.  For example, take the following quote from Roy Fielding discussing the relative merits of query parameter media-type indicators vs. file extension media-type indicators: 
 
-&ldquo;That's why I always prefer extensions. Neither choice has anything to do with REST.&rdquo; &mdash; Roy Fielding, [REST discuss mailing list][cite2]
+&ldquo;That's why I always prefer extensions.  Neither choice has anything to do with REST.&rdquo; &mdash; Roy Fielding, [REST discuss mailing list][cite2]
 
 The quote does not mention Accept headers, but it does make it clear that format suffixes should be considered an acceptable pattern.
 
diff --git a/docs/api-guide/generic-views.md b/docs/api-guide/generic-views.md
index 1a060a32..20b9440b 100755
--- a/docs/api-guide/generic-views.md
+++ b/docs/api-guide/generic-views.md
@@ -71,7 +71,7 @@ The following attributes control the basic view behavior.
 The following attibutes are used to control pagination when used with list views.
 
 * `paginate_by` - The size of pages to use with paginated data.  If set to `None` then pagination is turned off.  If unset this uses the same value as the `PAGINATE_BY` setting, which defaults to `None`.
-* `paginate_by_param` - The name of a query parameter, which can be used by the client to overide the default page size to use for pagination.  If unset this uses the same value as the `PAGINATE_BY_PARAM` setting, which defaults to `None`.
+* `paginate_by_param` - The name of a query parameter, which can be used by the client to override the default page size to use for pagination.  If unset this uses the same value as the `PAGINATE_BY_PARAM` setting, which defaults to `None`.
 * `pagination_serializer_class` - The pagination serializer class to use when determining the style of paginated responses.  Defaults to the same value as the `DEFAULT_PAGINATION_SERIALIZER_CLASS` setting.
 * `page_kwarg` - The name of a URL kwarg or URL query parameter which can be used by the client to control which page is requested.  Defaults to `'page'`.
 
diff --git a/docs/api-guide/permissions.md b/docs/api-guide/permissions.md
index db0d4b26..2c0a055c 100644
--- a/docs/api-guide/permissions.md
+++ b/docs/api-guide/permissions.md
@@ -2,7 +2,7 @@
 
 # Permissions
 
-> Authentication or identification by itself is not usually sufficient to gain access to information or code. For that, the entity requesting access must have authorization.
+> Authentication or identification by itself is not usually sufficient to gain access to information or code.  For that, the entity requesting access must have authorization.
 >
 > &mdash; [Apple Developer Documentation][cite]
 
@@ -147,7 +147,7 @@ If you need to test if a request is a read operation or a write operation, you s
 
 **Note**: In versions 2.0 and 2.1, the signature for the permission checks always included an optional `obj` parameter, like so: `.has_permission(self, request, view, obj=None)`.  The method would be called twice, first for the global permission checks, with no object supplied, and second for the object-level check when required.
 
-As of version 2.2 this signature has now been replaced with two seperate method calls, which is more explict and obvious.  The old style signature continues to work, but it's use will result in a `PendingDeprecationWarning`, which is silent by default.  In 2.3 this will be escalated to a `DeprecationWarning`, and in 2.4 the old-style signature will be removed.
+As of version 2.2 this signature has now been replaced with two separate method calls, which is more explict and obvious.  The old style signature continues to work, but it's use will result in a `PendingDeprecationWarning`, which is silent by default.  In 2.3 this will be escalated to a `DeprecationWarning`, and in 2.4 the old-style signature will be removed.
 
 For more details see the [2.2 release announcement][2.2-announcement].
 
diff --git a/docs/api-guide/relations.md b/docs/api-guide/relations.md
index 99fe1083..50c9bc54 100644
--- a/docs/api-guide/relations.md
+++ b/docs/api-guide/relations.md
@@ -138,7 +138,7 @@ By default this field is read-write, although you can change this behavior using
 * `many` - If applied to a to-many relationship, you should set this argument to `True`.
 * `required` - If set to `False`, the field will accept values of `None` or the empty-string for nullable relationships.
 * `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`.
-* `lookup_field` - The field on the target that should be used for the lookup.  Should correspond to a URL keyword argument on the referenced view. Default is `'pk'`.
+* `lookup_field` - The field on the target that should be used for the lookup.  Should correspond to a URL keyword argument on the referenced view.  Default is `'pk'`.
 * `format` - If using format suffixes, hyperlinked fields will use the same format suffix for the target unless overridden by using the `format` argument.
 
 ## SlugRelatedField
@@ -202,7 +202,7 @@ This field is always read-only.
 **Arguments**:
 
 * `view_name` - The view name that should be used as the target of the relationship.  **required**.
-* `lookup_field` - The field on the target that should be used for the lookup.  Should correspond to a URL keyword argument on the referenced view. Default is `'pk'`.
+* `lookup_field` - The field on the target that should be used for the lookup.  Should correspond to a URL keyword argument on the referenced view.  Default is `'pk'`.
 * `format` - If using format suffixes, hyperlinked fields will use the same format suffix for the target unless overridden by using the `format` argument.
 
 ---
@@ -237,7 +237,7 @@ Would serialize to a nested representation like this:
         'album_name': 'The Grey Album',
         'artist': 'Danger Mouse'
         'tracks': [
-            {'order': 1, 'title': 'Public Service Annoucement'},
+            {'order': 1, 'title': 'Public Service Announcement'},
             {'order': 2, 'title': 'What More Can I Say'},
             {'order': 3, 'title': 'Encore'},
             ...
diff --git a/docs/api-guide/renderers.md b/docs/api-guide/renderers.md
index a5eba9fc..b627c930 100644
--- a/docs/api-guide/renderers.md
+++ b/docs/api-guide/renderers.md
@@ -14,7 +14,7 @@ The set of valid renderers for a view is always defined as a list of classes.  W
 
 The basic process of content negotiation involves examining the request's `Accept` header, to determine which media types it expects in the response.  Optionally, format suffixes on the URL may be used to explicitly request a particular representation.  For example the URL `http://example.com/api/users_count.json` might be an endpoint that always returns JSON data.
 
-For more information see the documentation on [content negotation][conneg].
+For more information see the documentation on [content negotiation][conneg].
 
 ## Setting the renderers
 
@@ -67,22 +67,40 @@ If your API includes views that can serve both regular webpages and API response
 
 ## JSONRenderer
 
-Renders the request data into `JSON`, using ASCII encoding.
+Renders the request data into `JSON`, using utf-8 encoding.
+
+Note that non-ascii characters will be rendered using JSON's `\uXXXX` character escape.  For example:
+
+    {"unicode black star": "\u2605"}
 
 The client may additionally include an `'indent'` media type parameter, in which case the returned `JSON` will be indented.  For example `Accept: application/json; indent=4`.
 
+    {
+        "unicode black star": "\u2605"
+    }
+
 **.media_type**: `application/json`
 
 **.format**: `'.json'`
 
-**.charset**: `iso-8859-1`
+**.charset**: `utf-8`
 
 ## UnicodeJSONRenderer
 
 Renders the request data into `JSON`, using utf-8 encoding.
 
+Note that non-ascii characters will not be character escaped.  For example:
+
+    {"unicode black star": "★"}
+
 The client may additionally include an `'indent'` media type parameter, in which case the returned `JSON` will be indented.  For example `Accept: application/json; indent=4`.
 
+    {
+        "unicode black star": "★"
+    }
+
+Both the `JSONRenderer` and `UnicodeJSONRenderer` styles conform to [RFC 4627][rfc4627], and are syntactically valid JSON.
+
 **.media_type**: `application/json`
 
 **.format**: `'.json'`
@@ -101,7 +119,7 @@ The javascript callback function must be set by the client including a `callback
 
 **.format**: `'.jsonp'`
 
-**.charset**: `iso-8859-1`
+**.charset**: `utf-8`
 
 ## YAMLRenderer
 
@@ -215,13 +233,13 @@ The request data, as set by the `Response()` instantiation.
 
 ### `media_type=None`
 
-Optional. If provided, this is the accepted media type, as determined by the content negotiation stage.
+Optional.  If provided, this is the accepted media type, as determined by the content negotiation stage.
 
 Depending on the client's `Accept:` header, this may be more specific than the renderer's `media_type` attribute, and may include media type parameters.  For example `"application/json; nested=true"`.
 
 ### `renderer_context=None`
 
-Optional. If provided, this is a dictionary of contextual information provided by the view.
+Optional.  If provided, this is a dictionary of contextual information provided by the view.
 
 By default this will include the following keys: `view`, `request`, `response`, `args`, `kwargs`.
 
@@ -252,7 +270,9 @@ By default renderer classes are assumed to be using the `UTF-8` encoding.  To us
         def render(self, data, media_type=None, renderer_context=None):
             return data.encode(self.charset)
 
-If the renderer returns a raw bytestring, you should set a charset value of `None`, which will ensure the `Content-Type` header of the response will not have a `charset` value set.  Doing so will also ensure that the browsable API will not attempt to display the binary content as a string.
+Note that if a renderer class returns a unicode string, then the response content will be coerced into a bytestring by the `Response` class, with the `charset` attribute set on the renderer used to determine the encoding.
+
+If the renderer returns a bytestring representing raw binary content, you should set a charset value of `None`, which will ensure the `Content-Type` header of the response will not have a `charset` value set.  Doing so will also ensure that the browsable API will not attempt to display the binary content as a string.
 
     class JPEGRenderer(renderers.BaseRenderer):
         media_type = 'image/jpeg'
@@ -305,7 +325,7 @@ For example:
 In some cases you might want a renderer to serve a range of media types.
 In this case you can underspecify the media types it should respond to, by using a `media_type` value such as `image/*`, or `*/*`.
 
-If you underspecify the renderer's media type, you should make sure to specify the media type explictly when you return the response, using the `content_type` attribute.  For example:
+If you underspecify the renderer's media type, you should make sure to specify the media type explicitly when you return the response, using the `content_type` attribute.  For example:
 
     return Response(data, content_type='image/png')
 
@@ -350,6 +370,7 @@ Comma-separated values are a plain-text tabular data format, that can be easily
 [cite]: https://docs.djangoproject.com/en/dev/ref/template-response/#the-rendering-process
 [conneg]: content-negotiation.md
 [browser-accept-headers]: http://www.gethifi.com/blog/browser-rest-http-accept-headers
+[rfc4627]: http://www.ietf.org/rfc/rfc4627.txt
 [cors]: http://www.w3.org/TR/cors/
 [cors-docs]: ../topics/ajax-csrf-cors.md
 [HATEOAS]: http://timelessrepo.com/haters-gonna-hateoas
diff --git a/docs/api-guide/responses.md b/docs/api-guide/responses.md
index 59632ad5..374276dc 100644
--- a/docs/api-guide/responses.md
+++ b/docs/api-guide/responses.md
@@ -2,7 +2,7 @@
 
 # Responses
 
-> Unlike basic HttpResponse objects, TemplateResponse objects retain the details of the context that was provided by the view to compute the response. The final output of the response is not computed until it is needed, later in the response process.
+> Unlike basic HttpResponse objects, TemplateResponse objects retain the details of the context that was provided by the view to compute the response.  The final output of the response is not computed until it is needed, later in the response process.
 >
 > &mdash; [Django documentation][cite]
 
diff --git a/docs/api-guide/routers.md b/docs/api-guide/routers.md
index 6588d7e5..3c3a6ae3 100644
--- a/docs/api-guide/routers.md
+++ b/docs/api-guide/routers.md
@@ -2,7 +2,7 @@
 
 # Routers
 
-> Resource routing allows you to quickly declare all of the common routes for a given resourceful controller. Instead of declaring separate routes for your index... a resourceful route declares them in a single line of code.
+> Resource routing allows you to quickly declare all of the common routes for a given resourceful controller.  Instead of declaring separate routes for your index... a resourceful route declares them in a single line of code.
 >
 > &mdash; [Ruby on Rails Documentation][cite]
 
@@ -85,7 +85,7 @@ This router is similar to `SimpleRouter` as above, but additionally includes a d
 
 # Custom Routers
 
-Implementing a custom router isn't something you'd need to do very often, but it can be useful if you have specfic requirements about how the your URLs for your API are strutured.  Doing so allows you to encapsulate the URL structure in a reusable way that ensures you don't have to write your URL patterns explicitly for each new view.
+Implementing a custom router isn't something you'd need to do very often, but it can be useful if you have specific requirements about how the your URLs for your API are strutured.  Doing so allows you to encapsulate the URL structure in a reusable way that ensures you don't have to write your URL patterns explicitly for each new view.
 
 The simplest way to implement a custom router is to subclass one of the existing router classes.  The `.routes` attribute is used to template the URL patterns that will be mapped to each viewset. 
 
diff --git a/docs/api-guide/serializers.md b/docs/api-guide/serializers.md
index c83a0967..71f0abb7 100644
--- a/docs/api-guide/serializers.md
+++ b/docs/api-guide/serializers.md
@@ -3,7 +3,7 @@
 # Serializers
 
 > Expanding the usefulness of the serializers is something that we would
-like to address. However, it's not a trivial problem, and it
+like to address.  However, it's not a trivial problem, and it
 will take some serious design work.
 >
 > &mdash; Russell Keith-Magee, [Django users group][cite]
@@ -104,11 +104,11 @@ When deserializing a list of items, errors will be returned as a list of diction
 
 #### Field-level validation
 
-You can specify custom field-level validation by adding `.validate_<fieldname>` methods to your `Serializer` subclass. These are analagous to `.clean_<fieldname>` methods on Django forms, but accept slightly different arguments.
+You can specify custom field-level validation by adding `.validate_<fieldname>` methods to your `Serializer` subclass.  These are analogous to `.clean_<fieldname>` methods on Django forms, but accept slightly different arguments.
 
 They take a dictionary of deserialized attributes as a first argument, and the field name in that dictionary as a second argument (which will be either the name of the field or the value of the `source` argument to the field, if one was provided).
 
-Your `validate_<fieldname>` methods should either just return the `attrs` dictionary or raise a `ValidationError`. For example:
+Your `validate_<fieldname>` methods should either just return the `attrs` dictionary or raise a `ValidationError`.  For example:
 
     from rest_framework import serializers
 
@@ -127,7 +127,7 @@ Your `validate_<fieldname>` methods should either just return the `attrs` dictio
 
 #### Object-level validation
 
-To do any other validation that requires access to multiple fields, add a method called `.validate()` to your `Serializer` subclass. This method takes a single argument, which is the `attrs` dictionary. It should raise a `ValidationError` if necessary, or just return `attrs`.  For example:
+To do any other validation that requires access to multiple fields, add a method called `.validate()` to your `Serializer` subclass.  This method takes a single argument, which is the `attrs` dictionary.  It should raise a `ValidationError` if necessary, or just return `attrs`.  For example:
 
     from rest_framework import serializers
 
@@ -285,7 +285,7 @@ To map the incoming data items to their corresponding object instances, the `.ge
 
 There are some cases where you need to provide extra context to the serializer in addition to the object being serialized.  One common case is if you're using a serializer that includes hyperlinked relations, which requires the serializer to have access to the current request so that it can properly generate fully qualified URLs.
 
-You can provide arbitrary additional context by passing a `context` argument when instantiating the serializer. For example:
+You can provide arbitrary additional context by passing a `context` argument when instantiating the serializer.  For example:
 
     serializer = AccountSerializer(account, context={'request': request})
     serializer.data
@@ -333,7 +333,7 @@ The `depth` option should be set to an integer value that indicates the depth of
 
 ## Specifying which fields should be read-only 
 
-You may wish to specify multiple fields as read-only. Instead of adding each field explicitly with the `read_only=True` attribute, you may use the `read_only_fields` Meta option, like so:
+You may wish to specify multiple fields as read-only.  Instead of adding each field explicitly with the `read_only=True` attribute, you may use the `read_only_fields` Meta option, like so:
 
     class AccountSerializer(serializers.ModelSerializer):
         class Meta:
@@ -425,7 +425,7 @@ Doing so should be considered advanced usage, and will only be needed if you hav
 
 The `field_mapping` attribute is a dictionary that maps model classes to serializer classes.  Overriding the attribute will let you set a different set of default serializer classes. 
 
-For more advanced customization than simply changing the default serializer class you can override various `get_<field_type>_field` methods.  Doing so will allow you to customize the arguments that each serializer field is initialized with. Each of these methods may either return a field or serializer instance, or `None`.
+For more advanced customization than simply changing the default serializer class you can override various `get_<field_type>_field` methods.  Doing so will allow you to customize the arguments that each serializer field is initialized with.  Each of these methods may either return a field or serializer instance, or `None`.
 
 ### get_pk_field
 
diff --git a/docs/api-guide/settings.md b/docs/api-guide/settings.md
index b00ab4c1..8d8c00cf 100644
--- a/docs/api-guide/settings.md
+++ b/docs/api-guide/settings.md
@@ -125,7 +125,7 @@ Default: `None`
 
 #### PAGINATE_BY_PARAM
 
-The name of a query parameter, which can be used by the client to overide the default page size to use for pagination.  If set to `None`, clients may not override the default page size.
+The name of a query parameter, which can be used by the client to override the default page size to use for pagination.  If set to `None`, clients may not override the default page size.
 
 Default: `None`
 
diff --git a/docs/api-guide/status-codes.md b/docs/api-guide/status-codes.md
index b50c96ae..db2e059c 100644
--- a/docs/api-guide/status-codes.md
+++ b/docs/api-guide/status-codes.md
@@ -2,7 +2,7 @@
 
 # Status Codes
 
-> 418 I'm a teapot - Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout.
+> 418 I'm a teapot - Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot".  The resulting entity body MAY be short and stout.
 >
 > &mdash; [RFC 2324][rfc2324], Hyper Text Coffee Pot Control Protocol
 
@@ -53,7 +53,7 @@ This class of status code indicates that further action needs to be taken by the
 
 ## Client Error - 4xx
 
-The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
+The 4xx class of status code is intended for cases in which the client seems to have erred.  Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
 
     HTTP_400_BAD_REQUEST
     HTTP_401_UNAUTHORIZED
@@ -79,7 +79,7 @@ The 4xx class of status code is intended for cases in which the client seems to
 
 ## Server Error - 5xx
 
-Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
+Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request.  Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
 
     HTTP_500_INTERNAL_SERVER_ERROR
     HTTP_501_NOT_IMPLEMENTED
diff --git a/docs/api-guide/views.md b/docs/api-guide/views.md
index 8b26b3e3..37ebd55f 100644
--- a/docs/api-guide/views.md
+++ b/docs/api-guide/views.md
@@ -122,13 +122,13 @@ You won't typically need to override this method.
 >
 > &mdash; [Nick Coghlan][cite2]
 
-REST framework also allows you to work with regular function based views. It provides a set of simple decorators that wrap your function based views to ensure they receive an instance of `Request` (rather than the usual Django `HttpRequest`) and allows them to return a `Response` (instead of a Django `HttpResponse`), and allow you to configure how the request is processed.
+REST framework also allows you to work with regular function based views.  It provides a set of simple decorators that wrap your function based views to ensure they receive an instance of `Request` (rather than the usual Django `HttpRequest`) and allows them to return a `Response` (instead of a Django `HttpResponse`), and allow you to configure how the request is processed.
 
 ## @api_view()
 
 **Signature:** `@api_view(http_method_names)`
 
-The core of this functionality is the `api_view` decorator, which takes a list of HTTP methods that your view should respond to. For example, this is how you would write a very simple view that just manually returns some data:
+The core of this functionality is the `api_view` decorator, which takes a list of HTTP methods that your view should respond to.  For example, this is how you would write a very simple view that just manually returns some data:
 
     from rest_framework.decorators import api_view
 
@@ -141,7 +141,7 @@ This view will use the default renderers, parsers, authentication classes etc sp
 
 ## API policy decorators
 
-To override the default settings, REST framework provides a set of additional decorators which can be added to your views. These must come *after* (below) the `@api_view` decorator. For example, to create a view that uses a [throttle](throttling) to ensure it can only be called once per day by a particular user, use the `@throttle_classes` decorator, passing a list of throttle classes:
+To override the default settings, REST framework provides a set of additional decorators which can be added to your views.  These must come *after* (below) the `@api_view` decorator.  For example, to create a view that uses a [throttle](throttling) to ensure it can only be called once per day by a particular user, use the `@throttle_classes` decorator, passing a list of throttle classes:
 
     from rest_framework.decorators import api_view, throttle_classes
     from rest_framework.throttling import UserRateThrottle
diff --git a/docs/api-guide/viewsets.md b/docs/api-guide/viewsets.md
index cd92dc58..2783da98 100644
--- a/docs/api-guide/viewsets.md
+++ b/docs/api-guide/viewsets.md
@@ -34,7 +34,7 @@ Let's define a simple viewset that can be used to list or retrieve all the users
             serializer = UserSerializer(user)
             return Response(serializer.data)
 
-If we need to, we can bind this viewset into two seperate views, like so:
+If we need to, we can bind this viewset into two separate views, like so:
 
     user_list = UserViewSet.as_view({'get': 'list'})
     user_detail = UserViewSet.as_view({'get': 'retrieve'})
@@ -65,7 +65,7 @@ Both of these come with a trade-off.  Using regular views and URL confs is more
 
 The default routers included with REST framework will provide routes for a standard set of create/retrieve/update/destroy style operations, as shown below:
 
-    class UserViewSet(viewsets.VietSet):
+    class UserViewSet(viewsets.ViewSet):
         """
         Example empty viewset demonstrating the standard
         actions that will be handled by a router class.
@@ -92,7 +92,7 @@ The default routers included with REST framework will provide routes for a stand
         def destroy(self, request, pk=None):
             pass
 
-If you have ad-hoc methods that you need to be routed to, you can mark them as requiring routing using the `@link` or `@action` decorators.  The `@link` decorator will route `GET` requests, and the `@action` decroator will route `POST` requests.
+If you have ad-hoc methods that you need to be routed to, you can mark them as requiring routing using the `@link` or `@action` decorators.  The `@link` decorator will route `GET` requests, and the `@action` decorator will route `POST` requests.
 
 For example:
 
@@ -126,6 +126,11 @@ The `@action` and `@link` decorators can additionally take extra arguments that
         def set_password(self, request, pk=None):
            ...
 
+The `@action` decorator will route `POST` requests by default, but may also accept other HTTP methods, by using the `method` argument.  For example:
+
+        @action(methods=['POST', 'DELETE'])
+        def unset_password(self, request, pk=None):
+           ...
 ---
 
 # API Reference