mirror of
https://github.com/encode/django-rest-framework.git
synced 2025-01-27 09:44:37 +03:00
Deployed 7ecd4f7 with MkDocs version: 0.15.3
This commit is contained in:
Tom Christie
parent
086ffa3ec7
commit
53e119d8d1
|
|
@ -654,7 +654,7 @@ TokenAdmin.raw_id_fields = ('user',)
|
|||
<li><code>request.auth</code> will be <code>None</code>.</li>
|
||||
</ul>
|
||||
<p>Unauthenticated responses that are denied permission will result in an <code>HTTP 403 Forbidden</code> response.</p>
|
||||
<p>If you're using an AJAX style API with SessionAuthentication, you'll need to make sure you include a valid CSRF token for any "unsafe" HTTP method calls, such as <code>PUT</code>, <code>PATCH</code>, <code>POST</code> or <code>DELETE</code> requests. See the <a href="https://docs.djangoproject.com/en/dev/ref/csrf/#ajax">Django CSRF documentation</a> for more details.</p>
|
||||
<p>If you're using an AJAX style API with SessionAuthentication, you'll need to make sure you include a valid CSRF token for any "unsafe" HTTP method calls, such as <code>PUT</code>, <code>PATCH</code>, <code>POST</code> or <code>DELETE</code> requests. See the <a href="https://docs.djangoproject.com/en/stable/ref/csrf/#ajax">Django CSRF documentation</a> for more details.</p>
|
||||
<p><strong>Warning</strong>: Always use Django's standard login view when creating login pages. This will ensure your login views are properly protected.</p>
|
||||
<p>CSRF validation in REST framework works slightly differently to standard Django due to the need to support both session and non-session based authentication to the same views. This means that only authenticated requests require CSRF tokens, and anonymous requests may be sent without CSRF tokens. This behaviour is not suitable for login views, which should always have CSRF validation applied.</p>
|
||||
<h1 id="custom-authentication"><a class="toclink" href="#custom-authentication">Custom authentication</a></h1>
|
||||
|
|
|
|||
|
|
@ -485,7 +485,7 @@ Content-Length: 94
|
|||
</code></pre>
|
||||
<h2 id="custom-exception-handling"><a class="toclink" href="#custom-exception-handling">Custom exception handling</a></h2>
|
||||
<p>You can implement custom exception handling by creating a handler function that converts exceptions raised in your API views into response objects. This allows you to control the style of error responses used by your API.</p>
|
||||
<p>The function must take a pair of arguments, this first is the exception to be handled, and the second is a dictionary containing any extra context such as the view currently being handled. The exception handler function should either return a <code>Response</code> object, or return <code>None</code> if the exception cannot be handled. If the handler returns <code>None</code> then the exception will be re-raised and Django will return a standard HTTP 500 'server error' response.</p>
|
||||
<p>The function must take a pair of arguments, the first is the exception to be handled, and the second is a dictionary containing any extra context such as the view currently being handled. The exception handler function should either return a <code>Response</code> object, or return <code>None</code> if the exception cannot be handled. If the handler returns <code>None</code> then the exception will be re-raised and Django will return a standard HTTP 500 'server error' response.</p>
|
||||
<p>For example, you might want to ensure that all error responses include the HTTP status code in the body of the response, like so:</p>
|
||||
<pre><code>HTTP/1.1 405 Method Not Allowed
|
||||
Content-Type: application/json
|
||||
|
|
|
|||
|
|
@ -598,7 +598,7 @@
|
|||
<h1 id="serializer-fields"><a class="toclink" href="#serializer-fields">Serializer fields</a></h1>
|
||||
<blockquote>
|
||||
<p>Each field in a Form class is responsible not only for validating data, but also for "cleaning" it — normalizing it to a consistent format.</p>
|
||||
<p>— <a href="https://docs.djangoproject.com/en/dev/ref/forms/api/#django.forms.Form.cleaned_data">Django documentation</a></p>
|
||||
<p>— <a href="https://docs.djangoproject.com/en/stable/ref/forms/api/#django.forms.Form.cleaned_data">Django documentation</a></p>
|
||||
</blockquote>
|
||||
<p>Serializer fields handle converting between primitive values and internal datatypes. They also deal with validating input values, as well as retrieving and setting the values from their parent objects.</p>
|
||||
<hr />
|
||||
|
|
@ -760,7 +760,7 @@ color_channel = serializers.ChoiceField(
|
|||
<p>Corresponds to <code>django.db.models.fields.DecimalField</code>.</p>
|
||||
<p><strong>Signature</strong>: <code>DecimalField(max_digits, decimal_places, coerce_to_string=None, max_value=None, min_value=None)</code></p>
|
||||
<ul>
|
||||
<li><code>max_digits</code> The maximum number of digits allowed in the number. Note that this number must be greater than or equal to decimal_places.</li>
|
||||
<li><code>max_digits</code> The maximum number of digits allowed in the number. It must be either <code>None</code> or an integer greater than or equal to <code>decimal_places</code>.</li>
|
||||
<li><code>decimal_places</code> The number of decimal places to store with the number.</li>
|
||||
<li><code>coerce_to_string</code> Set to <code>True</code> if string values should be returned for the representation, or <code>False</code> if <code>Decimal</code> objects should be returned. Defaults to the same value as the <code>COERCE_DECIMAL_TO_STRING</code> settings key, which will be <code>True</code> unless overridden. If <code>Decimal</code> objects are returned by the serializer, then the final output format will be determined by the renderer. Note that setting <code>localize</code> will force the value to <code>True</code>.</li>
|
||||
<li><code>max_value</code> Validate that the number provided is no greater than this value.</li>
|
||||
|
|
@ -787,7 +787,7 @@ color_channel = serializers.ChoiceField(
|
|||
<li><code>input_formats</code> - A list of strings representing the input formats which may be used to parse the date. If not specified, the <code>DATETIME_INPUT_FORMATS</code> setting will be used, which defaults to <code>['iso-8601']</code>.</li>
|
||||
</ul>
|
||||
<h4 id="datetimefield-format-strings"><a class="toclink" href="#datetimefield-format-strings"><code>DateTimeField</code> format strings.</a></h4>
|
||||
<p>Format strings may either be <a href="http://docs.python.org/2/library/datetime.html#strftime-and-strptime-behavior">Python strftime formats</a> which explicitly specify the format, or the special string <code>'iso-8601'</code>, which indicates that <a href="http://www.w3.org/TR/NOTE-datetime">ISO 8601</a> style datetimes should be used. (eg <code>'2013-01-29T12:34:56.000000Z'</code>)</p>
|
||||
<p>Format strings may either be <a href="https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior">Python strftime formats</a> which explicitly specify the format, or the special string <code>'iso-8601'</code>, which indicates that <a href="http://www.w3.org/TR/NOTE-datetime">ISO 8601</a> style datetimes should be used. (eg <code>'2013-01-29T12:34:56.000000Z'</code>)</p>
|
||||
<p>When a value of <code>None</code> is used for the format <code>datetime</code> objects will be returned by <code>to_representation</code> and the final output representation will determined by the renderer class.</p>
|
||||
<p>In the case of JSON this means the default datetime representation uses the <a href="http://ecma-international.org/ecma-262/5.1/#sec-15.9.1.15">ECMA 262 date time string specification</a>. This is a subset of ISO 8601 which uses millisecond precision, and includes the 'Z' suffix for the UTC timezone, for example: <code>2013-01-29T12:34:56.123Z</code>.</p>
|
||||
<h4 id="auto_now-and-auto_now_add-model-fields"><code>auto_now_add</code> model fields.<a class="toclink" href="#auto_now-and-auto_now_add-model-fields"><code>auto_now</code> and </a></h4>
|
||||
|
|
@ -808,7 +808,7 @@ color_channel = serializers.ChoiceField(
|
|||
<li><code>input_formats</code> - A list of strings representing the input formats which may be used to parse the date. If not specified, the <code>DATE_INPUT_FORMATS</code> setting will be used, which defaults to <code>['iso-8601']</code>.</li>
|
||||
</ul>
|
||||
<h4 id="datefield-format-strings"><a class="toclink" href="#datefield-format-strings"><code>DateField</code> format strings</a></h4>
|
||||
<p>Format strings may either be <a href="http://docs.python.org/2/library/datetime.html#strftime-and-strptime-behavior">Python strftime formats</a> which explicitly specify the format, or the special string <code>'iso-8601'</code>, which indicates that <a href="http://www.w3.org/TR/NOTE-datetime">ISO 8601</a> style dates should be used. (eg <code>'2013-01-29'</code>)</p>
|
||||
<p>Format strings may either be <a href="https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior">Python strftime formats</a> which explicitly specify the format, or the special string <code>'iso-8601'</code>, which indicates that <a href="http://www.w3.org/TR/NOTE-datetime">ISO 8601</a> style dates should be used. (eg <code>'2013-01-29'</code>)</p>
|
||||
<h2 id="timefield"><a class="toclink" href="#timefield">TimeField</a></h2>
|
||||
<p>A time representation.</p>
|
||||
<p>Corresponds to <code>django.db.models.fields.TimeField</code></p>
|
||||
|
|
@ -818,7 +818,7 @@ color_channel = serializers.ChoiceField(
|
|||
<li><code>input_formats</code> - A list of strings representing the input formats which may be used to parse the date. If not specified, the <code>TIME_INPUT_FORMATS</code> setting will be used, which defaults to <code>['iso-8601']</code>.</li>
|
||||
</ul>
|
||||
<h4 id="timefield-format-strings"><a class="toclink" href="#timefield-format-strings"><code>TimeField</code> format strings</a></h4>
|
||||
<p>Format strings may either be <a href="http://docs.python.org/2/library/datetime.html#strftime-and-strptime-behavior">Python strftime formats</a> which explicitly specify the format, or the special string <code>'iso-8601'</code>, which indicates that <a href="http://www.w3.org/TR/NOTE-datetime">ISO 8601</a> style times should be used. (eg <code>'12:34:56.000000'</code>)</p>
|
||||
<p>Format strings may either be <a href="https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior">Python strftime formats</a> which explicitly specify the format, or the special string <code>'iso-8601'</code>, which indicates that <a href="http://www.w3.org/TR/NOTE-datetime">ISO 8601</a> style times should be used. (eg <code>'12:34:56.000000'</code>)</p>
|
||||
<h2 id="durationfield"><a class="toclink" href="#durationfield">DurationField</a></h2>
|
||||
<p>A Duration representation.
|
||||
Corresponds to <code>django.db.models.fields.DurationField</code></p>
|
||||
|
|
@ -853,7 +853,7 @@ The representation is a string following this format <code>'[DD] [HH:[MM:]]ss[.u
|
|||
<h1 id="file-upload-fields"><a class="toclink" href="#file-upload-fields">File upload fields</a></h1>
|
||||
<h4 id="parsers-and-file-uploads"><a class="toclink" href="#parsers-and-file-uploads">Parsers and file uploads.</a></h4>
|
||||
<p>The <code>FileField</code> and <code>ImageField</code> classes are only suitable for use with <code>MultiPartParser</code> or <code>FileUploadParser</code>. Most parsers, such as e.g. JSON don't support file uploads.
|
||||
Django's regular <a href="https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-FILE_UPLOAD_HANDLERS">FILE_UPLOAD_HANDLERS</a> are used for handling uploaded files.</p>
|
||||
Django's regular <a href="https://docs.djangoproject.com/en/stable/ref/settings/#std:setting-FILE_UPLOAD_HANDLERS">FILE_UPLOAD_HANDLERS</a> are used for handling uploaded files.</p>
|
||||
<h2 id="filefield"><a class="toclink" href="#filefield">FileField</a></h2>
|
||||
<p>A file representation. Performs Django's standard FileField validation.</p>
|
||||
<p>Corresponds to <code>django.forms.fields.FileField</code>.</p>
|
||||
|
|
|
|||
|
|
@ -486,7 +486,7 @@
|
|||
<h1 id="filtering"><a class="toclink" href="#filtering">Filtering</a></h1>
|
||||
<blockquote>
|
||||
<p>The root QuerySet provided by the Manager describes all objects in the database table. Usually, though, you'll need to select only a subset of the complete set of objects.</p>
|
||||
<p>— <a href="https://docs.djangoproject.com/en/dev/topics/db/queries/#retrieving-specific-objects-with-filters">Django documentation</a></p>
|
||||
<p>— <a href="https://docs.djangoproject.com/en/stable/topics/db/queries/#retrieving-specific-objects-with-filters">Django documentation</a></p>
|
||||
</blockquote>
|
||||
<p>The default behavior of REST framework's generic list views is to return the entire queryset for a model manager. Often you will want your API to restrict the items that are returned by the queryset.</p>
|
||||
<p>The simplest way to filter the queryset of any view that subclasses <code>GenericAPIView</code> is to override the <code>.get_queryset()</code> method.</p>
|
||||
|
|
@ -557,7 +557,7 @@ class PurchaseList(generics.ListAPIView):
|
|||
</code></pre>
|
||||
<p>You can also set the filter backends on a per-view, or per-viewset basis,
|
||||
using the <code>GenericAPIView</code> class-based views.</p>
|
||||
<pre><code>import django_filters
|
||||
<pre><code>import django_filters.rest_framework
|
||||
from django.contrib.auth.models import User
|
||||
from myapp.serializers import UserSerializer
|
||||
from rest_framework import generics
|
||||
|
|
@ -688,7 +688,7 @@ class ProductFilter(django_filters.rest_framework.FilterSet):
|
|||
</ul>
|
||||
<hr />
|
||||
<h2 id="searchfilter"><a class="toclink" href="#searchfilter">SearchFilter</a></h2>
|
||||
<p>The <code>SearchFilter</code> class supports simple single query parameter based searching, and is based on the <a href="https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.search_fields">Django admin's search functionality</a>.</p>
|
||||
<p>The <code>SearchFilter</code> class supports simple single query parameter based searching, and is based on the <a href="https://docs.djangoproject.com/en/stable/ref/contrib/admin/#django.contrib.admin.ModelAdmin.search_fields">Django admin's search functionality</a>.</p>
|
||||
<p>When in use, the browsable API will include a <code>SearchFilter</code> control:</p>
|
||||
<p><img alt="Search Filter" src="../../img/search-filter.png" /></p>
|
||||
<p>The <code>SearchFilter</code> class will only be applied if the view has a <code>search_fields</code> attribute set. The <code>search_fields</code> attribute should be a list of names of text type fields on the model, such as <code>CharField</code> or <code>TextField</code>.</p>
|
||||
|
|
@ -716,7 +716,7 @@ class ProductFilter(django_filters.rest_framework.FilterSet):
|
|||
<pre><code>search_fields = ('=username', '=email')
|
||||
</code></pre>
|
||||
<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/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.search_fields">Django documentation</a>.</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>
|
||||
<p>The <code>OrderingFilter</code> class supports simple query parameter controlled ordering of results.</p>
|
||||
|
|
|
|||
|
|
@ -514,7 +514,7 @@
|
|||
<h1 id="generic-views"><a class="toclink" href="#generic-views">Generic views</a></h1>
|
||||
<blockquote>
|
||||
<p>Django’s generic views... were developed as a shortcut for common usage patterns... 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.</p>
|
||||
<p>— <a href="https://docs.djangoproject.com/en/dev/ref/class-based-views/#base-vs-generic-views">Django Documentation</a></p>
|
||||
<p>— <a href="https://docs.djangoproject.com/en/stable/ref/class-based-views/#base-vs-generic-views">Django Documentation</a></p>
|
||||
</blockquote>
|
||||
<p>One of the key benefits of class-based views is the way they allow you to compose bits of reusable behavior. REST framework takes advantage of this by providing a number of pre-built views that provide for commonly used patterns.</p>
|
||||
<p>The generic views provided by REST framework allow you to quickly build API views that map closely to your database models.</p>
|
||||
|
|
|
|||
|
|
@ -466,7 +466,7 @@
|
|||
<h1 id="pagination"><a class="toclink" href="#pagination">Pagination</a></h1>
|
||||
<blockquote>
|
||||
<p>Django provides a few classes that help you manage paginated data – that is, data that’s split across several pages, with “Previous/Next” links.</p>
|
||||
<p>— <a href="https://docs.djangoproject.com/en/dev/topics/pagination/">Django documentation</a></p>
|
||||
<p>— <a href="https://docs.djangoproject.com/en/stable/topics/pagination/">Django documentation</a></p>
|
||||
</blockquote>
|
||||
<p>REST framework includes support for customizable pagination styles. This allows you to modify how large result sets are split into individual pages of data.</p>
|
||||
<p>The pagination API can support either:</p>
|
||||
|
|
|
|||
|
|
@ -537,7 +537,7 @@ def example_view(request, format=None):
|
|||
<ul>
|
||||
<li>The <code>FileUploadParser</code> is for usage with native clients that can upload the file as a raw data request. For web-based uploads, or for native clients with multipart upload support, you should use the <code>MultiPartParser</code> parser instead.</li>
|
||||
<li>Since this parser's <code>media_type</code> matches any content type, <code>FileUploadParser</code> should generally be the only parser set on an API view.</li>
|
||||
<li><code>FileUploadParser</code> respects Django's standard <code>FILE_UPLOAD_HANDLERS</code> setting, and the <code>request.upload_handlers</code> attribute. See the <a href="https://docs.djangoproject.com/en/dev/topics/http/file-uploads/#upload-handlers">Django documentation</a> for more details.</li>
|
||||
<li><code>FileUploadParser</code> respects Django's standard <code>FILE_UPLOAD_HANDLERS</code> setting, and the <code>request.upload_handlers</code> attribute. See the <a href="https://docs.djangoproject.com/en/stable/topics/http/file-uploads/#upload-handlers">Django documentation</a> for more details.</li>
|
||||
</ul>
|
||||
<h5 id="basic-usage-example"><a class="toclink" href="#basic-usage-example">Basic usage example:</a></h5>
|
||||
<pre><code># views.py
|
||||
|
|
|
|||
|
|
@ -562,7 +562,7 @@ def example_view(request, format=None):
|
|||
<p>The <code>IsAuthenticatedOrReadOnly</code> will allow authenticated users to perform any request. Requests for unauthorised users will only be permitted if the request method is one of the "safe" methods; <code>GET</code>, <code>HEAD</code> or <code>OPTIONS</code>.</p>
|
||||
<p>This permission is suitable if you want to your API to allow read permissions to anonymous users, and only allow write permissions to authenticated users.</p>
|
||||
<h2 id="djangomodelpermissions"><a class="toclink" href="#djangomodelpermissions">DjangoModelPermissions</a></h2>
|
||||
<p>This permission class ties into Django's standard <code>django.contrib.auth</code> <a href="https://docs.djangoproject.com/en/dev/topics/auth/customizing/#custom-permissions">model permissions</a>. This permission must only be applied to views that have a <code>.queryset</code> property set. Authorization will only be granted if the user <em>is authenticated</em> and has the <em>relevant model permissions</em> assigned.</p>
|
||||
<p>This permission class ties into Django's standard <code>django.contrib.auth</code> <a href="https://docs.djangoproject.com/en/stable/topics/auth/customizing/#custom-permissions">model permissions</a>. This permission must only be applied to views that have a <code>.queryset</code> property set. Authorization will only be granted if the user <em>is authenticated</em> and has the <em>relevant model permissions</em> assigned.</p>
|
||||
<ul>
|
||||
<li><code>POST</code> requests require the user to have the <code>add</code> permission on the model.</li>
|
||||
<li><code>PUT</code> and <code>PATCH</code> requests require the user to have the <code>change</code> permission on the model.</li>
|
||||
|
|
@ -577,7 +577,7 @@ def example_view(request, format=None):
|
|||
<h2 id="djangomodelpermissionsoranonreadonly"><a class="toclink" href="#djangomodelpermissionsoranonreadonly">DjangoModelPermissionsOrAnonReadOnly</a></h2>
|
||||
<p>Similar to <code>DjangoModelPermissions</code>, but also allows unauthenticated users to have read-only access to the API.</p>
|
||||
<h2 id="djangoobjectpermissions"><a class="toclink" href="#djangoobjectpermissions">DjangoObjectPermissions</a></h2>
|
||||
<p>This permission class ties into Django's standard <a href="https://docs.djangoproject.com/en/dev/topics/auth/customizing/#handling-object-permissions">object permissions framework</a> that allows per-object permissions on models. In order to use this permission class, you'll also need to add a permission backend that supports object-level permissions, such as <a href="https://github.com/lukaszb/django-guardian">django-guardian</a>.</p>
|
||||
<p>This permission class ties into Django's standard <a href="https://docs.djangoproject.com/en/stable/topics/auth/customizing/#handling-object-permissions">object permissions framework</a> that allows per-object permissions on models. In order to use this permission class, you'll also need to add a permission backend that supports object-level permissions, such as <a href="https://github.com/lukaszb/django-guardian">django-guardian</a>.</p>
|
||||
<p>As with <code>DjangoModelPermissions</code>, this permission must only be applied to views that have a <code>.queryset</code> property or <code>.get_queryset()</code> method. Authorization will only be granted if the user <em>is authenticated</em> and has the <em>relevant per-object permissions</em> and <em>relevant model permissions</em> assigned.</p>
|
||||
<ul>
|
||||
<li><code>POST</code> requests require the user to have the <code>add</code> permission on the model instance.</li>
|
||||
|
|
@ -585,7 +585,7 @@ def example_view(request, format=None):
|
|||
<li><code>DELETE</code> requests require the user to have the <code>delete</code> permission on the model instance.</li>
|
||||
</ul>
|
||||
<p>Note that <code>DjangoObjectPermissions</code> <strong>does not</strong> require the <code>django-guardian</code> package, and should support other object-level backends equally well.</p>
|
||||
<p>As with <code>DjangoModelPermissions</code> you can use custom model permissions by overriding <code>DjangoModelPermissions</code> and setting the <code>.perms_map</code> property. Refer to the source code for details.</p>
|
||||
<p>As with <code>DjangoModelPermissions</code> you can use custom model permissions by overriding <code>DjangoObjectPermissions</code> and setting the <code>.perms_map</code> property. Refer to the source code for details.</p>
|
||||
<hr />
|
||||
<p><strong>Note</strong>: If you need object level <code>view</code> permissions for <code>GET</code>, <code>HEAD</code> and <code>OPTIONS</code> requests, you'll want to consider also adding the <code>DjangoObjectPermissionsFilter</code> class to ensure that list endpoints only return results including objects for which the user has appropriate view permissions.</p>
|
||||
<hr />
|
||||
|
|
|
|||
|
|
@ -896,7 +896,7 @@ class CustomerHyperlink(serializers.HyperlinkedRelatedField):
|
|||
class Meta:
|
||||
fields = ('track_set', ...)
|
||||
</code></pre>
|
||||
<p>See the Django documentation on <a href="https://docs.djangoproject.com/en/dev/topics/db/queries/#following-relationships-backward">reverse relationships</a> for more details.</p>
|
||||
<p>See the Django documentation on <a href="https://docs.djangoproject.com/en/stable/topics/db/queries/#following-relationships-backward">reverse relationships</a> for more details.</p>
|
||||
<h2 id="generic-relationships"><a class="toclink" href="#generic-relationships">Generic relationships</a></h2>
|
||||
<p>If you want to serialize a generic foreign key, you need to define a custom field, to determine explicitly how you want to serialize the targets of the relationship.</p>
|
||||
<p>For example, given the following model for a tag, which has a generic relationship with other arbitrary models:</p>
|
||||
|
|
@ -904,7 +904,7 @@ class CustomerHyperlink(serializers.HyperlinkedRelatedField):
|
|||
"""
|
||||
Tags arbitrary model instances using a generic relation.
|
||||
|
||||
See: https://docs.djangoproject.com/en/dev/ref/contrib/contenttypes/
|
||||
See: https://docs.djangoproject.com/en/stable/ref/contrib/contenttypes/
|
||||
"""
|
||||
tag_name = models.SlugField()
|
||||
content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)
|
||||
|
|
@ -962,7 +962,7 @@ class Note(models.Model):
|
|||
return serializer.data
|
||||
</code></pre>
|
||||
<p>Note that reverse generic keys, expressed using the <code>GenericRelation</code> field, can be serialized using the regular relational field types, since the type of the target in the relationship is always known.</p>
|
||||
<p>For more information see <a href="https://docs.djangoproject.com/en/dev/ref/contrib/contenttypes/#id1">the Django documentation on generic relations</a>.</p>
|
||||
<p>For more information see <a href="https://docs.djangoproject.com/en/stable/ref/contrib/contenttypes/#id1">the Django documentation on generic relations</a>.</p>
|
||||
<h2 id="manytomanyfields-with-a-through-model"><a class="toclink" href="#manytomanyfields-with-a-through-model">ManyToManyFields with a Through Model</a></h2>
|
||||
<p>By default, relational fields that target a <code>ManyToManyField</code> with a
|
||||
<code>through</code> model specified are set to read-only.</p>
|
||||
|
|
|
|||
|
|
@ -530,7 +530,7 @@
|
|||
<h1 id="renderers"><a class="toclink" href="#renderers">Renderers</a></h1>
|
||||
<blockquote>
|
||||
<p>Before a TemplateResponse instance can be returned to the client, it must be rendered. The rendering process takes the intermediate representation of template and context, and turns it into the final byte stream that can be served to the client.</p>
|
||||
<p>— <a href="https://docs.djangoproject.com/en/dev/ref/template-response/#the-rendering-process">Django documentation</a></p>
|
||||
<p>— <a href="https://docs.djangoproject.com/en/stable/stable/template-response/#the-rendering-process">Django documentation</a></p>
|
||||
</blockquote>
|
||||
<p>REST framework includes a number of built in Renderer classes, that allow you to return responses with various media types. There is also support for defining your own custom renderers, which gives you the flexibility to design your own media types.</p>
|
||||
<h2 id="how-the-renderer-is-determined"><a class="toclink" href="#how-the-renderer-is-determined">How the renderer is determined</a></h2>
|
||||
|
|
@ -620,6 +620,7 @@ Unlike other renderers, the data passed to the <code>Response</code> does not ne
|
|||
</code></pre>
|
||||
<p>You can use <code>TemplateHTMLRenderer</code> either to return regular HTML pages using REST framework, or to return both HTML and API responses from a single endpoint.</p>
|
||||
<p>If you're building websites that use <code>TemplateHTMLRenderer</code> along with other renderer classes, you should consider listing <code>TemplateHTMLRenderer</code> as the first class in the <code>renderer_classes</code> list, so that it will be prioritised first even for browsers that send poorly formed <code>ACCEPT:</code> headers.</p>
|
||||
<p>See the <a href="../../topics/html-and-forms/"><em>HTML & Forms</em> Topic Page</a> for further examples of <code>TemplateHTMLRenderer</code> usage.</p>
|
||||
<p><strong>.media_type</strong>: <code>text/html</code></p>
|
||||
<p><strong>.format</strong>: <code>'.html'</code></p>
|
||||
<p><strong>.charset</strong>: <code>utf-8</code></p>
|
||||
|
|
@ -782,7 +783,7 @@ In this case you can underspecify the media types it should respond to, by using
|
|||
<p>For good examples of custom media types, see GitHub's use of a custom <a href="http://developer.github.com/v3/media/">application/vnd.github+json</a> media type, and Mike Amundsen's IANA approved <a href="http://www.amundsen.com/media-types/collection/">application/vnd.collection+json</a> JSON-based hypermedia.</p>
|
||||
<h2 id="html-error-views"><a class="toclink" href="#html-error-views">HTML error views</a></h2>
|
||||
<p>Typically a renderer will behave the same regardless of if it's dealing with a regular response, or with a response caused by an exception being raised, such as an <code>Http404</code> or <code>PermissionDenied</code> exception, or a subclass of <code>APIException</code>.</p>
|
||||
<p>If you're using either the <code>TemplateHTMLRenderer</code> or the <code>StaticHTMLRenderer</code> and an exception is raised, the behavior is slightly different, and mirrors <a href="https://docs.djangoproject.com/en/dev/topics/http/views/#customizing-error-views">Django's default handling of error views</a>.</p>
|
||||
<p>If you're using either the <code>TemplateHTMLRenderer</code> or the <code>StaticHTMLRenderer</code> and an exception is raised, the behavior is slightly different, and mirrors <a href="https://docs.djangoproject.com/en/stable/topics/http/views/#customizing-error-views">Django's default handling of error views</a>.</p>
|
||||
<p>Exceptions raised and handled by an HTML renderer will attempt to render using one of the following methods, by order of precedence.</p>
|
||||
<ul>
|
||||
<li>Load and render a template named <code>{status_code}.html</code>.</li>
|
||||
|
|
|
|||
|
|
@ -448,7 +448,7 @@
|
|||
<h1 id="responses"><a class="toclink" href="#responses">Responses</a></h1>
|
||||
<blockquote>
|
||||
<p>Unlike basic HttpResponse objects, TemplateResponse objects retain the details of the context that was provided by the view to compute the response. The final output of the response is not computed until it is needed, later in the response process.</p>
|
||||
<p>— <a href="https://docs.djangoproject.com/en/dev/ref/template-response/">Django documentation</a></p>
|
||||
<p>— <a href="https://docs.djangoproject.com/en/stable/stable/template-response/">Django documentation</a></p>
|
||||
</blockquote>
|
||||
<p>REST framework supports HTTP content negotiation by providing a <code>Response</code> class which allows you to return content that can be rendered into multiple content types, depending on the client request.</p>
|
||||
<p>The <code>Response</code> class subclasses Django's <code>SimpleTemplateResponse</code>. <code>Response</code> objects are initialised with data, which should consist of native Python primitives. REST framework then uses standard HTTP content negotiation to determine how it should render the final response content.</p>
|
||||
|
|
|
|||
|
|
@ -416,7 +416,7 @@
|
|||
<p>There's no requirement for you to use them, but if you do then the self-describing API will be able to automatically hyperlink its output for you, which makes browsing the API much easier.</p>
|
||||
<h2 id="reverse"><a class="toclink" href="#reverse">reverse</a></h2>
|
||||
<p><strong>Signature:</strong> <code>reverse(viewname, *args, **kwargs)</code></p>
|
||||
<p>Has the same behavior as <a href="https://docs.djangoproject.com/en/dev/topics/http/urls/#reverse"><code>django.urls.reverse</code></a>, except that it returns a fully qualified URL, using the request to determine the host and port.</p>
|
||||
<p>Has the same behavior as <a href="https://docs.djangoproject.com/en/stable/topics/http/urls/#reverse"><code>django.urls.reverse</code></a>, except that it returns a fully qualified URL, using the request to determine the host and port.</p>
|
||||
<p>You should <strong>include the request as a keyword argument</strong> to the function, for example:</p>
|
||||
<pre><code>from rest_framework.reverse import reverse
|
||||
from rest_framework.views import APIView
|
||||
|
|
@ -433,7 +433,7 @@ class APIRootView(APIView):
|
|||
</code></pre>
|
||||
<h2 id="reverse_lazy"><a class="toclink" href="#reverse_lazy">reverse_lazy</a></h2>
|
||||
<p><strong>Signature:</strong> <code>reverse_lazy(viewname, *args, **kwargs)</code></p>
|
||||
<p>Has the same behavior as <a href="https://docs.djangoproject.com/en/dev/topics/http/urls/#reverse-lazy"><code>django.urls.reverse_lazy</code></a>, except that it returns a fully qualified URL, using the request to determine the host and port.</p>
|
||||
<p>Has the same behavior as <a href="https://docs.djangoproject.com/en/stable/topics/http/urls/#reverse-lazy"><code>django.urls.reverse_lazy</code></a>, except that it returns a fully qualified URL, using the request to determine the host and port.</p>
|
||||
<p>As with the <code>reverse</code> function, you should <strong>include the request as a keyword argument</strong> to the function, for example:</p>
|
||||
<pre><code>api_root = reverse_lazy('api-root', request=request)
|
||||
</code></pre>
|
||||
|
|
|
|||
|
|
@ -654,7 +654,7 @@ def schema_view(request):
|
|||
of the available formats, such as Core JSON or Open API.</p>
|
||||
<p>You could then either:</p>
|
||||
<ul>
|
||||
<li>Write a schema definition as a static file, and <a href="https://docs.djangoproject.com/en/dev/howto/static-files/">serve the static file directly</a>.</li>
|
||||
<li>Write a schema definition as a static file, and <a href="https://docs.djangoproject.com/en/stable/howto/static-files/">serve the static file directly</a>.</li>
|
||||
<li>Write a schema definition that is loaded using <code>Core API</code>, and then
|
||||
rendered to one of many available formats, depending on the client request.</li>
|
||||
</ul>
|
||||
|
|
@ -831,7 +831,7 @@ the parameter can be omitted.</p>
|
|||
the following strings:</p>
|
||||
<p><strong>"path"</strong></p>
|
||||
<p>Included in a templated URI. For example a <code>url</code> value of <code>/products/{product_code}/</code> could be used together with a <code>"path"</code> field, to handle API inputs in a URL path such as <code>/products/slim-fit-jeans/</code>.</p>
|
||||
<p>These fields will normally correspond with <a href="https://docs.djangoproject.com/en/dev/topics/http/urls/#named-groups">named arguments in the project URL conf</a>.</p>
|
||||
<p>These fields will normally correspond with <a href="https://docs.djangoproject.com/en/stable/topics/http/urls/#named-groups">named arguments in the project URL conf</a>.</p>
|
||||
<p><strong>"query"</strong></p>
|
||||
<p>Included as a URL query parameter. For example <code>?search=sale</code>. Typically for <code>GET</code> requests.</p>
|
||||
<p>These fields will normally correspond with pagination and filtering controls on a view.</p>
|
||||
|
|
|
|||
|
|
@ -895,7 +895,7 @@ serializer.errors
|
|||
has_support_contract=validated_data['profile']['has_support_contract']
|
||||
)
|
||||
</code></pre>
|
||||
<p>For more details on this approach see the Django documentation on <a href="https://docs.djangoproject.com/en/dev/topics/db/managers/">model managers</a>, and <a href="http://www.dabapps.com/blog/django-models-and-encapsulation/">this blogpost on using model and manager classes</a>.</p>
|
||||
<p>For more details on this approach see the Django documentation on <a href="https://docs.djangoproject.com/en/stable/topics/db/managers/">model managers</a>, and <a href="http://www.dabapps.com/blog/django-models-and-encapsulation/">this blogpost on using model and manager classes</a>.</p>
|
||||
<h2 id="dealing-with-multiple-objects"><a class="toclink" href="#dealing-with-multiple-objects">Dealing with multiple objects</a></h2>
|
||||
<p>The <code>Serializer</code> class can also handle serializing or deserializing lists of objects.</p>
|
||||
<h4 id="serializing-multiple-objects"><a class="toclink" href="#serializing-multiple-objects">Serializing multiple objects</a></h4>
|
||||
|
|
|
|||
|
|
@ -452,7 +452,7 @@
|
|||
<h1 id="settings"><a class="toclink" href="#settings">Settings</a></h1>
|
||||
<blockquote>
|
||||
<p>Namespaces are one honking great idea - let's do more of those!</p>
|
||||
<p>— <a href="http://www.python.org/dev/peps/pep-0020/">The Zen of Python</a></p>
|
||||
<p>— <a href="https://www.python.org/dev/peps/pep-0020/">The Zen of Python</a></p>
|
||||
</blockquote>
|
||||
<p>Configuration for REST framework is all namespaced inside a single Django setting, named <code>REST_FRAMEWORK</code>.</p>
|
||||
<p>For example your project's <code>settings.py</code> file might include something like this:</p>
|
||||
|
|
@ -618,27 +618,27 @@ internally in the codebase.</p>
|
|||
<p><em>The following settings are used to control how date and time representations may be parsed and rendered.</em></p>
|
||||
<h4 id="datetime_format"><a class="toclink" href="#datetime_format">DATETIME_FORMAT</a></h4>
|
||||
<p>A format string that should be used by default for rendering the output of <code>DateTimeField</code> serializer fields. If <code>None</code>, then <code>DateTimeField</code> serializer fields will return Python <code>datetime</code> objects, and the datetime encoding will be determined by the renderer.</p>
|
||||
<p>May be any of <code>None</code>, <code>'iso-8601'</code> or a Python <a href="http://docs.python.org/2/library/time.html#time.strftime">strftime format</a> string.</p>
|
||||
<p>May be any of <code>None</code>, <code>'iso-8601'</code> or a Python <a href="https://docs.python.org/3/library/time.html#time.strftime">strftime format</a> string.</p>
|
||||
<p>Default: <code>'iso-8601'</code></p>
|
||||
<h4 id="datetime_input_formats"><a class="toclink" href="#datetime_input_formats">DATETIME_INPUT_FORMATS</a></h4>
|
||||
<p>A list of format strings that should be used by default for parsing inputs to <code>DateTimeField</code> serializer fields.</p>
|
||||
<p>May be a list including the string <code>'iso-8601'</code> or Python <a href="http://docs.python.org/2/library/time.html#time.strftime">strftime format</a> strings.</p>
|
||||
<p>May be a list including the string <code>'iso-8601'</code> or Python <a href="https://docs.python.org/3/library/time.html#time.strftime">strftime format</a> strings.</p>
|
||||
<p>Default: <code>['iso-8601']</code></p>
|
||||
<h4 id="date_format"><a class="toclink" href="#date_format">DATE_FORMAT</a></h4>
|
||||
<p>A format string that should be used by default for rendering the output of <code>DateField</code> serializer fields. If <code>None</code>, then <code>DateField</code> serializer fields will return Python <code>date</code> objects, and the date encoding will be determined by the renderer.</p>
|
||||
<p>May be any of <code>None</code>, <code>'iso-8601'</code> or a Python <a href="http://docs.python.org/2/library/time.html#time.strftime">strftime format</a> string.</p>
|
||||
<p>May be any of <code>None</code>, <code>'iso-8601'</code> or a Python <a href="https://docs.python.org/3/library/time.html#time.strftime">strftime format</a> string.</p>
|
||||
<p>Default: <code>'iso-8601'</code></p>
|
||||
<h4 id="date_input_formats"><a class="toclink" href="#date_input_formats">DATE_INPUT_FORMATS</a></h4>
|
||||
<p>A list of format strings that should be used by default for parsing inputs to <code>DateField</code> serializer fields.</p>
|
||||
<p>May be a list including the string <code>'iso-8601'</code> or Python <a href="http://docs.python.org/2/library/time.html#time.strftime">strftime format</a> strings.</p>
|
||||
<p>May be a list including the string <code>'iso-8601'</code> or Python <a href="https://docs.python.org/3/library/time.html#time.strftime">strftime format</a> strings.</p>
|
||||
<p>Default: <code>['iso-8601']</code></p>
|
||||
<h4 id="time_format"><a class="toclink" href="#time_format">TIME_FORMAT</a></h4>
|
||||
<p>A format string that should be used by default for rendering the output of <code>TimeField</code> serializer fields. If <code>None</code>, then <code>TimeField</code> serializer fields will return Python <code>time</code> objects, and the time encoding will be determined by the renderer.</p>
|
||||
<p>May be any of <code>None</code>, <code>'iso-8601'</code> or a Python <a href="http://docs.python.org/2/library/time.html#time.strftime">strftime format</a> string.</p>
|
||||
<p>May be any of <code>None</code>, <code>'iso-8601'</code> or a Python <a href="https://docs.python.org/3/library/time.html#time.strftime">strftime format</a> string.</p>
|
||||
<p>Default: <code>'iso-8601'</code></p>
|
||||
<h4 id="time_input_formats"><a class="toclink" href="#time_input_formats">TIME_INPUT_FORMATS</a></h4>
|
||||
<p>A list of format strings that should be used by default for parsing inputs to <code>TimeField</code> serializer fields.</p>
|
||||
<p>May be a list including the string <code>'iso-8601'</code> or Python <a href="http://docs.python.org/2/library/time.html#time.strftime">strftime format</a> strings.</p>
|
||||
<p>May be a list including the string <code>'iso-8601'</code> or Python <a href="https://docs.python.org/3/library/time.html#time.strftime">strftime format</a> strings.</p>
|
||||
<p>Default: <code>['iso-8601']</code></p>
|
||||
<hr />
|
||||
<h2 id="encodings"><a class="toclink" href="#encodings">Encodings</a></h2>
|
||||
|
|
|
|||
|
|
@ -412,6 +412,10 @@
|
|||
</li>
|
||||
|
||||
|
||||
<li>
|
||||
<a href="#requestsclient-and-working-with-the-database">RequestsClient and working with the database</a>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<a href="#headers-authentication">Headers & Authentication</a>
|
||||
</li>
|
||||
|
|
@ -500,7 +504,7 @@
|
|||
</blockquote>
|
||||
<p>REST framework includes a few helper classes that extend Django's existing test framework, and improve support for making API requests.</p>
|
||||
<h1 id="apirequestfactory"><a class="toclink" href="#apirequestfactory">APIRequestFactory</a></h1>
|
||||
<p>Extends <a href="https://docs.djangoproject.com/en/dev/topics/testing/advanced/#django.test.client.RequestFactory">Django's existing <code>RequestFactory</code> class</a>.</p>
|
||||
<p>Extends <a href="https://docs.djangoproject.com/en/stable/topics/testing/advanced/#django.test.client.RequestFactory">Django's existing <code>RequestFactory</code> class</a>.</p>
|
||||
<h2 id="creating-test-requests"><a class="toclink" href="#creating-test-requests">Creating test requests</a></h2>
|
||||
<p>The <code>APIRequestFactory</code> class supports an almost identical API to Django's standard <code>RequestFactory</code> class. This means that the standard <code>.get()</code>, <code>.post()</code>, <code>.put()</code>, <code>.patch()</code>, <code>.delete()</code>, <code>.head()</code> and <code>.options()</code> methods are all available.</p>
|
||||
<pre><code>from rest_framework.test import APIRequestFactory
|
||||
|
|
@ -573,7 +577,7 @@ response = view(request)
|
|||
<p><strong>Note</strong>: It's worth noting that Django's standard <code>RequestFactory</code> doesn't need to include this option, because when using regular Django the CSRF validation takes place in middleware, which is not run when testing views directly. When using REST framework, CSRF validation takes place inside the view, so the request factory needs to disable view-level CSRF checks.</p>
|
||||
<hr />
|
||||
<h1 id="apiclient"><a class="toclink" href="#apiclient">APIClient</a></h1>
|
||||
<p>Extends <a href="https://docs.djangoproject.com/en/dev/topics/testing/tools/#the-test-client">Django's existing <code>Client</code> class</a>.</p>
|
||||
<p>Extends <a href="https://docs.djangoproject.com/en/stable/topics/testing/tools/#the-test-client">Django's existing <code>Client</code> class</a>.</p>
|
||||
<h2 id="making-requests"><a class="toclink" href="#making-requests">Making requests</a></h2>
|
||||
<p>The <code>APIClient</code> class supports the same request interface as Django's standard <code>Client</code> class. This means the that standard <code>.get()</code>, <code>.post()</code>, <code>.put()</code>, <code>.patch()</code>, <code>.delete()</code>, <code>.head()</code> and <code>.options()</code> methods are all available. For example:</p>
|
||||
<pre><code>from rest_framework.test import APIClient
|
||||
|
|
@ -627,7 +631,13 @@ client.force_authenticate(user=user)
|
|||
<hr />
|
||||
<h1 id="requestsclient"><a class="toclink" href="#requestsclient">RequestsClient</a></h1>
|
||||
<p>REST framework also includes a client for interacting with your application
|
||||
using the popular Python library, <code>requests</code>.</p>
|
||||
using the popular Python library, <code>requests</code>. This may be useful if:</p>
|
||||
<ul>
|
||||
<li>You are expecting to interface with the API primarily from another Python service,
|
||||
and want to test the service at the same level as the client will see.</li>
|
||||
<li>You want to write tests in such a way that they can also be run against a staging or
|
||||
live environment. (See "Live tests" below.)</li>
|
||||
</ul>
|
||||
<p>This exposes exactly the same interface as if you were using a requests session
|
||||
directly.</p>
|
||||
<pre><code>client = RequestsClient()
|
||||
|
|
@ -635,6 +645,8 @@ response = client.get('http://testserver/users/')
|
|||
assert response.status_code == 200
|
||||
</code></pre>
|
||||
<p>Note that the requests client requires you to pass fully qualified URLs.</p>
|
||||
<h2 id="requestsclient-and-working-with-the-database"><a class="toclink" href="#requestsclient-and-working-with-the-database"><code>RequestsClient</code> and working with the database</a></h2>
|
||||
<p>The <code>RequestsClient</code> class is useful if</p>
|
||||
<h2 id="headers-authentication"><a class="toclink" href="#headers-authentication">Headers & Authentication</a></h2>
|
||||
<p>Custom headers and authentication credentials can be provided in the same way
|
||||
as <a href="http://docs.python-requests.org/en/master/user/advanced/#session-objects">when using a standard <code>requests.Session</code> instance</a>.</p>
|
||||
|
|
|
|||
|
|
@ -493,7 +493,7 @@ def example_view(request, format=None):
|
|||
<p>It is important to understand that if you configure the <code>NUM_PROXIES</code> setting, then all clients behind a unique <a href="http://en.wikipedia.org/wiki/Network_address_translation">NAT'd</a> gateway will be treated as a single client.</p>
|
||||
<p>Further context on how the <code>X-Forwarded-For</code> header works, and identifying a remote client IP can be <a href="http://oxpedia.org/wiki/index.php?title=AppSuite:Grizzly#Multiple_Proxies_in_front_of_the_cluster">found here</a>.</p>
|
||||
<h2 id="setting-up-the-cache"><a class="toclink" href="#setting-up-the-cache">Setting up the cache</a></h2>
|
||||
<p>The throttle classes provided by REST framework use Django's cache backend. You should make sure that you've set appropriate <a href="https://docs.djangoproject.com/en/dev/ref/settings/#caches">cache settings</a>. The default value of <code>LocMemCache</code> backend should be okay for simple setups. See Django's <a href="https://docs.djangoproject.com/en/dev/topics/cache/#setting-up-the-cache">cache documentation</a> for more details.</p>
|
||||
<p>The throttle classes provided by REST framework use Django's cache backend. You should make sure that you've set appropriate <a href="https://docs.djangoproject.com/en/stable/ref/settings/#caches">cache settings</a>. The default value of <code>LocMemCache</code> backend should be okay for simple setups. See Django's <a href="https://docs.djangoproject.com/en/stable/topics/cache/#setting-up-the-cache">cache documentation</a> for more details.</p>
|
||||
<p>If you need to use a cache other than <code>'default'</code>, you can do so by creating a custom throttle class and setting the <code>cache</code> attribute. For example:</p>
|
||||
<pre><code>class CustomAnonRateThrottle(AnonRateThrottle):
|
||||
cache = get_cache('alternate')
|
||||
|
|
|
|||
|
|
@ -464,7 +464,7 @@
|
|||
<h1 id="validators"><a class="toclink" href="#validators">Validators</a></h1>
|
||||
<blockquote>
|
||||
<p>Validators can be useful for re-using validation logic between different types of fields.</p>
|
||||
<p>— <a href="https://docs.djangoproject.com/en/dev/ref/validators/">Django documentation</a></p>
|
||||
<p>— <a href="https://docs.djangoproject.com/en/stable/ref/validators/">Django documentation</a></p>
|
||||
</blockquote>
|
||||
<p>Most of the time you're dealing with validation in REST framework you'll simply be relying on the default field validation, or writing explicit validation methods on serializer or field classes.</p>
|
||||
<p>However, sometimes you'll want to place your validation logic into reusable components, so that it can easily be reused throughout your codebase. This can be achieved by using validator functions and validator classes.</p>
|
||||
|
|
@ -476,7 +476,7 @@
|
|||
<li>It is easy to switch between using shortcut <code>ModelSerializer</code> classes and using explicit <code>Serializer</code> classes. Any validation behavior being used for <code>ModelSerializer</code> is simple to replicate.</li>
|
||||
<li>Printing the <code>repr</code> of a serializer instance will show you exactly what validation rules it applies. There's no extra hidden validation behavior being called on the model instance.</li>
|
||||
</ul>
|
||||
<p>When you're using <code>ModelSerializer</code> all of this is handled automatically for you. If you want to drop down to using a <code>Serializer</code> classes instead, then you need to define the validation rules explicitly.</p>
|
||||
<p>When you're using <code>ModelSerializer</code> all of this is handled automatically for you. If you want to drop down to using <code>Serializer</code> classes instead, then you need to define the validation rules explicitly.</p>
|
||||
<h4 id="example"><a class="toclink" href="#example">Example</a></h4>
|
||||
<p>As an example of how REST framework uses explicit validation, we'll take a simple model class that has a field with a uniqueness constraint.</p>
|
||||
<pre><code>class CustomerReportRecord(models.Model):
|
||||
|
|
@ -582,11 +582,11 @@ class ExampleSerializer(serializers.Serializer):
|
|||
</code></pre>
|
||||
<p>The field will not be writable to the user, but the default value will still be passed through to the <code>validated_data</code>.</p>
|
||||
<h4 id="using-with-a-hidden-date-field"><a class="toclink" href="#using-with-a-hidden-date-field">Using with a hidden date field.</a></h4>
|
||||
<p>If you want the date field to be entirely hidden from the user, then use <code>HiddenField</code>. This field type does not accept user input, but instead always returns it's default value to the <code>validated_data</code> in the serializer.</p>
|
||||
<p>If you want the date field to be entirely hidden from the user, then use <code>HiddenField</code>. This field type does not accept user input, but instead always returns its default value to the <code>validated_data</code> in the serializer.</p>
|
||||
<pre><code>published = serializers.HiddenField(default=timezone.now)
|
||||
</code></pre>
|
||||
<hr />
|
||||
<p><strong>Note</strong>: The <code>UniqueFor<Range>Validation</code> classes always imposes an implicit constraint that the fields they are applied to are always treated as required. Fields with <code>default</code> values are an exception to this as they always supply a value even when omitted from user input.</p>
|
||||
<p><strong>Note</strong>: The <code>UniqueFor<Range>Validation</code> classes impose an implicit constraint that the fields they are applied to are always treated as required. Fields with <code>default</code> values are an exception to this as they always supply a value even when omitted from user input.</p>
|
||||
<hr />
|
||||
<h1 id="advanced-field-defaults"><a class="toclink" href="#advanced-field-defaults">Advanced field defaults</a></h1>
|
||||
<p>Validators that are applied across multiple fields in the serializer can sometimes require a field input that should not be provided by the API client, but that <em>is</em> available as input to the validator.</p>
|
||||
|
|
|
|||
|
|
@ -522,7 +522,7 @@ continued development by <strong><a href="topics/funding/">signing up for a paid
|
|||
<ul class="premium-promo promo">
|
||||
<li><a href="http://jobs.rover.com/" style="background-image: url(https://fund-rest-framework.s3.amazonaws.com/rover_130x130.png)">Rover.com</a></li>
|
||||
<li><a href="https://getsentry.com/welcome/" style="background-image: url(https://fund-rest-framework.s3.amazonaws.com/sentry130.png)">Sentry</a></li>
|
||||
<li><a href="https://getstream.io/?utm_source=drf&utm_medium=banner&utm_campaign=drf" style="background-image: url(https://fund-rest-framework.s3.amazonaws.com/stream-130.png)">Stream</a></li>
|
||||
<li><a href="https://getstream.io/try-the-api/?utm_source=drf&utm_medium=banner&utm_campaign=drf" style="background-image: url(https://fund-rest-framework.s3.amazonaws.com/stream-130.png)">Stream</a></li>
|
||||
<li><a href="http://www.machinalis.com/#services" style="background-image: url(https://fund-rest-framework.s3.amazonaws.com/Machinalis130.png)">Machinalis</a></li>
|
||||
</ul>
|
||||
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
114
sitemap.xml
114
sitemap.xml
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
|
|
@ -13,49 +13,49 @@
|
|||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//tutorial/quickstart/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//tutorial/1-serialization/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//tutorial/2-requests-and-responses/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//tutorial/3-class-based-views/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//tutorial/4-authentication-and-permissions/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//tutorial/5-relationships-and-hyperlinked-apis/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//tutorial/6-viewsets-and-routers/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//tutorial/7-schemas-and-client-libraries/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
|
|
@ -65,163 +65,163 @@
|
|||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/requests/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/responses/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/views/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/generic-views/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/viewsets/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/routers/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/parsers/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/renderers/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/serializers/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/fields/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/relations/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/validators/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/authentication/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/permissions/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/throttling/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/filtering/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/pagination/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/versioning/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/content-negotiation/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/metadata/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/schemas/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/format-suffixes/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/reverse/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/exceptions/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/status-codes/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/testing/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//api-guide/settings/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
|
|
@ -231,127 +231,127 @@
|
|||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/documenting-your-api/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/api-clients/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/internationalization/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/ajax-csrf-cors/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/html-and-forms/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/browser-enhancements/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/browsable-api/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/rest-hypermedia-hateoas/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/third-party-resources/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/contributing/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/project-management/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/3.0-announcement/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/3.1-announcement/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/3.2-announcement/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/3.3-announcement/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/3.4-announcement/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/3.5-announcement/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/kickstarter-announcement/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/mozilla-grant/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/funding/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
<url>
|
||||
<loc>http://www.django-rest-framework.org//topics/release-notes/</loc>
|
||||
<lastmod>2016-11-07</lastmod>
|
||||
<lastmod>2016-12-09</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
|
||||
|
|
|
|||
|
|
@ -1098,7 +1098,7 @@ class OrganizationSerializer(serializers.Serializer):
|
|||
}
|
||||
</code></pre>
|
||||
<h4 id="file-fields-as-urls"><a class="toclink" href="#file-fields-as-urls">File fields as URLs</a></h4>
|
||||
<p>The <code>FileField</code> and <code>ImageField</code> classes are now represented as URLs by default. You should ensure you set Django's <a href="https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-MEDIA_URL">standard <code>MEDIA_URL</code> setting</a> appropriately, and ensure your application <a href="https://docs.djangoproject.com/en/dev/howto/static-files/#serving-uploaded-files-in-development">serves the uploaded files</a>.</p>
|
||||
<p>The <code>FileField</code> and <code>ImageField</code> classes are now represented as URLs by default. You should ensure you set Django's <a href="https://docs.djangoproject.com/en/stable/ref/settings/#std:setting-MEDIA_URL">standard <code>MEDIA_URL</code> setting</a> appropriately, and ensure your application <a href="https://docs.djangoproject.com/en/stable/howto/static-files/#serving-uploaded-files-in-development">serves the uploaded files</a>.</p>
|
||||
<p>You can revert this behavior, and display filenames in the representation by using the <code>UPLOADED_FILES_USE_URL</code> settings key:</p>
|
||||
<pre><code>REST_FRAMEWORK = {
|
||||
'UPLOADED_FILES_USE_URL': False
|
||||
|
|
@ -1150,7 +1150,7 @@ amount = serializers.DecimalField(
|
|||
<ul>
|
||||
<li>The serializer <code>ChoiceField</code> does not currently display nested choices, as was the case in 2.4. This will be address as part of 3.1.</li>
|
||||
<li>Due to the new templated form rendering, the 'widget' option is no longer valid. This means there's no easy way of using third party "autocomplete" widgets for rendering select inputs that contain a large number of choices. You'll either need to use a regular select or a plain text input. We may consider addressing this in 3.1 or 3.2 if there's sufficient demand.</li>
|
||||
<li>Some of the default validation error messages were rewritten and might no longer be pre-translated. You can still <a href="https://docs.djangoproject.com/en/dev/topics/i18n/translation/#localization-how-to-create-language-files">create language files with Django</a> if you wish to localize them.</li>
|
||||
<li>Some of the default validation error messages were rewritten and might no longer be pre-translated. You can still <a href="https://docs.djangoproject.com/en/stable/topics/i18n/translation/#localization-how-to-create-language-files">create language files with Django</a> if you wish to localize them.</li>
|
||||
<li><code>APIException</code> subclasses could previously take any arbitrary type in the <code>detail</code> argument. These exceptions now use translatable text strings, and as a result call <code>force_text</code> on the <code>detail</code> argument, which <em>must be a string</em>. If you need complex arguments to an <code>APIException</code> class, you should subclass it and override the <code>__init__()</code> method. Typically you'll instead want to use a custom exception handler to provide for non-standard error responses.</li>
|
||||
</ul>
|
||||
<hr />
|
||||
|
|
|
|||
|
|
@ -414,7 +414,7 @@
|
|||
<li>Ensure that any 'unsafe' HTTP operations, such as <code>POST</code>, <code>PUT</code>, <code>PATCH</code> and <code>DELETE</code>, always require a valid CSRF token.</li>
|
||||
</ol>
|
||||
<p>If you're using <code>SessionAuthentication</code> you'll need to include valid CSRF tokens for any <code>POST</code>, <code>PUT</code>, <code>PATCH</code> or <code>DELETE</code> operations.</p>
|
||||
<p>In order to make AJAX requests, you need to include CSRF token in the HTTP header, as <a href="https://docs.djangoproject.com/en/dev/ref/csrf/#ajax">described in the Django documentation</a>.</p>
|
||||
<p>In order to make AJAX requests, you need to include CSRF token in the HTTP header, as <a href="https://docs.djangoproject.com/en/stable/ref/csrf/#ajax">described in the Django documentation</a>.</p>
|
||||
<h2 id="cors"><a class="toclink" href="#cors">CORS</a></h2>
|
||||
<p><a href="http://www.w3.org/TR/cors/">Cross-Origin Resource Sharing</a> is a mechanism for allowing clients to interact with APIs that are hosted on a different domain. CORS works by requiring the server to include a specific set of headers that allow a browser to determine if and when cross-domain requests should be allowed.</p>
|
||||
<p>The best way to deal with CORS in REST framework is to add the required response headers in middleware. This ensures that CORS is supported transparently, without having to change any behavior in your views.</p>
|
||||
|
|
|
|||
|
|
@ -431,7 +431,7 @@
|
|||
<p>Medium version numbers (0.x.0) may include API changes, in line with the <a href="#deprecation-policy">deprecation policy</a>. You should read the release notes carefully before upgrading between medium point releases.</p>
|
||||
<p>Major version numbers (x.0.0) are reserved for substantial project milestones.</p>
|
||||
<h2 id="deprecation-policy"><a class="toclink" href="#deprecation-policy">Deprecation policy</a></h2>
|
||||
<p>REST framework releases follow a formal deprecation policy, which is in line with <a href="https://docs.djangoproject.com/en/dev/internals/release-process/#internal-release-deprecation-policy">Django's deprecation policy</a>.</p>
|
||||
<p>REST framework releases follow a formal deprecation policy, which is in line with <a href="https://docs.djangoproject.com/en/stable/internals/release-process/#internal-release-deprecation-policy">Django's deprecation policy</a>.</p>
|
||||
<p>The timeline for deprecation of a feature present in version 1.0 would work as follows:</p>
|
||||
<ul>
|
||||
<li>
|
||||
|
|
|
|||
|
|
@ -508,7 +508,9 @@ urlpatterns = [
|
|||
)
|
||||
|
||||
REST_FRAMEWORK = {
|
||||
'DEFAULT_PERMISSION_CLASSES': ('rest_framework.permissions.IsAdminUser',),
|
||||
'DEFAULT_PERMISSION_CLASSES': [
|
||||
'rest_framework.permissions.IsAdminUser',
|
||||
],
|
||||
'PAGE_SIZE': 10
|
||||
}
|
||||
</code></pre>
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user