<h2 id="using-cache-with-apiview-and-viewsets"><a class="toclink" href="#using-cache-with-apiview-and-viewsets">Using cache with apiview and viewsets</a></h2>

<p>Django provides a <a href="https://docs.djangoproject.com/en/dev/topics/class-based-views/intro/#decorating-the-class"><code>method_decorator</code></a> to use

decorators with class based views. This can be used with

<a href="https://docs.djangoproject.com/en/dev/topics/http/decorators/#django.views.decorators.vary.vary_on_cookie"><code>vary_on_cookie</code></a>.</p>

<pre><code class="python">from rest_framework.response import Response

from rest_framework.views import APIView

<h2 id="booleanfield"><a class="toclink" href="#booleanfield">BooleanField</a></h2>

<p>A boolean representation.</p>

<p>When using HTML encoded form input be aware that omitting a value will always be treated as setting a field to <code>False</code>, even if it has a <code>default=True</code> option specified. This is because HTML checkbox inputs represent the unchecked state by omitting the value, so REST framework treats omission as if it is an empty checkbox input.</p>

<p>Corresponds to <code>django.db.models.fields.BooleanField</code>.</p>

<p><strong>Signature:</strong> <code>BooleanField()</code></p>

<h2 id="nullbooleanfield"><a class="toclink" href="#nullbooleanfield">NullBooleanField</a></h2>

