Creating a DjangoRest API using DjangoRestFramework part 2.
This is the second part of a series. The first part can be found here. In this part, we will recreate the Blog API that we created in the previous articles but now using GenericAPIView instead of basic APIView.
Why use GenericAPIView you may ask. This class extends REST framework’s
APIView class, adding commonly required behavior for standard list and detail views. Let's dive in and see this in action to make it more clear.
From above, we start by extending
GenericAPIView Provides the basic functionality while the
ListModelMixin provide the
.list() action (Mixins , provide the actions that are used to provide the basic view behavior). In order for the
.list() to work, we need to explicitly bind
get method to the
This provides us with the ability to return a list of all articles that we currently have in our database. But in order for this to work, two attributes are required.
This is basically the queryset that should be used for returning objects from this view. In our case, we want to return all the articles. If we wanted some more customization, we could override
get_querysetmethod instead and do some more customization from there.
This is the serializer class that should be used for validating and deserializing input, and for serializing output. We will use the
ArticleSerializerwe had created earlier.
Our serializer, however, is replicating a lot of information that’s also contained in the Article model. I think it would be nice if we could keep our code a bit more concise.
Let's update our serializer to use a model serializer as shown below
By using a ModelSerializer, we get by default
update methods for free. Also, a set of default validators are automatically populated.
With this, you will still be able to see a list of all articles from the API endpoint.
Since we are building a CRUD app, we will need to provide the user with the ability to create an article. To do this, we will use another Mixin called CreateModelMixin
Update your views to the following
Since every article has an author, we are accepting
author_id to be passed in the post request and using it to find if such an author exists. This can, however, be updated to automatically set the author to the logged in user; I will leave this as a small challenge for you.
With this, you are now able to create an article by sending a POST request to
I am sure you are already appreciating the lines of code we have reduced our API with from the previous article.
I am disturbed by the fact that we have to define the
post methods in our class to just call some other methods without doing any processing. Some GenericAPIViews exist to help us with this; after all, this is a blog on GenericAPIViews.
CreateAPIView extends from the CreateModelMixin that we were extending above and defines a
post method for us. We can, therefore, extend CreateAPIView and forget about writing the
post method ourselves. The same applies to the
get method. We can just extend ListAPIView and forget about writing the
Let's update the code to look like
At this point, the API should still be working as expected.
Even further, we can use a special GenericView and combine both creating an article and listing an article. We will use
ListCreateAPIView . For this, we will need to update our code to the following.
Next, we need to allow users to update their articles. For this, to happen, we need to provide the user with a way to retrieve a single article. DRF provides us with the
RetrieveAPIView for this exact functionality. To deal with a single Article, we will create a new class that extends the
RetrieveAPIView as shown below.
Notice how we are just adding a single class and a feature gets completed? That's the fun of using GenericViews.
We will need to update our URLs to reflect this. Add this to your urls.py
RetrieveAPIView , we are only able to view a single article using that article
id. To be able to update an article, we will need to use another GenericView; The
RetrieveUpdateAPIView will do the trick. it lets us retrieve a single article and at the same time allow us to update the article. While using the DRF browsable API, the fields are even pre-populated for us 😊.
With this, you will be able to create, list, retrieve and update articles.
One more thing, I am sure you guessed it right. Allowing users to delete an article. For this, we will follow the same trend and pick up a DRF generic class that has been built to specifically do this. The
RetrieveUpdateDestroyAPIView does exactly as it says. With this added as the class, we are inheriting from, we will now be able to retrieve an article, update the article and delete the article.
With GenericAPIViews, we have dramatically reduced the amount of code we had to write in order for us to perform the CRUD operations. I am not sure you will believe that we can write even less code if we used
viewsets . See you in part 3 of this series where you will find out.
Cheers and happy hacking.