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].
## Rewriting our API using class based views
We'll start by rewriting the root view as a class based view. All this involves is a little bit of refactoring.
So far, so good. It looks pretty similar to the previous case, but we've got better seperation between the different HTTP methods. We'll also need to update the instance view.
Okay, we're done. If you run the development server everything should be working just as before.
## Using mixins
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.
We can compose those mixin classes, to recreate our existing API behaviour with less code.
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.