diff --git a/tutorial/2-requests-and-responses.html b/tutorial/2-requests-and-responses.html index 40355be53..82011802a 100644 --- a/tutorial/2-requests-and-responses.html +++ b/tutorial/2-requests-and-responses.html @@ -217,7 +217,7 @@ urlpatterns = format_suffix_patterns(urlpatterns)

Because the API chooses a return format based on what the client asks for, it will, by default, return an HTML-formatted representation of the resource when that resource is requested by a browser. This allows for the API to be easily browsable and usable by humans.

See the browsable api topic for more information about the browsable API feature and how to customize it.

What's next?

-

In tutorial part 3, we'll start using class based views, and see how generic views reduce the amount of code we need to write.

+

In tutorial part 3, we'll start using class based views, and see how generic views reduce the amount of code we need to write.

diff --git a/tutorial/4-authentication-permissions-and-throttling.html b/tutorial/4-authentication-permissions-and-throttling.html index cb35bed40..af86ac8f0 100644 --- a/tutorial/4-authentication-permissions-and-throttling.html +++ b/tutorial/4-authentication-permissions-and-throttling.html @@ -93,13 +93,15 @@
-

part 5

+

Tutorial 4: Authentication & Permissions

+

Nothing to see here. Onwards to part 5.

diff --git a/tutorial/5-relationships-and-hyperlinked-apis.html b/tutorial/5-relationships-and-hyperlinked-apis.html index 19bf18e12..36a404f6a 100644 --- a/tutorial/5-relationships-and-hyperlinked-apis.html +++ b/tutorial/5-relationships-and-hyperlinked-apis.html @@ -93,19 +93,21 @@
-

TODO

+

Tutorial 5 - Relationships & Hyperlinked APIs

+

TODO

-

part 6

+

Onwards to part 6.

diff --git a/tutorial/6-resource-orientated-projects.html b/tutorial/6-resource-orientated-projects.html index 52af194ba..29d92f5f8 100644 --- a/tutorial/6-resource-orientated-projects.html +++ b/tutorial/6-resource-orientated-projects.html @@ -93,7 +93,10 @@
-

In REST framework Resources classes are just View classes that don't have any handler methods bound to them. This allows us to seperate out the behaviour of the classes from how that behaviour should be bound to a set of URLs.

-

For instance, given our serializers

-

serializers.py

-
class BlogPostSerializer(URLModelSerializer):
-    class Meta:
-        model = BlogPost
-
-class CommentSerializer(URLModelSerializer):
-    class Meta:
-        model = Comment
-
-

We can re-write our 4 sets of views into something more compact...

+

Tutorial 6 - Resources

+

Resource classes are just View classes that don't have any handler methods bound to them. The actions on a resource are defined,

+

This allows us to:

+ +

Refactoring to use Resources, not Views

+

For instance, we can re-write our 4 sets of views into something more compact...

resources.py

class BlogPostResource(ModelResource):
     serializer_class = BlogPostSerializer
@@ -127,6 +127,7 @@ class CommentResource(ModelResource):
     permissions_classes = (permissions.IsAuthenticatedOrReadOnly,)
     throttle_classes = (throttles.UserRateThrottle,)
+

Binding Resources to URLs explicitly

The handler methods only get bound to the actions when we define the URLConf. Here's our urls.py:

comment_root = CommentResource.as_view(actions={
     'get': 'list',
@@ -165,7 +166,7 @@ urlpatterns = router.urlpatterns
 
  • Join the REST framework group, and help build the community.
    • 
 
  • Follow me on Twitter and say hi.
    • 
 
-
    Now go build something great.
    
+
    Now go build some awesome things.