Returns an object instance that should be used for detail views. To get more information about n+1 problem and use cases of the mentioned methods refer to related section in django documentation. Note: If the serializer_class used in the generic view spans orm relations, leading to an n+1 problem, you could optimize your queryset in this method using select_related and prefetch_related. May be overridden to provide dynamic behavior, such as returning a queryset, that is specific to the user making the request. This method should always be used rather than accessing self.queryset directly, as self.queryset gets evaluated only once, and those results are cached for all subsequent requests. Defaults to returning the queryset specified by the queryset attribute. Returns the queryset that should be used for list views, and that should be used as the base for lookups in detail views. Defaults to the same value as the DEFAULT_FILTER_BACKENDS setting. filter_backends - A list of filter backend classes that should be used for filtering the queryset.Setting pagination_class=None will disable pagination on this view. Defaults to the same value as the DEFAULT_PAGINATION_CLASS setting, which is 'rest_'. pagination_class - The pagination class that should be used when paginating list results.The following attributes are used to control pagination when used with list views. If unset this defaults to using the same value as lookup_field. The URL conf should include a keyword argument corresponding to this value. lookup_url_kwarg - The URL keyword argument that should be used for object lookup.Note that when using hyperlinked APIs you'll need to ensure that both the API views and the serializer classes set the lookup fields if you need to use a custom value. lookup_field - The model field that should be used for performing object lookup of individual model instances.Typically, you must either set this attribute, or override the get_serializer_class() method. serializer_class - The serializer class that should be used for validating and deserializing input, and for serializing output.
If you are overriding a view method, it is important that you call get_queryset() instead of accessing this property directly, as queryset will get evaluated once, and those results will be cached for all subsequent requests. Typically, you must either set this attribute, or override the get_queryset() method. queryset - The queryset that should be used for returning objects from this view.The following attributes control the basic view behavior. This class extends REST framework's APIView class, adding commonly required behavior for standard list and detail views.Įach of the concrete generic views provided is built by combining GenericAPIView, with one or more mixin classes. For example, your URLconf might include something like the following entry: path('users/', ListCreateAPIView.as_view(queryset=(), serializer_class=UserSerializer), name='user-list') Serializer = UserSerializer(queryset, many=True)įor very simple cases you might want to pass through any class attributes using the. # Note the use of `get_queryset()` instead of `self.queryset` class UserList(generics.ListCreateAPIView): from import Userįrom rializers import UserSerializerįrom rest_framework.permissions import IsAdminUserĬlass UserList(generics.ListCreateAPIView):įor more complex cases you might also want to override various methods on the view class. Typically when using the generic views, you'll override the view, and set several class attributes. If the generic views don't suit the needs of your API, you can drop down to using the regular APIView class, or reuse the mixins and base classes used by the generic views to compose your own set of reusable generic views. The generic views provided by REST framework allow you to quickly build API views that map closely to your database models.
REST framework takes advantage of this by providing a number of pre-built views that provide for commonly used patterns. One of the key benefits of class-based views is the way they allow you to compose bits of reusable behavior. They take certain common idioms and patterns found in view development and abstract them so that you can quickly write common views of data without having to repeat yourself. were developed as a shortcut for common usage patterns.
0 kommentar(er)
