4 files changed, 20 insertions, 11 deletions
diff --git a/docs/api-guide/authentication.md b/docs/api-guide/authentication.md
index 342fabe7..fae86386 100644
--- a/docs/api-guide/authentication.md
+++ b/docs/api-guide/authentication.md
@@ -10,7 +10,7 @@ Authentication is the mechanism of associating an incoming request with a set of
 
 REST framework provides a number of authentication schemes out of the box, and also allows you to implement custom schemes.
 
-Authentication will run the first time either the `request.user` or `request.auth` properties are accessed, and determines how those properties are initialized.
+Authentication is always run at the very start of the view, before the permission and throttling checks occur, and before any other code is allowed to proceed.
 
 The `request.user` property will typically be set to an instance of the `contrib.auth` package's `User` class.
 
@@ -191,7 +191,7 @@ In some circumstances instead of returning `None`, you may want to raise an `Aut
 Typically the approach you should take is:
 
 * If authentication is not attempted, return `None`.  Any other authentication schemes also in use will still be checked.
-* If authentication is attempted but fails, raise a `AuthenticationFailed` exception.  An error response will be returned immediately, without checking any other authentication schemes.
+* If authentication is attempted but fails, raise a `AuthenticationFailed` exception.  An error response will be returned immediately, regardless of any permissions checks, and without checking any other authentication schemes.
 
 You *may* also override the `.authenticate_header(self, request)` method.  If implemented, it should return a string that will be used as the value of the `WWW-Authenticate` header in a `HTTP 401 Unauthorized` response.
 
diff --git a/docs/api-guide/fields.md b/docs/api-guide/fields.md
index 898de12d..c1f3c051 100644
--- a/docs/api-guide/fields.md
+++ b/docs/api-guide/fields.md
@@ -102,7 +102,7 @@ You can customize this  behavior by overriding the `.to_native(self, value)` met
 
 ## WritableField
 
-A field that supports both read and write operations.  By itself `WriteableField` does not perform any translation of input values into a given type.  You won't typically use this field directly, but you may want to override it and implement the `.to_native(self, value)` and `.from_native(self, value)` methods.
+A field that supports both read and write operations.  By itself `WritableField` does not perform any translation of input values into a given type.  You won't typically use this field directly, but you may want to override it and implement the `.to_native(self, value)` and `.from_native(self, value)` methods.
 
 ## ModelField
 
diff --git a/docs/api-guide/format-suffixes.md b/docs/api-guide/format-suffixes.md
index 6d5feba4..dae3dea3 100644
--- a/docs/api-guide/format-suffixes.md
+++ b/docs/api-guide/format-suffixes.md
@@ -29,18 +29,27 @@ Example:
     
     urlpatterns = patterns('blog.views',
         url(r'^/$', 'api_root'),
-        url(r'^comment/$', 'comment_root'),
-        url(r'^comment/(?P<pk>[0-9]+)/$', 'comment_instance')
+        url(r'^comments/$', 'comment_list'),
+        url(r'^comments/(?P<pk>[0-9]+)/$', 'comment_detail')
     )
     
     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.
+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):
+    @api_view(('GET', 'POST'))
+    def comment_list(request, format=None):
         # do stuff...
 
+Or with class based views:
+
+    class CommentList(APIView):
+        def get(self, request, format=None):
+            # do stuff...
+
+        def post(self, 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.
@@ -58,4 +67,4 @@ It is actually a misconception.  For example, take the following quote from Roy
 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
+[cite2]: http://tech.groups.yahoo.com/group/rest-discuss/message/14844
diff --git a/docs/api-guide/renderers.md b/docs/api-guide/renderers.md
index 5de1491b..3c8396aa 100644
--- a/docs/api-guide/renderers.md
+++ b/docs/api-guide/renderers.md
@@ -123,7 +123,7 @@ The template name is determined by (in order of preference):
 
 An example of a view that uses `TemplateHTMLRenderer`:
 
-    class UserInstance(generics.RetrieveUserAPIView):
+    class UserDetail(generics.RetrieveUserAPIView):
         """
         A view that returns a templated HTML representations of a given user.
         """
@@ -301,4 +301,4 @@ Comma-separated values are a plain-text tabular data format, that can be easily
 [juanriaza]: https://github.com/juanriaza
 [mjumbewu]: https://github.com/mjumbewu
 [djangorestframework-msgpack]: https://github.com/juanriaza/django-rest-framework-msgpack
-[djangorestframework-csv]: https://github.com/mjumbewu/django-rest-framework-csv
-\ No newline at end of file
+[djangorestframework-csv]: https://github.com/mjumbewu/django-rest-framework-csv