16 files changed, 160 insertions, 55 deletions
diff --git a/docs/api-guide/authentication.md b/docs/api-guide/authentication.md
index 71f48163..7bad4867 100644
--- a/docs/api-guide/authentication.md
+++ b/docs/api-guide/authentication.md
@@ -26,10 +26,10 @@ The value of `request.user` and `request.auth` for unauthenticated requests can
 
 ## Setting the authentication policy
 
-The default authentication policy may be set globally, using the `DEFAULT_AUTHENTICATION` setting.  For example.
+The default authentication policy may be set globally, using the `DEFAULT_AUTHENTICATION_CLASSES` setting.  For example.
 
     REST_FRAMEWORK = {
-        'DEFAULT_AUTHENTICATION': (
+        'DEFAULT_AUTHENTICATION_CLASSES': (
             'rest_framework.authentication.UserBasicAuthentication',
             'rest_framework.authentication.SessionAuthentication',
         )
@@ -86,7 +86,7 @@ You'll also need to create tokens for your users.
     token = Token.objects.create(user=...)
     print token.key
 
-For clients to authenticate, the token key should be included in the `Authorization` HTTP header.  The key should be prefixed by the string literal "Token", with whitespace seperating the two strings.  For example:
+For clients to authenticate, the token key should be included in the `Authorization` HTTP header.  The key should be prefixed by the string literal "Token", with whitespace separating the two strings.  For example:
 
     Authorization: Token 9944b09199c62bcf9418ad846dd0e4bbdfc6ee4b
 
diff --git a/docs/api-guide/content-negotiation.md b/docs/api-guide/content-negotiation.md
index b95091c5..10288c94 100644
--- a/docs/api-guide/content-negotiation.md
+++ b/docs/api-guide/content-negotiation.md
@@ -8,8 +8,59 @@
 
 [cite]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html
 
-**TODO**: Describe content negotiation style used by REST framework.
+Content negotiation is the process of selecting one of multiple possible representations to return to a client, based on client or server preferences.
 
-## Custom content negotiation
+## Determining the accepted renderer
 
-It's unlikley that you'll want to provide a custom content negotiation scheme for REST framework, but you can do so if needed.  To implement a custom content negotiation scheme, override `BaseContentNegotiation`, and implement the `.select_parser(request, parsers)` and `.select_renderer(request, renderers, format_suffix)`
-\ No newline at end of file
+REST framework uses a simple style of content negotiation to determine which media type should be returned to a client, based on the available renderers, the priorities of each of those renderers, and the client's `Accept:` header.  The style used is partly client-driven, and partly server-driven.
+
+1. More specific media types are given preference to less specific media types.
+2. If multiple media types have the same specificity, then preference is given to based on the ordering of the renderers configured for the given view.
+
+For example, given the following `Accept` header:
+
+    application/json; indent=4, application/json, application/yaml, text/html, */*
+
+The priorities for each of the given media types would be:
+
+* `application/json; indent=4`
+* `application/json`, `application/yaml` and `text/html`
+* `*/*`
+
+If the requested view was only configured with renderers for `YAML` and `HTML`, then REST framework would select whichever renderer was listed first in the `renderer_classes` list or `DEFAULT_RENDERER_CLASSES` setting.
+
+For more information on the `HTTP Accept` header, see [RFC 2616][accept-header] 
+
+---
+
+**Note**: "q" values are not taken into account by REST framework when determining preference.  The use of "q" values negatively impacts caching, and in the author's opinion they are an unnecessary and overcomplicated approach to content negotiation.
+
+This is a valid approach as the HTTP spec deliberately underspecifies how a server should weight server-based preferences against client-based preferences.
+
+---
+
+# Custom content negotiation
+
+It's unlikely that you'll want to provide a custom content negotiation scheme for REST framework, but you can do so if needed.  To implement a custom content negotiation scheme override `BaseContentNegotiation`.
+
+REST framework's content negotiation classes handle selection of both the appropriate parser for the request, and the appropriate renderer for the response,  so you should implement both the `.select_parser(request, parsers)` and `.select_renderer(request, renderers, format_suffix)` methods.
+
+## Example
+
+The following is a custom content negotiation class which ignores the client
+request when selecting the appropriate parser or renderer.
+
+    class IgnoreClientContentNegotiation(BaseContentNegotiation):
+        def select_parser(self, request, parsers):
+            """
+            Select the first parser in the `.parser_classes` list.
+            """
+            return parsers[0]
+        
+        def select_renderer(self, request, renderers, format_suffix):
+            """
+            Select the first renderer in the `.renderer_classes` list.
+            """
+            return renderers[0]
+
+[accept-header]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
diff --git a/docs/api-guide/exceptions.md b/docs/api-guide/exceptions.md
index 33cf1ca8..ba57fde8 100644
--- a/docs/api-guide/exceptions.md
+++ b/docs/api-guide/exceptions.md
@@ -25,7 +25,7 @@ For example, the following request:
     DELETE http://api.example.com/foo/bar HTTP/1.1
     Accept: application/json
 
-Might recieve an error response indicating that the `DELETE` method is not allowed on that resource:
+Might receive an error response indicating that the `DELETE` method is not allowed on that resource:
 
     HTTP/1.1 405 Method Not Allowed
     Content-Type: application/json; charset=utf-8
@@ -85,4 +85,4 @@ Raised when an incoming request fails the throttling checks.
 
 By default this exception results in a response with the HTTP status code "429 Too Many Requests".
 
-[cite]: http://www.doughellmann.com/articles/how-tos/python-exception-handling/index.html
-\ No newline at end of file
+[cite]: http://www.doughellmann.com/articles/how-tos/python-exception-handling/index.html
diff --git a/docs/api-guide/fields.md b/docs/api-guide/fields.md
index 234c65ad..189ed76f 100644
--- a/docs/api-guide/fields.md
+++ b/docs/api-guide/fields.md
@@ -42,7 +42,7 @@ A serializer definition that looked like this:
         class Meta:
             fields = ('url', 'owner', 'name', 'expired')
 
-Would produced output similar to:
+Would produce output similar to:
 
     {
         'url': 'http://example.com/api/accounts/3/',
@@ -51,7 +51,7 @@ Would produced output similar to:
         'expired': True
     }
 
-Be default, the `Field` class will perform a basic translation of the source value into primative datatypes, falling back to unicode representations of complex datatypes when neccesary.
+By default, the `Field` class will perform a basic translation of the source value into primative datatypes, falling back to unicode representations of complex datatypes when necessary.
 
 You can customize this  behaviour by overriding the `.to_native(self, value)` method.
 
@@ -92,7 +92,7 @@ A field that can accept on of a limited set of choices.
 
 ## EmailField
 
-A text representation, validates the text to be a valid e-mail adress.
+A text representation, validates the text to be a valid e-mail address.
 
 Corresponds to `django.db.models.fields.EmailField`
 
@@ -183,7 +183,7 @@ And a model serializer defined like this:
             model = Bookmark
             exclude = ('id',)
 
-The an example output format for a Bookmark instance would be:
+Then an example output format for a Bookmark instance would be:
 
     {
         'tags': [u'django', u'python'],
diff --git a/docs/api-guide/format-suffixes.md b/docs/api-guide/format-suffixes.md
index 7d72d9f8..6d5feba4 100644
--- a/docs/api-guide/format-suffixes.md
+++ b/docs/api-guide/format-suffixes.md
@@ -7,5 +7,55 @@ used all the time.
 >
 > &mdash; Roy Fielding, [REST discuss mailing list][cite]
 
-[cite]: http://tech.groups.yahoo.com/group/rest-discuss/message/5857
+A common pattern for Web APIs is to use filename extensions on URLs to provide an endpoint for a given media type.  For example, 'http://example.com/api/users.json' to serve a JSON representation. 
+
+Adding format-suffix patterns to each individual entry in the URLconf for your API is error-prone and non-DRY, so REST framework provides a shortcut to adding these patterns to your URLConf.
+
+## format_suffix_patterns
+
+**Signature**: format_suffix_patterns(urlpatterns, suffix_required=False, allowed=None)
+
+Returns a URL pattern list which includes format suffix patterns appended to each of the URL patterns provided.
+
+Arguments:
+
+* **urlpatterns**: Required.  A URL pattern list.
+* **suffix_required**:  Optional.  A boolean indicating if suffixes in the URLs should be optional or mandatory.  Defaults to `False`, meaning that suffixes are optional by default.
+* **allowed**:  Optional.  A list or tuple of valid format suffixes.  If not provided, a wildcard format suffix pattern will be used. 
+
+Example:
+
+    from rest_framework.urlpatterns import format_suffix_patterns
+    
+    urlpatterns = patterns('blog.views',
+        url(r'^/$', 'api_root'),
+        url(r'^comment/$', 'comment_root'),
+        url(r'^comment/(?P<pk>[0-9]+)/$', 'comment_instance')
+    )
+    
+    urlpatterns = format_suffix_patterns(urlpatterns, allowed=['json', 'html'])
+
+When using `format_suffix_patterns`, you must make sure to add the `'format'` keyword argument to the corresponding views.  For example.
 
+    @api_view(('GET',))
+    def api_root(request, format=None):
+        # do stuff...
+
+The name of the kwarg used may be modified by using the `FORMAT_SUFFIX_KWARG` setting.
+
+Also note that `format_suffix_patterns` does not support descending into `include` URL patterns.
+
+---
+        
+## 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.  
+
+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]
+
+The quote does not mention Accept headers, but it does make it clear that format suffixes should be considered an acceptable pattern.
+
+[cite]: http://tech.groups.yahoo.com/group/rest-discuss/message/5857
+[cite2]: http://tech.groups.yahoo.com/group/rest-discuss/message/14844
+\ No newline at end of file
diff --git a/docs/api-guide/pagination.md b/docs/api-guide/pagination.md
index e416de02..597baba4 100644
--- a/docs/api-guide/pagination.md
+++ b/docs/api-guide/pagination.md
@@ -100,12 +100,16 @@ You can also set the pagination style on a per-view basis, using the `ListAPIVie
 
 For more complex requirements such as serialization that differs depending on the requested media type you can override the `.get_paginate_by()` and `.get_pagination_serializer_class()` methods.
 
-## Custom pagination serializers
+---
+
+# Custom pagination serializers
 
 To create a custom pagination serializer class you should override `pagination.BasePaginationSerializer` and set the fields that you want the serializer to return.
 
 You can also override the name used for the object list field, by setting the `results_field` attribute, which defaults to `'results'`.
 
+## Example
+
 For example, to nest a pair of links labelled 'prev' and 'next', and set the name for the results field to 'objects', you might use something like this.
 
     class LinksSerializer(serializers.Serializer):
diff --git a/docs/api-guide/parsers.md b/docs/api-guide/parsers.md
index 0985b2ca..ac904720 100644
--- a/docs/api-guide/parsers.md
+++ b/docs/api-guide/parsers.md
@@ -8,7 +8,7 @@ sending more complex data than simple forms
 >
 > &mdash; Malcom Tredinnick, [Django developers group][cite]
 
-REST framework includes a number of built in Parser classes, that allow you to accept requests with various media types.  There is also support for defining your own custom parsers, which gives you the flexiblity to design the media types that your API accepts.
+REST framework includes a number of built in Parser classes, that allow you to accept requests with various media types.  There is also support for defining your own custom parsers, which gives you the flexibility to design the media types that your API accepts.
 
 ## How the parser is determined
 
@@ -16,10 +16,10 @@ The set of valid parsers for a view is always defined as a list of classes.  Whe
 
 ## Setting the parsers
 
-The default set of parsers may be set globally, using the `DEFAULT_PARSERS` setting.  For example, the following settings would allow requests with `YAML` content.
+The default set of parsers may be set globally, using the `DEFAULT_PARSER_CLASSES` setting.  For example, the following settings would allow requests with `YAML` content.
 
     REST_FRAMEWORK = {
-        'DEFAULT_PARSERS': (
+        'DEFAULT_PARSER_CLASSES': (
             'rest_framework.parsers.YAMLParser',
         )
     }
@@ -65,7 +65,7 @@ Parses `YAML` request content.
 
 Parses REST framework's default style of `XML` request content.
 
-Note that the `XML` markup language is used typically used as the base language for more strictly defined domain-specific languages, such as `RSS`, `Atom`, and `XHTML`.
+Note that the `XML` markup language is typically used as the base language for more strictly defined domain-specific languages, such as `RSS`, `Atom`, and `XHTML`.
 
 If you are considering using `XML` for your API, you may want to consider implementing a custom renderer and parser for your specific requirements, and using an existing domain-specific media-type, or creating your own custom XML-based media-type.
 
diff --git a/docs/api-guide/permissions.md b/docs/api-guide/permissions.md
index b25b52be..0b7b32e9 100644
--- a/docs/api-guide/permissions.md
+++ b/docs/api-guide/permissions.md
@@ -6,7 +6,7 @@
 >
 > &mdash; [Apple Developer Documentation][cite]
 
-Together with [authentication] and [throttling], permissions determine wheter a request should be granted or denied access.
+Together with [authentication] and [throttling], permissions determine whether a request should be granted or denied access.
 
 Permission checks are always run at the very start of the view, before any other code is allowed to proceed.  Permission checks will typically use the authentication information in the `request.user` and `request.auth` properties to determine if the incoming request should be permitted.
 
@@ -25,10 +25,10 @@ Object level permissions are run by REST framework's generic views when `.get_ob
 
 ## Setting the permission policy
 
-The default permission policy may be set globally, using the `DEFAULT_PERMISSIONS` setting.  For example.
+The default permission policy may be set globally, using the `DEFAULT_PERMISSION_CLASSES` setting.  For example.
 
     REST_FRAMEWORK = {
-        'DEFAULT_PERMISSIONS': (
+        'DEFAULT_PERMISSION_CLASSES': (
             'rest_framework.permissions.IsAuthenticated',
         )
     }
diff --git a/docs/api-guide/renderers.md b/docs/api-guide/renderers.md
index 24cca181..b6db376c 100644
--- a/docs/api-guide/renderers.md
+++ b/docs/api-guide/renderers.md
@@ -6,7 +6,7 @@
 >
 > &mdash; [Django documentation][cite]
 
-REST framework includes a number of built in Renderer classes, that allow you to return responses with various media types.  There is also support for defining your own custom renderers, which gives you the flexiblity to design your own media types.
+REST framework includes a number of built in Renderer classes, that allow you to return responses with various media types.  There is also support for defining your own custom renderers, which gives you the flexibility to design your own media types.
 
 ## How the renderer is determined
 
@@ -18,10 +18,10 @@ For more information see the documentation on [content negotation][conneg].
 
 ## Setting the renderers
 
-The default set of renderers may be set globally, using the `DEFAULT_RENDERERS` setting.  For example, the following settings would use `YAML` as the main media type and also include the self describing API.
+The default set of renderers may be set globally, using the `DEFAULT_RENDERER_CLASSES` setting.  For example, the following settings would use `YAML` as the main media type and also include the self describing API.
 
     REST_FRAMEWORK = {
-        'DEFAULT_RENDERERS': (
+        'DEFAULT_RENDERER_CLASSES': (
             'rest_framework.renderers.YAMLRenderer',
             'rest_framework.renderers.BrowsableAPIRenderer',
         )
@@ -229,7 +229,7 @@ For example:
 
 ## Designing your media types
 
-For the purposes of many Web APIs, simple `JSON` responses with hyperlinked relations may be sufficient.  If you want to fully embrace RESTful design and [HATEOAS] you'll neeed to consider the design and usage of your media types in more detail.
+For the purposes of many Web APIs, simple `JSON` responses with hyperlinked relations may be sufficient.  If you want to fully embrace RESTful design and [HATEOAS] you'll need to consider the design and usage of your media types in more detail.
 
 In [the words of Roy Fielding][quote], "A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types.".
 
diff --git a/docs/api-guide/requests.md b/docs/api-guide/requests.md
index 439c97bc..72932f5d 100644
--- a/docs/api-guide/requests.md
+++ b/docs/api-guide/requests.md
@@ -25,19 +25,19 @@ For more details see the [parsers documentation].
 
 ## .FILES
 
-`request.FILES` returns any uploaded files that may be present in the content of the request body.  This is the same as the standard `HttpRequest` behavior, except that the same flexible request parsing that is used for `request.DATA`.
+`request.FILES` returns any uploaded files that may be present in the content of the request body.  This is the same as the standard `HttpRequest` behavior, except that the same flexible request parsing is used for `request.DATA`.
 
 For more details see the [parsers documentation].
 
 ## .QUERY_PARAMS
 
-`request.QUERY_PARAMS` is a more correcly named synonym for `request.GET`.
+`request.QUERY_PARAMS` is a more correctly named synonym for `request.GET`.
 
 For clarity inside your code, we recommend using `request.QUERY_PARAMS` instead of the usual `request.GET`, as *any* HTTP method type may include query parameters.
 
 ## .parsers
 
-The `APIView` class or `@api_view` decorator will ensure that this property is automatically to a list of `Parser` instances, based on the `parser_classes` set on the view or based on the `DEFAULT_PARSERS` setting.
+The `APIView` class or `@api_view` decorator will ensure that this property is automatically set to a list of `Parser` instances, based on the `parser_classes` set on the view or based on the `DEFAULT_PARSER_CLASSES` setting.
 
 You won't typically need to access this property.
 
@@ -51,7 +51,7 @@ If a client sends a request with a content-type that cannot be parsed then a `Un
 
 # Authentication
 
-REST framework provides flexbile, per-request authentication, that gives you the abilty to:
+REST framework provides flexible, per-request authentication, that gives you the ability to:
 
 * Use different authentication policies for different parts of your API.
 * Support the use of multiple authentication policies.
@@ -75,7 +75,7 @@ For more details see the [authentication documentation].
 
 ## .authenticators
 
-The `APIView` class or `@api_view` decorator will ensure that this property is automatically to a list of `Authentication` instances, based on the `authentication_classes` set on the view or based on the `DEFAULT_AUTHENTICATORS` setting.
+The `APIView` class or `@api_view` decorator will ensure that this property is automatically set to a list of `Authentication` instances, based on the `authentication_classes` set on the view or based on the `DEFAULT_AUTHENTICATORS` setting.
 
 You won't typically need to access this property.
 
@@ -83,7 +83,7 @@ You won't typically need to access this property.
 
 # Browser enhancements
 
-REST framework supports a few browser enhancments such as browser-based `PUT` and `DELETE` forms.
+REST framework supports a few browser enhancements such as browser-based `PUT` and `DELETE` forms.
 
 ## .method
 
@@ -125,4 +125,4 @@ Note that due to implementation reasons the `Request` class does not inherit fro
 [cite]: https://groups.google.com/d/topic/django-developers/dxI4qVzrBY4/discussion
 [parsers documentation]: parsers.md
 [authentication documentation]: authentication.md
-[browser enhancements documentation]: ../topics/browser-enhancements.md
-\ No newline at end of file
+[browser enhancements documentation]: ../topics/browser-enhancements.md
diff --git a/docs/api-guide/responses.md b/docs/api-guide/responses.md
index 395decda..794f9377 100644
--- a/docs/api-guide/responses.md
+++ b/docs/api-guide/responses.md
@@ -86,7 +86,7 @@ The `Response` class extends `SimpleTemplateResponse`, and all the usual attribu
 
 **Signature:** `.render()`
 
-As with any other `TemplateResponse`, this methd is called to render the serialized data of the response into the final response content.  When `.render()` is called, the response content will be set to the result of calling the `.render(data, accepted_media_type, renderer_context)` method on the `accepted_renderer` instance.
+As with any other `TemplateResponse`, this method is called to render the serialized data of the response into the final response content.  When `.render()` is called, the response content will be set to the result of calling the `.render(data, accepted_media_type, renderer_context)` method on the `accepted_renderer` instance.
 
 You won't typically need to call `.render()` yourself, as it's handled by Django's standard response cycle.
     
diff --git a/docs/api-guide/reverse.md b/docs/api-guide/reverse.md
index 12346eb4..19930dc3 100644
--- a/docs/api-guide/reverse.md
+++ b/docs/api-guide/reverse.md
@@ -6,7 +6,7 @@
 >
 > &mdash; Roy Fielding, [Architectural Styles and the Design of Network-based Software Architectures][cite]
 
-As a rule, it's probably better practice to return absolute URIs from you Web APIs, such as `http://example.com/foobar`, rather than returning relative URIs, such as `/foobar`.
+As a rule, it's probably better practice to return absolute URIs from your Web APIs, such as `http://example.com/foobar`, rather than returning relative URIs, such as `/foobar`.
 
 The advantages of doing so are:
 
diff --git a/docs/api-guide/serializers.md b/docs/api-guide/serializers.md
index 47958fe3..c10a3f44 100644
--- a/docs/api-guide/serializers.md
+++ b/docs/api-guide/serializers.md
@@ -175,7 +175,7 @@ You can add extra fields to a `ModelSerializer` or override the default fields b
         class Meta:
             model = Account
 
-Extra fields can corrospond to any property or callable on the model.
+Extra fields can correspond to any property or callable on the model.
 
 ## Relational fields
 
@@ -187,7 +187,7 @@ The `PrimaryKeyRelatedField` and `HyperlinkedRelatedField` fields provide altern
 
 The `ModelSerializer` class can itself be used as a field, in order to serialize relationships using nested representations.
 
-The `RelatedField` class may be subclassed to create a custom represenation of a relationship.  The subclass should override `.to_native()`, and optionally `.from_native()` if deserialization is supported.
+The `RelatedField` class may be subclassed to create a custom representation of a relationship.  The subclass should override `.to_native()`, and optionally `.from_native()` if deserialization is supported.
 
 All the relational fields may be used for any relationship or reverse relationship on a model.
 
diff --git a/docs/api-guide/settings.md b/docs/api-guide/settings.md
index 84acd797..21efc853 100644
--- a/docs/api-guide/settings.md
+++ b/docs/api-guide/settings.md
@@ -11,10 +11,10 @@ Configuration for REST framework is all namespaced inside a single Django settin
 For example your project's `settings.py` file might include something like this:
 
     REST_FRAMEWORK = {
-        'DEFAULT_RENDERERS': (
+        'DEFAULT_RENDERER_CLASSES': (
             'rest_framework.renderers.YAMLRenderer',
         )
-        'DEFAULT_PARSERS': (
+        'DEFAULT_PARSER_CLASSES': (
             'rest_framework.parsers.YAMLParser',
         )
     }
@@ -26,7 +26,7 @@ you should use the `api_settings` object.  For example.
 
     from rest_framework.settings import api_settings
     
-    print api_settings.DEFAULT_AUTHENTICATION
+    print api_settings.DEFAULT_AUTHENTICATION_CLASSES
 
 The `api_settings` object will check for any user-defined settings, and otherwise fallback to the default values.  Any setting that uses string import paths to refer to a class will automatically import and return the referenced class, instead of the string literal.
 
@@ -34,7 +34,7 @@ The `api_settings` object will check for any user-defined settings, and otherwis
 
 # API Reference
 
-## DEFAULT_RENDERERS
+## DEFAULT_RENDERER_CLASSES
 
 A list or tuple of renderer classes, that determines the default set of renderers that may be used when returning a `Response` object.
 
@@ -46,7 +46,7 @@ Default:
         'rest_framework.renderers.TemplateHTMLRenderer'
     )
 
-## DEFAULT_PARSERS
+## DEFAULT_PARSER_CLASSES
 
 A list or tuple of parser classes, that determines the default set of parsers used when accessing the `request.DATA` property.
 
@@ -57,7 +57,7 @@ Default:
         'rest_framework.parsers.FormParser'
     )
 
-## DEFAULT_AUTHENTICATION
+## DEFAULT_AUTHENTICATION_CLASSES
 
 A list or tuple of authentication classes, that determines the default set of authenticators used when accessing the `request.user` or `request.auth` properties.
 
@@ -68,25 +68,25 @@ Default:
         'rest_framework.authentication.UserBasicAuthentication'
     )
 
-## DEFAULT_PERMISSIONS
+## DEFAULT_PERMISSION_CLASSES
 
 A list or tuple of permission classes, that determines the default set of permissions checked at the start of a view.
 
 Default: `()`
 
-## DEFAULT_THROTTLES
+## DEFAULT_THROTTLE_CLASSES
 
 A list or tuple of throttle classes, that determines the default set of throttles checked at the start of a view.
 
 Default: `()`
 
-## DEFAULT_MODEL_SERIALIZER
+## DEFAULT_MODEL_SERIALIZER_CLASS
 
 **TODO**
 
 Default: `rest_framework.serializers.ModelSerializer`
 
-## DEFAULT_PAGINATION_SERIALIZER
+## DEFAULT_PAGINATION_SERIALIZER_CLASS
 
 **TODO**
 
diff --git a/docs/api-guide/throttling.md b/docs/api-guide/throttling.md
index 22e34187..d54433b1 100644
--- a/docs/api-guide/throttling.md
+++ b/docs/api-guide/throttling.md
@@ -27,10 +27,10 @@ If any throttle check fails an `exceptions.Throttled` exception will be raised,
 
 ## Setting the throttling policy
 
-The default throttling policy may be set globally, using the `DEFAULT_THROTTLES` and `DEFAULT_THROTTLE_RATES` settings.  For example.
+The default throttling policy may be set globally, using the `DEFAULT_THROTTLE_CLASSES` and `DEFAULT_THROTTLE_RATES` settings.  For example.
 
     REST_FRAMEWORK = {
-        'DEFAULT_THROTTLES': (
+        'DEFAULT_THROTTLE_CLASSES': (
             'rest_framework.throttles.AnonThrottle',
             'rest_framework.throttles.UserThrottle',
         )
@@ -80,7 +80,7 @@ The allowed request rate is determined from one of the following (in order of pr
 
 ## UserRateThrottle
 
-The `UserThrottle` will throttle users to a given rate of requests across the API.  The user id is used to generate a unique key to throttle against.  Unauthenticted requests will fall back to using the IP address of the incoming request to generate a unique key to throttle against.
+The `UserThrottle` will throttle users to a given rate of requests across the API.  The user id is used to generate a unique key to throttle against.  Unauthenticated requests will fall back to using the IP address of the incoming request to generate a unique key to throttle against.
 
 The allowed request rate is determined from one of the following (in order of preference).
 
@@ -100,7 +100,7 @@ For example, multiple user throttle rates could be implemented by using the foll
 ...and the following settings.
 
     REST_FRAMEWORK = {
-        'DEFAULT_THROTTLES': (
+        'DEFAULT_THROTTLE_CLASSES': (
             'example.throttles.BurstRateThrottle',
             'example.throttles.SustainedRateThrottle',
         )
@@ -114,7 +114,7 @@ For example, multiple user throttle rates could be implemented by using the foll
 
 ## ScopedRateThrottle
 
-The `ScopedThrottle` class can be used to restrict access to specific parts of the API.  This throttle will only be applied if the view that is being accessed includes a `.throttle_scope` property.  The unique throttle key will then be formed by concatenating the "scope" of the request with the unqiue user id or IP address.
+The `ScopedThrottle` class can be used to restrict access to specific parts of the API.  This throttle will only be applied if the view that is being accessed includes a `.throttle_scope` property.  The unique throttle key will then be formed by concatenating the "scope" of the request with the unique user id or IP address.
 
 The allowed request rate is determined by the `DEFAULT_THROTTLE_RATES` setting using a key from the request "scope".
 
@@ -135,7 +135,7 @@ For example, given the following views...
 ...and the following settings.
 
     REST_FRAMEWORK = {
-        'DEFAULT_THROTTLES': (
+        'DEFAULT_THROTTLE_CLASSES': (
             'rest_framework.throttles.ScopedRateThrottle',
         )
         'DEFAULT_THROTTLE_RATES': {
@@ -152,6 +152,6 @@ User requests to either `ContactListView` or `ContactDetailView` would be restri
 
 To create a custom throttle, override `BaseThrottle` and implement `.allow_request(request, view)`.  The method should return `True` if the request should be allowed, and `False` otherwise.
 
-Optionally you may also override the `.wait()` method.  If implemented, `.wait()` should return a recomended number of seconds to wait before attempting the next request, or `None`.  The `.wait()` method will only be called if `.allow_request()` has previously returned `False`.
+Optionally you may also override the `.wait()` method.  If implemented, `.wait()` should return a recommended number of seconds to wait before attempting the next request, or `None`.  The `.wait()` method will only be called if `.allow_request()` has previously returned `False`.
 
 [permissions]: permissions.md
diff --git a/docs/api-guide/views.md b/docs/api-guide/views.md
index 77349252..e3fbadb2 100644
--- a/docs/api-guide/views.md
+++ b/docs/api-guide/views.md
@@ -27,7 +27,7 @@ For example:
         * Only admin users are able to access this view.
         """
         authentication_classes = (authentication.TokenAuthentication,)
-        permission_classes = (permissions.IsAdmin,)
+        permission_classes = (permissions.IsAdminUser,)
 
         def get(self, request, format=None):
             """
@@ -123,4 +123,4 @@ REST framework also gives you to work with regular function based views...
 **[TODO]**
 
 [cite]: http://reinout.vanrees.org/weblog/2011/08/24/class-based-views-usage.html
-[cite2]: http://www.boredomandlaziness.org/2012/05/djangos-cbvs-are-not-mistake-but.html
-\ No newline at end of file
+[cite2]: http://www.boredomandlaziness.org/2012/05/djangos-cbvs-are-not-mistake-but.html