"""

model = Product

serializer_class = ProductSerializer

def get_queryset(self):

user = self.request.user

...

filter_backends = (DjangoFilterBackend,)

<pre><code>class ProductList(generics.ListAPIView):

queryset = Product.objects.all()

serializer_class = ProductSerializer

filter_backends = (DjangoFilterBackend,)

<p>This will automatically create a <code>FilterSet</code> class for the given fields, and will allow you to make requests such as:</p>

<pre><code>http://example.com/api/products?category=clothing&amp;in_stock=True

<pre><code>search_fields = ('=username', '=email')

<p>By default, the search parameter is named <code>'search</code>', but this may be overridden with the <code>SEARCH_PARAM</code> setting.</p>

<p>For more details, see the <a href="https://docs.djangoproject.com/en/stable/ref/contrib/admin/#django.contrib.admin.ModelAdmin.search_fields">Django documentation</a>.</p>

<hr />

<h2 id="orderingfilter"><a class="toclink" href="#orderingfilter">OrderingFilter</a></h2>

<h2 id="drf-proxy-pagination"><a class="toclink" href="#drf-proxy-pagination">drf-proxy-pagination</a></h2>

<p>The <a href="https://github.com/tuffnatty/drf-proxy-pagination"><code>drf-proxy-pagination</code> package</a> includes a <code>ProxyPagination</code> class which allows to choose pagination class with a query parameter.</p>

<h2 id="link-header-pagination"><a class="toclink" href="#link-header-pagination">link-header-pagination</a></h2>

</div> <!--/span-->

</li>

<li>

</li>

<li>

<p>Together with <a href="../authentication/">authentication</a> and <a href="../throttling/">throttling</a>, permissions determine whether a request should be granted or denied access.</p>

<p>Permission checks are always run at the very start of the view, before any other code is allowed to proceed. Permission checks will typically use the authentication information in the <code>request.user</code> and <code>request.auth</code> properties to determine if the incoming request should be permitted.</p>

<p>A slightly less strict style of permission would be to allow full access to authenticated users, but allow read-only access to unauthenticated users. This corresponds to the <code>IsAuthenticatedOrReadOnly</code> class in REST framework.</p>

<h2 id="how-permissions-are-determined"><a class="toclink" href="#how-permissions-are-determined">How permissions are determined</a></h2>

<p>Permissions in REST framework are always defined as a list of permission classes.</p>

self.check_object_permissions(self.request, obj)

return obj

<h4 id="limitations-of-object-level-permissions"><a class="toclink" href="#limitations-of-object-level-permissions">Limitations of object level permissions</a></h4>

<p>For performance reasons the generic views will not automatically apply object level permissions to each instance in a queryset when returning a list of objects.</p>

<p>Often when you're using object level permissions you'll also want to <a href="../filtering/">filter the queryset</a> appropriately, to ensure that users only have visibility onto instances that they are permitted to view.</p>

}

return Response(content)

<hr />

<h1 id="api-reference"><a class="toclink" href="#api-reference">API Reference</a></h1>

<h2 id="allowany"><a class="toclink" href="#allowany">AllowAny</a></h2>

<p>The <a href="https://github.com/Helioscene/dry-rest-permissions">DRY Rest Permissions</a> package provides the ability to define different permissions for individual default and custom actions. This package is made for apps with permissions that are derived from relationships defined in the app's data model. It also supports permission checks being returned to a client app through the API's serializer. Additionally it supports adding permissions to the default and custom list actions to restrict the data they retrieve per user.</p>

<h2 id="django-rest-framework-roles"><a class="toclink" href="#django-rest-framework-roles">Django Rest Framework Roles</a></h2>

<p>The <a href="https://github.com/computer-lab/django-rest-framework-roles">Django Rest Framework Roles</a> package makes it easier to parameterize your API over multiple types of users.</p>

<h2 id="django-rest-framework-role-filters"><a class="toclink" href="#django-rest-framework-role-filters">Django Rest Framework Role Filters</a></h2>

<p>The <a href="https://github.com/allisson/django-rest-framework-role-filters">Django Rest Framework Role Filters</a> package provides simple filtering over multiple types of roles.</p>

unique_together = ('album', 'order')

ordering = ['order']

return '%d: %s' % (self.order, self.title)

<h2 id="stringrelatedfield"><a class="toclink" href="#stringrelatedfield">StringRelatedField</a></h2>

<p>For example, the following serializer.</p>

<pre><code>class AlbumSerializer(serializers.ModelSerializer):

tracks = serializers.StringRelatedField(many=True)

object_id = models.PositiveIntegerField()

tagged_object = GenericForeignKey('content_type', 'object_id')

return self.tag_name

<p>And the following two models, which may have associated tags:</p>

<h1 id="content-negotiation"><a class="toclink" href="#content-negotiation">Content negotiation</a></h1>

<p>The request exposes some properties that allow you to determine the result of the content negotiation stage. This allows you to implement behaviour such as selecting a different serialisation schemes for different media types.</p>

<h2 id="accepted_renderer"><a class="toclink" href="#accepted_renderer">.accepted_renderer</a></h2>

<h2 id="accepted_media_type"><a class="toclink" href="#accepted_media_type">.accepted_media_type</a></h2>

<p>A string representing the media type that was accepted by the content negotiation stage.</p>

<hr />

serializer.is_valid()

# False

serializer.errors

<p>Each key in the dictionary will be the field name, and the values will be lists of strings of any error messages corresponding to that field. The <code>non_field_errors</code> key may also be present, and will list any general validation errors. The name of the <code>non_field_errors</code> key may be customized using the <code>NON_FIELD_ERRORS_KEY</code> REST framework setting.</p>

<p>When deserializing a list of items, errors will be returned as a list of dictionaries representing each of the deserialized items.</p>

<h2 id="partial-updates"><a class="toclink" href="#partial-updates">Partial updates</a></h2>

<p>By default, serializers must be passed values for all required fields or they will raise validation errors. You can use the <code>partial</code> argument in order to allow partial updates.</p>

<pre><code># Update `comment` with partial data

<h2 id="dealing-with-nested-objects"><a class="toclink" href="#dealing-with-nested-objects">Dealing with nested objects</a></h2>

<p>The previous examples are fine for dealing with objects that only have simple datatypes, but sometimes we also need to be able to represent more complex objects, where some of the attributes of an object might not be simple datatypes such as strings, dates or integers.</p>

serializer.is_valid()

# False

serializer.errors

<p>Similarly, the <code>.validated_data</code> property will include nested data structures.</p>

<h4 id="writing-create-methods-for-nested-representations"><a class="toclink" href="#writing-create-methods-for-nested-representations">Writing <code>.create()</code> methods for nested representations</a></h4>

<p>You can provide arbitrary additional context by passing a <code>context</code> argument when instantiating the serializer. For example:</p>

<pre><code>serializer = AccountSerializer(account, context={'request': request})

serializer.data

<p>The context dictionary can be used within any serializer field logic, such as a custom <code>.to_representation()</code> method, by accessing the <code>self.context</code> attribute.</p>

<hr />

&gt;&gt;&gt; model = User

&gt;&gt;&gt; fields = ('id', 'username', 'email')

&gt;&gt;&gt;

{'id': 2, 'username': 'jonwatts', 'email': 'jon@example.com'}

&gt;&gt;&gt;

{'id': 2, 'email': 'jon@example.com'}

<h2 id="customizing-the-default-fields"><a class="toclink" href="#customizing-the-default-fields">Customizing the default fields</a></h2>