Django Logging

ViewSets

• ViewSet is considered one of the class-based view types.
• In place of method handlers such as .get() and .post(), .lost() and .create() method are provided by it.
• Automatic handling of URL construction is one of the most significant advantages of the ViewSets in Django.

Basically, viewsets are classified into four types and classified is from the most basic to the most powerful one:

• ViewSet
• GenericViewSet
• ReadOnlyModelViewSet
• ModelViewSet

Refer to the below image for the ViewSet classification

All the magic happens in the class named ViewSetMixin. All four viewsets share only one same class i.e. ViewSetMixin. as_view method is overridden by it and proper action is combined with the method by it.

ViewSet Class

The advantage of the APIView class is taken by the ViewSet class. No Default actions are provided by it but it can be used by users for the creation of their views set.

The GET HTTP method is provided by the ViewSets in Django by which list action is mapped and this is used for all instance listing and single instance retrieval retrieve action.

Actions

The router class by default handles the actions which are given below:

• list
• retrieve (pk needed)
• create
• partial_update (pk needed)
• update (pk needed)
• destroy (pk needed)

@action decorator can also be used for custom action creation.

For example:

Here items_not_done is a custom action defined by us. GET is the HTTP method that is allowed. GET is allowed by default but we are setting it explicitly. Optional parameters are method parameters but the detail parameters are not optional. In case of action is meant for a single object then the value of the detail parameter is set to true. And if the instead of single object action is meant for all the objects then its value is set to false. By default, actions can be accessed by using the URL given below: /items_not_done In case you want to manipulate this URL then this can be done by setting the value of the decorator url_path parameter.

Handling URLs

ViewSets in Django contains a router class that provides the URL configurations automatically. So it does not require urlpatterns of Django. DRF comes with two routers out-of-the-box:

• DefaultRouter
• SimpleRouter

The Major point that differentiates these two is that the default API root view is included in DefaultRouter. It is easy to navigate with your application as the hyperlinked list view is listed by the default API root view.

There is a possibility of the creation of a custom router.

A combination of routers with patterns can be possible.

Here the router is created (with the help of DefaultRouter to obtain the default API view), and ItemsViewSet is registered to it. It is mandatory to provide two arguments whenever there is a creation of any router.

• The ViewSet itself.
• For the views, URL prefix.

After this, the router is included in the urlpatterns There are many different methods to include routers. For availing of more options, refer to the Router's documentation. A list of items can be accessed through this http://127.0.0.1:8000/custom-viewset/ and a single item can be accessed through this http://127.0.0.1:8000/custom-viewset/{id}/. in the process of documentation. GET is the only allowed method in ItemsViewSet, as only retrieve and list actions are defined by us.

GenericViewSet

APIView is extended by the ViewSets in Django, on the other hand, GenericAPIView is extended by the GenericViewSet in Django. The generic view behavior base set is provided by the GenericViewSet along with that it also provides get_queryset() and get_object methods. Creation of the ViewSet and GenericViewSet takes place like this.

ViewSetMixin, APIView or GenericAPI are extended by both. Except that, there is no extra code. For GenericViewSet class utilization, it is required to override the class and either implementation of the actions is defined explicitly or use the class named mixin for achieving the wanted result. GenericViewSet is used in combination with Mixins

GenericViewSet can be combined with the RetrieveModelMixin and ListModelMixin mixins. As this is a ViewSet, URL mapping is taken into care by the router, and for the detail and list views actions are provided by the mixin.

Using GenericViewSet with Explicit Action Implementations

When the mixins are used, then the user is required to provide only queryset and serializer_class attributes; otherwise, the actions are required to be implemented by you on your own. We will go through a little more complicated example so that we can emphasize the importance of GenericViewSet vs ViewSet.

In this example, ViewSet is created by which list, create, destroy, and retrieve actions are allowed. As the GenericViewSet is extended by us so

• DjangoObjectPermissions are used by us and do not require you to check the permissions of the object on your own.
• Paginated response is returned

ModelViewSet

As the GenericViewSet and all available mixins are used by it Default actions create, list, update, retrieve, partial_update, and destroy are provided by the ModelViewset. Among all the views ModelViewSet is the easiest to use: There is the only requirement below the given 3 lines:

You are good to go after the view registration to the router.

You can now do

• Item creation and items listing
• Single item retrieval, deletion, and updation.

ReadOnlyModelViewSet

Retrieve and list actions are only provided by the ReadOnlyModelViewSet. It provides these actions by combining GenericViewSet with the two mixins that are: ListModelMixin and RetrieveModelMixin. Similar to the ReadOnlyModelViewSet, ModelViewSet, serializer_class, and queryset attributes are only required by it.

APIViews

The APIView class is one of the important components of the DRF views and the view class of Django is subclassed by it. All the views selected by you for your DRF application, for all that views APIView class acts as a base. Whether it be:

• function-based views
• mixins
• class-based views
• viewsets
• generic view classes

APIView class is used by all.

Refer to the below image for the APIView demonstration

Most freedom is offered by the extension of the APIView, instead of a lot of work left by it for the user. In case of having complicated views and controlling the views of every aspect, APIView is a great selection of yours. Quick development is possible by the generic view classes, but a bit of control is provided by it for the API endpoints. The API stood up along with the code of 5 lines provided by the ModelViewSet. Of those 5 lines three lines are for your views and URLs there are 2 lines. Customization of all the views defined above is also possible.

Generic Views

The commonly used pattern set is referred to as a Generic view. Building of Generic view is done on top of the APIView class. The main objective of the generic view is to allow API view building faster which is closely mapped with the models of the database without repetition of yourself. It comprises concrete views, mixins, and GenericAPIView:

• APIView’s more loaded version is the GenericAPIView. There can not be any proper utilization of its own but it can be utilized in reusable action creation.
• Mixins does not have any use without using the GenericAPIView
• For views creation used in APIs often, GenericAPIView is combined with the appropriate mixins by the Concrete views.

Various names are used by DRF for concrete views. Concrete views are specified as concrete generic views or concrete views, concrete view classes in the documentation and the comments of code.