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.

New ArticleView

From above, we start by extending

ListModelMixin and GenericAPIView

The 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 list action.

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.

1. queryset
   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_queryset method instead and do some more customization from there.
2. serializer_class
   This is the serializer class that should be used for validating and deserializing input, and for serializing output. We will use the ArticleSerializer we 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.

ModelSerializer

Let's update our serializer to use a model serializer as shown below

By using a ModelSerializer, we get by default

create and 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 http://127.0.0.1:8000/api/articles/ .
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 get and 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 get method.

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

path('articles/<int:pk>', SingleArticleView.as_view()),

With the 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.

Do you need to hire top developers? Talk to Andela to help you scale.
Are you looking to accelerate your career as a developer? Andela is currently hiring senior developers. Apply now.