Simplifying bits of docs

3 files changed, 16 insertions, 8 deletions

diff --git a/docs/api-guide/generic-views.md b/docs/api-guide/generic-views.md
index 4a24b7c7..5de12bdb 100755
--- a/docs/api-guide/generic-views.md
+++ b/docs/api-guide/generic-views.md
@@ -62,6 +62,10 @@ The following attributes control the basic view behavior.
 * `serializer_class` - The serializer class that should be used for validating and deserializing input, and for serializing output.  Typically, you must either set this attribute, or override the `get_serializer_class()` method.
 * `lookup_field` - The field that should be used to lookup individual model instances.  Defaults to `'pk'`.  The URL conf should include a keyword argument corresponding to this value.  More complex lookup styles can be supported by overriding the `get_object()` method.
 
+**Shortcuts**:
+
+* `model` - This shortcut may be used instead of setting either (or both) of the `queryset`/`serializer_class` attributes, although using the explicit style is generally preferred.  If used instead of `serializer_class`, then then `DEFAULT_MODEL_SERIALIZER_CLASS` setting will determine the base serializer class.
+
 **Pagination**:
 
 The following attibutes are used to control pagination when used with list views.
@@ -75,7 +79,6 @@ The following attibutes are used to control pagination when used with list views
 
 * `filter_backend` - The filter backend class that should be used for filtering the queryset.  Defaults to the same value as the `FILTER_BACKEND` setting.
 * `allow_empty` - Determines if an empty list should successfully display zero results, or return a 404 response.  Defaults to `True`, meaning empty lists will return sucessful `200 OK` responses, with zero results.
-* `model` - This shortcut may be used instead of setting either (or both) of the `queryset`/`serializer_class` attributes, although using the explicit style is generally preferred.  If used instead of `serializer_class`, then then `DEFAULT_MODEL_SERIALIZER_CLASS` setting will determine the base serializer class.
 
 ### Methods
 
@@ -160,7 +163,7 @@ The following classes are the concrete generic views.  If you're using generic v
 
 Used for **create-only** endpoints.
 
-Provides `post` method handlers.
+Provides a `post` method handler.
 
 Extends: [GenericAPIView], [CreateModelMixin]
 
diff --git a/docs/api-guide/routers.md b/docs/api-guide/routers.md
index 7495b91c..6588d7e5 100644
--- a/docs/api-guide/routers.md
+++ b/docs/api-guide/routers.md
@@ -15,15 +15,18 @@ REST framework adds support for automatic URL routing to Django, and provides yo
 Here's an example of a simple URL conf, that uses `DefaultRouter`.
 
     router = routers.SimpleRouter()
-    router.register(r'users', UserViewSet, name='user')
-    router.register(r'accounts', AccountViewSet, name='account')
+    router.register(r'users', UserViewSet)
+    router.register(r'accounts', AccountViewSet)
     urlpatterns = router.urls
 
-There are three arguments to the `register()` method:
+There are two mandatory arguments to the `register()` method:
 
 * `prefix` - The URL prefix to use for this set of routes.
 * `viewset` - The viewset class.
-* `name` - The base to use for the URL names that are created.
+
+Optionally, you may also specify an additional argument:
+
+* `base_name` - The base to use for the URL names that are created.  If unset the basename will be automatically generated based on the `model` or `queryset` attribute on the viewset, if it has one.
 
 The example above would generate the following URL patterns:
 
@@ -101,6 +104,8 @@ The following example will only route to the `list` and `retrieve` actions, and
 
 ## Advanced custom routers
 
-If you want to provide totally custom behavior, you can override `BaseRouter` and override the `get_urls()` method.  The method should insect the registered viewsets and return a list of URL patterns.  The registered prefix, viewset and basename tuples may be inspected by accessing the `self.registry` attribute.  
+If you want to provide totally custom behavior, you can override `BaseRouter` and override the `get_urls(self)` method.  The method should insect the registered viewsets and return a list of URL patterns.  The registered prefix, viewset and basename tuples may be inspected by accessing the `self.registry` attribute.  
+
+You may also want to override the `get_default_base_name(self, viewset)` method, or else always explicitly set the `base_name` argument when registering your viewsets with the router.
 
 [cite]: http://guides.rubyonrails.org/routing.html
diff --git a/docs/api-guide/viewsets.md b/docs/api-guide/viewsets.md
index 8af35bb8..d98f37d8 100644
--- a/docs/api-guide/viewsets.md
+++ b/docs/api-guide/viewsets.md
@@ -42,7 +42,7 @@ If we need to, we can bind this viewset into two seperate views, like so:
 Typically we wouldn't do this, but would instead register the viewset with a router, and allow the urlconf to be automatically generated.
 
     router = DefaultRouter()
-    router.register(r'users', UserViewSet, name='user')
+    router.register(r'users', UserViewSet)
     urlpatterns = router.urls
 
 Rather than writing your own viewsets, you'll often want to use the existing base classes that provide a default set of behavior.  For example: