132👍
They are different, let’s see.
DRF has two main systems for handling views:
- APIView: This provides methods handler for http verbs:
get
,post
,put
,patch
, anddelete
. - ViewSet: This is an abstraction over APIView, which provides actions as methods:
list
: read only, returns multiple resources (http verb:get
). Returns a list of dicts.retrieve
: read only, single resource (http verb:get
, but will expect an id in the url). Returns a single dict.create
: creates a new resource (http verb:post
)update/partial_update
: edits a resource (http verbs:put/patch
)destroy
: removes a resource (http verb:delete
)
Both can be used with normal django urls.
Because of the conventions established with the actions, the ViewSet
has also the ability to be mapped into a router, which is really helpful.
Now, both of this Views, have shortcuts, these shortcuts give you a simple implementation ready to be used.
GenericAPIView: for APIView
, this gives you shortcuts that map closely to your database models. Adds commonly required behavior for standard list and detail views. Gives you some attributes like, the serializer_class
, also gives pagination_class
, filter_backend
, etc
GenericViewSet: There are many GenericViewSet, the most common being ModelViewSet
. They inherit from GenericAPIView
and have a full implementation of all of the actions: list
, retrieve
, destroy
, updated
, etc. Of course, you can also pick some of them, read the docs.
So, to answer your question: DRY, if you are doing something really simple, with a ModelViewSet
should be enough, even redefining and calling super
also is enough. For more complex cases, you can go for lower level classes.
Hope to have helped you!
17👍
My golden rule for this is to use generics whenever I have to override the default methods to accomplish different specifications from list and details views.
For instance, when you have different serializer classes for listing your resources and for retrieving a resource details by id I consider that using generics is a better option since probably these two endpoints’ logic is going to evolve separately. Keep in mind is a good practice to maintain different logics decoupled.
When your endpoint is very simple and you don’t need to customize logic between list/create and retrieve/update/delete operations you can use viewset, but yet having in mind it may be good to separate it in two views in case these operations’ logic start growing in different paths.
- [Django]-TransactionManagementError "You can't execute queries until the end of the 'atomic' block" while using signals, but only during Unit Testing
- [Django]-Django models: Only permit one entry in a model?
- [Django]-Django Rest Framework File Upload