Filling out docs a bit more

This commit is contained in:
Tom Christie 2012-09-07 09:37:06 +01:00
parent 01d6a0899e
commit da5a6243f3
2 changed files with 29 additions and 15 deletions

View File

@ -1,4 +1,4 @@
# Tutorial 2: Request and Response objects # Tutorial 2: Requests and Responses
From this point we're going to really start covering the core of REST framework. From this point we're going to really start covering the core of REST framework.
Let's introduce a couple of essential building blocks. Let's introduce a couple of essential building blocks.

View File

@ -1,4 +1,4 @@
# Tutorial 3: Using Class Based Views # Tutorial 3: Class Based Views
We can also write our API views using class based views, rather than function based views. As we'll see this is a powerful pattern that allows us to reuse common functionality, and helps us keep our code [DRY][1]. We can also write our API views using class based views, rather than function based views. As we'll see this is a powerful pattern that allows us to reuse common functionality, and helps us keep our code [DRY][1].
@ -73,19 +73,18 @@ Okay, we're done. If you run the development server everything should be workin
One of the big wins of using class based views is that it allows us to easily compose reusable bits of behaviour. One of the big wins of using class based views is that it allows us to easily compose reusable bits of behaviour.
The create/retrieve/update/delete operations that we've been using so far is going to be pretty simliar for any model-backed API views we create. Those bits of common behaviour are implemented in REST framework's mixin classes. The create/retrieve/update/delete operations that we've been using so far are going to be pretty simliar for any model-backed API views we create. Those bits of common behaviour are implemented in REST framework's mixin classes.
We can compose those mixin classes, to recreate our existing API behaviour with less code. Let's take a look at how we can compose our views by using the mixin classes.
from blog.models import Comment from blog.models import Comment
from blog.serializers import CommentSerializer from blog.serializers import CommentSerializer
from djangorestframework import mixins from djangorestframework import mixins
from djangorestframework import views from djangorestframework import generics
class CommentRoot(mixins.ListModelMixin, class CommentRoot(mixins.ListModelMixin,
mixins.CreateModelMixin, mixins.CreateModelMixin,
views.MultipleObjectBaseView): generics.MultipleObjectBaseView):
model = Comment model = Comment
serializer_class = CommentSerializer serializer_class = CommentSerializer
@ -95,11 +94,16 @@ We can compose those mixin classes, to recreate our existing API behaviour with
def post(self, request, *args, **kwargs): def post(self, request, *args, **kwargs):
return self.create(request, *args, **kwargs) return self.create(request, *args, **kwargs)
comment_root = CommentRoot.as_view()
We'll take a moment to examine exactly what's happening here - We're building our view using `MultipleObjectBaseView`, and adding in `ListModelMixin` and `CreateModelMixin`.
The base class provides the core functionality, and the mixin classes provide the `.list()` and `.create()` actions. We're then explictly binding the `get` and `post` methods to the appropriate actions. Simple enough stuff so far.
class CommentInstance(mixins.RetrieveModelMixin, class CommentInstance(mixins.RetrieveModelMixin,
mixins.UpdateModelMixin, mixins.UpdateModelMixin,
mixins.DestroyModelMixin, mixins.DestroyModelMixin,
views.SingleObjectBaseView): generics.SingleObjectBaseView):
model = Comment model = Comment
serializer_class = CommentSerializer serializer_class = CommentSerializer
@ -112,24 +116,34 @@ We can compose those mixin classes, to recreate our existing API behaviour with
def delete(self, request, *args, **kwargs): def delete(self, request, *args, **kwargs):
return self.destroy(request, *args, **kwargs) return self.destroy(request, *args, **kwargs)
## Reusing generic class based views comment_instance = CommentInstance.as_view()
That's a lot less code than before, but we can go one step further still. REST framework also provides a set of already mixed-in views. Pretty similar. This time we're using the `SingleObjectBaseView` class to provide the core functionality, and adding in mixins to provide the `.retrieve()`, `.update()` and `.destroy()` actions.
## Using generic class based views
Using the mixin classes we've rewritten the views to use slightly less code than before, but we can go one step further. REST framework provides a set of already mixed-in generic views that we can use.
from blog.models import Comment from blog.models import Comment
from blog.serializers import CommentSerializer from blog.serializers import CommentSerializer
from djangorestframework import views from djangorestframework import generics
class CommentRoot(views.RootModelView):
class CommentRoot(generics.RootAPIView):
model = Comment model = Comment
serializer_class = CommentSerializer serializer_class = CommentSerializer
class CommentInstance(views.InstanceModelView): comment_root = CommentRoot.as_view()
class CommentInstance(generics.InstanceAPIView):
model = Comment model = Comment
serializer_class = CommentSerializer serializer_class = CommentSerializer
Wow, that's pretty concise. We've got a huge amount for free, and our code looks like comment_instance = CommentInstance.as_view()
good, clean, idomatic Django.
Wow, that's pretty concise. We've got a huge amount for free, and our code looks like good, clean, idomatic Django.
Next we'll move onto [part 4 of the tutorial][2], where we'll take a look at how we can customize the behavior of our views to support a range of authentication, permissions, throttling and other aspects. Next we'll move onto [part 4 of the tutorial][2], where we'll take a look at how we can customize the behavior of our views to support a range of authentication, permissions, throttling and other aspects.