From 5cbb535d1185ebc34ac9881b865594c57713b142 Mon Sep 17 00:00:00 2001 From: Tom Christie Date: Mon, 24 Aug 2015 10:04:47 +0000 Subject: [PATCH] Update documentation --- .DS_Store | Bin 0 -> 12292 bytes api-guide/fields/index.html | 6 +- api-guide/filtering/index.html | 2 + api-guide/relations/index.html | 23 +- mkdocs/search_index.json | 27 +- sitemap.xml | 96 ++--- topics/funding/index.html | 709 ++++++++++++++++++++++++++++++++ topics/release-notes/index.html | 15 +- 8 files changed, 815 insertions(+), 63 deletions(-) create mode 100644 .DS_Store create mode 100644 topics/funding/index.html diff --git a/.DS_Store b/.DS_Store new file mode 100644 index 0000000000000000000000000000000000000000..7eabc72618222d2e8f644121a49cf2828d763ad0 GIT binary patch literal 12292 zcmeHMTWl3Y7@qI6z^>i3+txx`3OTlkR4t@jq}VocTFM=yp$A%SmOW=zSl#Y6XZM^E zYo%gLl&JCcU}B77)CVN;qJj^;=z|!1voVpVFY2qBNaE#1|C!kqXzi26G&+;ae6#ca z|6IQP=1gV}V+=h-XEkGWj4_QeN2`L0zewE9^Q@FgTFMDQ@hlq2`C*Qp&gVvEd8-D+ zfMP%~pcqgLCAhW6B5Zn2{M#Wh9bFQK!#I$I`PXSI3ZDnGbEP}BqJlap+JmI{ilUHLq?)1 z6$6Ta*$nXQQ^q_t%#P(oufMreSuV2`GSRuG+oz>!vkL6grhxSF>saI{)2+v~+NM=q+p_k<!jDRQ@*_m*Ty8`z;>z?Q zZmKZMn>TOSx@4O%WL1|ucXZE4?1e$J-z`LhLsn%(%i5j~gT8{x?L$^o-uClF-;UjG z-|zPxa-)HK=og2BhCV%Wl2x&bGVmzGu>^s;)6=jU@vmFYyT54)2!Rn=B~gJ~RgsL$P@!|jgso~8@S@&?m9#4Vc&E|rd^iRPwe z)5u0NdCN{5SF{*L_Cb2-R;0_&)|H02&$n}~Z#lXQTfN3G2TGDZYiH89zSb}Y^WpF? zO)g5>Iyz1BK0fR&JBs&=xB*S+5{x8n}1#Rhbs6J6Mh9oU84xEBLBf*~A*jR#Obj3P=ni6`(RPU8ie3pq)rIAW8o063f^$l8{tZ!J_xNJFzk<{s)n7J#a zq+~7PdqNZ5ByZEwgyMMciWYiI(Vmdj)|IAVl?ml@D;Kr3Kxmvlu5ULCt6b~?{@B?? z)`ddsjSWldjpas-q&~eh|qd0}f@D!fGvv>~A<7K>pSMeIo;4I$8IlM!9 zy@(I+5iVmAU(ZnL&KXMm=9*GV{e{2}gJaY(rRy7=)ziFYpiIuLj^F<`&;9*>Uavt- zPBEYu_ -

Note: The style argument replaces the old-style version 2.x widget keyword argument. Because REST framework 3 now uses templated HTML form generation, the widget option that was used to support Django built-in widgets can no longer be supported. Version 3.1 is planned to include public API support for customizing HTML form generation.

+

Note: The style argument replaces the old-style version 2.x widget keyword argument. Because REST framework 3 now uses templated HTML form generation, the widget option that was used to support Django built-in widgets can no longer be supported. Version 3.3 is planned to include public API support for customizing HTML form generation.

Boolean fields

BooleanField

@@ -787,6 +787,8 @@ The representation is a string following this format '[DD] [HH:[MM:]]ss[.u
  • choices - A list of valid values, or a list of (key, display_name) tuples.
  • allow_blank - If set to True then the empty string should be considered a valid value. If set to False then the empty string is considered invalid and will raise a validation error. Defaults to False.
    • +
  • html_cutoff - If set this will be the maximum number of choices that will be displayed by a HTML select drop down. Can be used to ensure that automatically generated ChoiceFields with very large possible selections do not prevent a template from rendering. Defaults to None.
    • +
  • html_cutoff_text - If set this will display a textual indicator if the maximum number of items have been cutoff in an HTML select drop down. Defaults to "More than {count} items…"

Both the allow_blank and allow_null are valid options on ChoiceField, although it is highly recommended that you only use one and not both. allow_blank should be preferred for textual choices, and allow_null should be preferred for numeric or other non-textual choices.

MultipleChoiceField

@@ -795,6 +797,8 @@ The representation is a string following this format '[DD] [HH:[MM:]]ss[.u
  • choices - A list of valid values, or a list of (key, display_name) tuples.
  • allow_blank - If set to True then the empty string should be considered a valid value. If set to False then the empty string is considered invalid and will raise a validation error. Defaults to False.
    • +
  • html_cutoff - If set this will be the maximum number of choices that will be displayed by a HTML select drop down. Can be used to ensure that automatically generated ChoiceFields with very large possible selections do not prevent a template from rendering. Defaults to None.
    • +
  • html_cutoff_text - If set this will display a textual indicator if the maximum number of items have been cutoff in an HTML select drop down. Defaults to "More than {count} items…"

As with ChoiceField, both the allow_blank and allow_null options are valid, although it is highly recommended that you only use one and not both. allow_blank should be preferred for textual choices, and allow_null should be preferred for numeric or other non-textual choices.

diff --git a/api-guide/filtering/index.html b/api-guide/filtering/index.html index ed7e19368..5a6efaf7e 100644 --- a/api-guide/filtering/index.html +++ b/api-guide/filtering/index.html @@ -556,6 +556,7 @@ class UserListView(generics.ListAPIView): 
import django_filters
 from myapp.models import Product
 from myapp.serializers import ProductSerializer
+from rest_framework import filters
 from rest_framework import generics
 
 class ProductFilter(django_filters.FilterSet):
@@ -637,6 +638,7 @@ class ProductFilter(django_filters.FilterSet):
 
  • '^' Starts-with search.
    • 
 
  • '=' Exact matches.
    • 
 
  • '@' Full-text search.  (Currently only supported Django's MySQL backend.)
    • 
+
  • '$' Regex search.
    • 
 
 
    For example:
    
 
    search_fields = ('=username', '=email')
diff --git a/api-guide/relations/index.html b/api-guide/relations/index.html
index adadf7938..5f1015e63 100644
--- a/api-guide/relations/index.html
+++ b/api-guide/relations/index.html
@@ -338,7 +338,7 @@
 
                   
                     
  • 
-                      Inspecting automatically generated relationships.
+                      Inspecting relationships.
                     
    • 
                   
                 
@@ -417,6 +417,10 @@
                       Customizing the HTML display
                     
                   
+                    
  • 
+                      Select field cutoffs
+                    
    • 
+                  
                     
  • 
                       Reverse relations
                     
    • 
@@ -467,7 +471,7 @@ Good programmers worry about data structures and their relationships.
    
 
    
 
    Note: The relational fields are declared in relations.py, but by convention you should import them from the serializers module, using from rest_framework import serializers and refer to fields as serializers.<FieldName>.
    
 
    
-
    Inspecting automatically generated relationships.
    
+
    Inspecting relationships.
    
 
    When using the ModelSerializer class, serializer fields and relationships will be automatically generated for you. Inspecting these automatically generated fields can be a useful tool for determining how to customize the relationship style.
    
 
    To do so, open the Django shell, using python manage.py shell, then import the serializer class, instantiate it, and print the object representation…
    
 
    >>> from myapp.serializers import AccountSerializer
@@ -817,6 +821,21 @@ class CustomerHyperlink(serializers.HyperlinkedRelatedField):
     def display_value(self, instance):
         return 'Track: %s' % (instance.title)
 
    
+
    Select field cutoffs
    
+
    When rendered in the browsable API relational fields will default to only displaying a maximum of 1000 selectable items. If more items are present then a disabled option with "More than 1000 items…" will be displayed.
    
+
    This behavior is intended to prevent a template from being unable to render in an acceptable timespan due to a very large number of relationships being displayed.
    
+
    There are two keyword arguments you can use to control this behavior:
    
+
      
+
    • html_cutoff - If set this will be the maximum number of choices that will be displayed by a HTML select drop down. Set to None to disable any limiting. Defaults to 1000.
      • 
+
    • html_cutoff_text - If set this will display a textual indicator if the maximum number of items have been cutoff in an HTML select drop down. Defaults to "More than {count} items…"
      • 
+
    
+
    In cases where the cutoff is being enforced you may want to instead use a plain input field in the HTML form. You can do so using the style keyword argument. For example:
    
+
    assigned_to = serializers.SlugRelatedField(
+   queryset=User.objects.all(),
+   slug field='username',
+   style={'base_template': 'input.html'}
+)
+
    
 
    Reverse relations
    
 
    Note that reverse relationships are not automatically included by the ModelSerializer and HyperlinkedModelSerializer classes.  To include a reverse relationship, you must explicitly add it to the fields list.  For example:
    
 
    class AlbumSerializer(serializers.ModelSerializer):
diff --git a/mkdocs/search_index.json b/mkdocs/search_index.json
index dead27689..594d3eea0 100644
--- a/mkdocs/search_index.json
+++ b/mkdocs/search_index.json
@@ -1247,7 +1247,7 @@
         }, 
         {
             "location": "/api-guide/fields/", 
-            "text": "Serializer fields\n\n\n\n\nEach field in a Form class is responsible not only for validating data, but also for \"cleaning\" it \n normalizing it to a consistent format.\n\n\n \nDjango documentation\n\n\n\n\nSerializer 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.\n\n\n\n\nNote:\n The serializer fields are declared in \nfields.py\n, but by convention you should import them using \nfrom rest_framework import serializers\n and refer to fields as \nserializers.\nFieldName\n.\n\n\n\n\nCore arguments\n\n\nEach serializer field class constructor takes at least these arguments.  Some Field classes take additional, field-specific arguments, but the following should always be accepted:\n\n\nread_only\n\n\nRead-only fields are included in the API output, but should not be included in the input during create or update operations. Any 'read_only' fields that are incorrectly included in the serializer input will be ignored.\n\n\nSet this to \nTrue\n to ensure that the field is used when serializing a representation, but is not used when creating or updating an instance during deserialization.\n\n\nDefaults to \nFalse\n\n\nwrite_only\n\n\nSet this to \nTrue\n to ensure that the field may be used when updating or creating an instance, but is not included when serializing the representation.\n\n\nDefaults to \nFalse\n\n\nrequired\n\n\nNormally an error will be raised if a field is not supplied during deserialization.\nSet to false if this field is not required to be present during deserialization.\n\n\nSetting this to \nFalse\n also allows the object attribute or dictionary key to be omitted from output when serializing the instance. If the key is not present it will simply not be included in the output representation.\n\n\nDefaults to \nTrue\n.\n\n\nallow_null\n\n\nNormally an error will be raised if \nNone\n is passed to a serializer field. Set this keyword argument to \nTrue\n if \nNone\n should be considered a valid value.\n\n\nDefaults to \nFalse\n\n\ndefault\n\n\nIf set, this gives the default value that will be used for the field if no input value is supplied.  If not set the default behavior is to not populate the attribute at all.\n\n\nMay be set to a function or other callable, in which case the value will be evaluated each time it is used.\n\n\nNote that setting a \ndefault\n value implies that the field is not required. Including both the \ndefault\n and \nrequired\n keyword arguments is invalid and will raise an error.\n\n\nsource\n\n\nThe name of the attribute that will be used to populate the field.  May be a method that only takes a \nself\n argument, such as \nURLField('get_absolute_url')\n, or may use dotted notation to traverse attributes, such as \nEmailField(source='user.email')\n.\n\n\nThe value \nsource='*'\n has a special meaning, and is used to indicate that the entire object should be passed through to the field.  This can be useful for creating nested representations, or for fields which require access to the complete object in order to determine the output representation.\n\n\nDefaults to the name of the field.\n\n\nvalidators\n\n\nA list of validator functions which should be applied to the incoming field input, and which either raise a validation error or simply return. Validator functions should typically raise \nserializers.ValidationError\n, but Django's built-in \nValidationError\n is also supported for compatibility with validators defined in the Django codebase or third party Django packages.\n\n\nerror_messages\n\n\nA dictionary of error codes to error messages.\n\n\nlabel\n\n\nA short text string that may be used as the name of the field in HTML form fields or other descriptive elements.\n\n\nhelp_text\n\n\nA text string that may be used as a description of the field in HTML form fields or other descriptive elements.\n\n\ninitial\n\n\nA value that should be used for pre-populating the value of HTML form fields.\n\n\nstyle\n\n\nA dictionary of key-value pairs that can be used to control how renderers should render the field. The API for this should still be considered experimental, and will be formalized with the 3.1 release.\n\n\nTwo options are currently used in HTML form generation, \n'input_type'\n and \n'base_template'\n.\n\n\n# Use \ninput type=\"password\"\n for the input.\npassword = serializers.CharField(\n    style={'input_type': 'password'}\n)\n\n# Use a radio input instead of a select input.\ncolor_channel = serializers.ChoiceField(\n    choices=['red', 'green', 'blue']\n    style = {'base_template': 'radio.html'}\n}\n\n\n\nNote\n: The \nstyle\n argument replaces the old-style version 2.x \nwidget\n keyword argument. Because REST framework 3 now uses templated HTML form generation, the \nwidget\n option that was used to support Django built-in widgets can no longer be supported. Version 3.1 is planned to include public API support for customizing HTML form generation.\n\n\n\n\nBoolean fields\n\n\nBooleanField\n\n\nA boolean representation.\n\n\nWhen using HTML encoded form input be aware that omitting a value will always be treated as setting a field to \nFalse\n, even if it has a \ndefault=True\n 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.\n\n\nCorresponds to \ndjango.db.models.fields.BooleanField\n.\n\n\nSignature:\n \nBooleanField()\n\n\nNullBooleanField\n\n\nA boolean representation that also accepts \nNone\n as a valid value.\n\n\nCorresponds to \ndjango.db.models.fields.NullBooleanField\n.\n\n\nSignature:\n \nNullBooleanField()\n\n\n\n\nString fields\n\n\nCharField\n\n\nA text representation. Optionally validates the text to be shorter than \nmax_length\n and longer than \nmin_length\n.\n\n\nCorresponds to \ndjango.db.models.fields.CharField\n or \ndjango.db.models.fields.TextField\n.\n\n\nSignature:\n \nCharField(max_length=None, min_length=None, allow_blank=False, trim_whitespace=True)\n\n\n\n\nmax_length\n - Validates that the input contains no more than this number of characters.\n\n\nmin_length\n - Validates that the input contains no fewer than this number of characters.\n\n\nallow_blank\n - If set to \nTrue\n then the empty string should be considered a valid value. If set to \nFalse\n then the empty string is considered invalid and will raise a validation error. Defaults to \nFalse\n.\n\n\ntrim_whitespace\n - If set to \nTrue\n then leading and trailing whitespace is trimmed. Defaults to \nTrue\n.\n\n\n\n\nThe \nallow_null\n option is also available for string fields, although its usage is discouraged in favor of \nallow_blank\n. It is valid to set both \nallow_blank=True\n and \nallow_null=True\n, but doing so means that there will be two differing types of empty value permissible for string representations, which can lead to data inconsistencies and subtle application bugs.\n\n\nEmailField\n\n\nA text representation, validates the text to be a valid e-mail address.\n\n\nCorresponds to \ndjango.db.models.fields.EmailField\n\n\nSignature:\n \nEmailField(max_length=None, min_length=None, allow_blank=False)\n\n\nRegexField\n\n\nA text representation, that validates the given value matches against a certain regular expression.\n\n\nCorresponds to \ndjango.forms.fields.RegexField\n.\n\n\nSignature:\n \nRegexField(regex, max_length=None, min_length=None, allow_blank=False)\n\n\nThe mandatory \nregex\n argument may either be a string, or a compiled python regular expression object.\n\n\nUses Django's \ndjango.core.validators.RegexValidator\n for validation.\n\n\nSlugField\n\n\nA \nRegexField\n that validates the input against the pattern \n[a-zA-Z0-9_-]+\n.\n\n\nCorresponds to \ndjango.db.models.fields.SlugField\n.\n\n\nSignature:\n \nSlugField(max_length=50, min_length=None, allow_blank=False)\n\n\nURLField\n\n\nA \nRegexField\n that validates the input against a URL matching pattern. Expects fully qualified URLs of the form \nhttp://\nhost\n/\npath\n.\n\n\nCorresponds to \ndjango.db.models.fields.URLField\n.  Uses Django's \ndjango.core.validators.URLValidator\n for validation.\n\n\nSignature:\n \nURLField(max_length=200, min_length=None, allow_blank=False)\n\n\nUUIDField\n\n\nA field that ensures the input is a valid UUID string. The \nto_internal_value\n method will return a \nuuid.UUID\n instance. On output the field will return a string in the canonical hyphenated format, for example:\n\n\n\"de305d54-75b4-431b-adb2-eb6b9e546013\"\n\n\n\nSignature:\n \nUUIDField(format='hex_verbose')\n\n\n\n\nformat\n: Determines the representation format of the uuid value\n\n\n'hex_verbose'\n - The cannoncical hex representation, including hyphens: \n\"5ce0e9a5-5ffa-654b-cee0-1238041fb31a\"\n\n\n'hex'\n - The compact hex representation of the UUID, not including hyphens: \n\"5ce0e9a55ffa654bcee01238041fb31a\"\n\n\n'int'\n - A 128 bit integer representation of the UUID: \n\"123456789012312313134124512351145145114\"\n\n\n'urn'\n - RFC 4122 URN representation of the UUID: \n\"urn:uuid:5ce0e9a5-5ffa-654b-cee0-1238041fb31a\"\n\n  Changing the \nformat\n parameters only affects representation values. All formats are accepted by \nto_internal_value\n\n\n\n\n\n\n\n\nFilePathField\n\n\nA field whose choices are limited to the filenames in a certain directory on the filesystem\n\n\nCorresponds to \ndjango.forms.fields.FilePathField\n.\n\n\nSignature:\n \nFilePathField(path, match=None, recursive=False, allow_files=True, allow_folders=False, required=None, **kwargs)\n\n\n\n\npath\n - The absolute filesystem path to a directory from which this FilePathField should get its choice.\n\n\nmatch\n - A regular expression, as a string, that FilePathField will use to filter filenames.\n\n\nrecursive\n - Specifies whether all subdirectories of path should be included.  Default is \nFalse\n.\n\n\nallow_files\n - Specifies whether files in the specified location should be included. Default is \nTrue\n. Either this or \nallow_folders\n must be \nTrue\n.\n\n\nallow_folders\n - Specifies whether folders in the specified location should be included. Default is \nFalse\n. Either this or \nallow_files\n must be \nTrue\n.\n\n\n\n\nIPAddressField\n\n\nA field that ensures the input is a valid IPv4 or IPv6 string.\n\n\nCorresponds to \ndjango.forms.fields.IPAddressField\n and \ndjango.forms.fields.GenericIPAddressField\n.\n\n\nSignature\n: \nIPAddressField(protocol='both', unpack_ipv4=False, **options)\n\n\n\n\nprotocol\n Limits valid inputs to the specified protocol. Accepted values are 'both' (default), 'IPv4' or 'IPv6'. Matching is case insensitive.\n\n\nunpack_ipv4\n Unpacks IPv4 mapped addresses like ::ffff:192.0.2.1. If this option is enabled that address would be unpacked to 192.0.2.1. Default is disabled. Can only be used when protocol is set to 'both'.\n\n\n\n\n\n\nNumeric fields\n\n\nIntegerField\n\n\nAn integer representation.\n\n\nCorresponds to \ndjango.db.models.fields.IntegerField\n, \ndjango.db.models.fields.SmallIntegerField\n, \ndjango.db.models.fields.PositiveIntegerField\n and \ndjango.db.models.fields.PositiveSmallIntegerField\n.\n\n\nSignature\n: \nIntegerField(max_value=None, min_value=None)\n\n\n\n\nmax_value\n Validate that the number provided is no greater than this value.\n\n\nmin_value\n Validate that the number provided is no less than this value.\n\n\n\n\nFloatField\n\n\nA floating point representation.\n\n\nCorresponds to \ndjango.db.models.fields.FloatField\n.\n\n\nSignature\n: \nFloatField(max_value=None, min_value=None)\n\n\n\n\nmax_value\n Validate that the number provided is no greater than this value.\n\n\nmin_value\n Validate that the number provided is no less than this value.\n\n\n\n\nDecimalField\n\n\nA decimal representation, represented in Python by a \nDecimal\n instance.\n\n\nCorresponds to \ndjango.db.models.fields.DecimalField\n.\n\n\nSignature\n: \nDecimalField(max_digits, decimal_places, coerce_to_string=None, max_value=None, min_value=None)\n\n\n\n\nmax_digits\n The maximum number of digits allowed in the number. Note that this number must be greater than or equal to decimal_places.\n\n\ndecimal_places\n The number of decimal places to store with the number.\n\n\ncoerce_to_string\n Set to \nTrue\n if string values should be returned for the representation, or \nFalse\n if \nDecimal\n objects should be returned. Defaults to the same value as the \nCOERCE_DECIMAL_TO_STRING\n settings key, which will be \nTrue\n unless overridden. If \nDecimal\n objects are returned by the serializer, then the final output format will be determined by the renderer.\n\n\nmax_value\n Validate that the number provided is no greater than this value.\n\n\nmin_value\n Validate that the number provided is no less than this value.\n\n\n\n\nExample usage\n\n\nTo validate numbers up to 999 with a resolution of 2 decimal places, you would use:\n\n\nserializers.DecimalField(max_digits=5, decimal_places=2)\n\n\n\nAnd to validate numbers up to anything less than one billion with a resolution of 10 decimal places:\n\n\nserializers.DecimalField(max_digits=19, decimal_places=10)\n\n\n\nThis field also takes an optional argument, \ncoerce_to_string\n. If set to \nTrue\n the representation will be output as a string. If set to \nFalse\n the representation will be left as a \nDecimal\n instance and the final representation will be determined by the renderer.\n\n\nIf unset, this will default to the same value as the \nCOERCE_DECIMAL_TO_STRING\n setting, which is \nTrue\n unless set otherwise.\n\n\n\n\nDate and time fields\n\n\nDateTimeField\n\n\nA date and time representation.\n\n\nCorresponds to \ndjango.db.models.fields.DateTimeField\n.\n\n\nSignature:\n \nDateTimeField(format=None, input_formats=None)\n\n\n\n\nformat\n - A string representing the output format.  If not specified, this defaults to the same value as the \nDATETIME_FORMAT\n settings key, which will be \n'iso-8601'\n unless set. Setting to a format string indicates that \nto_representation\n return values should be coerced to string output. Format strings are described below. Setting this value to \nNone\n indicates that Python \ndatetime\n objects should be returned by \nto_representation\n. In this case the datetime encoding will be determined by the renderer.\n\n\ninput_formats\n - A list of strings representing the input formats which may be used to parse the date.  If not specified, the \nDATETIME_INPUT_FORMATS\n setting will be used, which defaults to \n['iso-8601']\n.\n\n\n\n\nDateTimeField\n format strings.\n\n\nFormat strings may either be \nPython strftime formats\n which explicitly specify the format, or the special string \n'iso-8601'\n, which indicates that \nISO 8601\n style datetimes should be used. (eg \n'2013-01-29T12:34:56.000000Z'\n)\n\n\nWhen a value of \nNone\n is used for the format \ndatetime\n objects will be returned by \nto_representation\n and the final output representation will determined by the renderer class.\n\n\nIn the case of JSON this means the default datetime representation uses the \nECMA 262 date time string specification\n.  This is a subset of ISO 8601 which uses millisecond precision, and includes the 'Z' suffix for the UTC timezone, for example: \n2013-01-29T12:34:56.123Z\n.\n\n\nauto_now\n and \nauto_now_add\n model fields.\n\n\nWhen using \nModelSerializer\n or \nHyperlinkedModelSerializer\n, note that any model fields with \nauto_now=True\n or \nauto_now_add=True\n will use serializer fields that are \nread_only=True\n by default.\n\n\nIf you want to override this behavior, you'll need to declare the \nDateTimeField\n explicitly on the serializer.  For example:\n\n\nclass CommentSerializer(serializers.ModelSerializer):\n    created = serializers.DateTimeField()\n\n    class Meta:\n        model = Comment\n\n\n\nDateField\n\n\nA date representation.\n\n\nCorresponds to \ndjango.db.models.fields.DateField\n\n\nSignature:\n \nDateField(format=None, input_formats=None)\n\n\n\n\nformat\n - A string representing the output format.  If not specified, this defaults to the same value as the \nDATE_FORMAT\n settings key, which will be \n'iso-8601'\n unless set. Setting to a format string indicates that \nto_representation\n return values should be coerced to string output. Format strings are described below. Setting this value to \nNone\n indicates that Python \ndate\n objects should be returned by \nto_representation\n. In this case the date encoding will be determined by the renderer.\n\n\ninput_formats\n - A list of strings representing the input formats which may be used to parse the date.  If not specified, the \nDATE_INPUT_FORMATS\n setting will be used, which defaults to \n['iso-8601']\n.\n\n\n\n\nDateField\n format strings\n\n\nFormat strings may either be \nPython strftime formats\n which explicitly specify the format, or the special string \n'iso-8601'\n, which indicates that \nISO 8601\n style dates should be used. (eg \n'2013-01-29'\n)\n\n\nTimeField\n\n\nA time representation.\n\n\nCorresponds to \ndjango.db.models.fields.TimeField\n\n\nSignature:\n \nTimeField(format=None, input_formats=None)\n\n\n\n\nformat\n - A string representing the output format.  If not specified, this defaults to the same value as the \nTIME_FORMAT\n settings key, which will be \n'iso-8601'\n unless set. Setting to a format string indicates that \nto_representation\n return values should be coerced to string output. Format strings are described below. Setting this value to \nNone\n indicates that Python \ntime\n objects should be returned by \nto_representation\n. In this case the time encoding will be determined by the renderer.\n\n\ninput_formats\n - A list of strings representing the input formats which may be used to parse the date.  If not specified, the \nTIME_INPUT_FORMATS\n setting will be used, which defaults to \n['iso-8601']\n.\n\n\n\n\nTimeField\n format strings\n\n\nFormat strings may either be \nPython strftime formats\n which explicitly specify the format, or the special string \n'iso-8601'\n, which indicates that \nISO 8601\n style times should be used. (eg \n'12:34:56.000000'\n)\n\n\nDurationField\n\n\nA Duration representation.\nCorresponds to \ndjango.db.models.fields.DurationField\n\n\nThe \nvalidated_data\n for these fields will contain a \ndatetime.timedelta\n instance.\nThe representation is a string following this format \n'[DD] [HH:[MM:]]ss[.uuuuuu]'\n.\n\n\nNote:\n This field is only available with Django versions \n= 1.8.\n\n\nSignature:\n \nDurationField()\n\n\n\n\nChoice selection fields\n\n\nChoiceField\n\n\nA field that can accept a value out of a limited set of choices.\n\n\nUsed by \nModelSerializer\n to automatically generate fields if the corresponding model field includes a \nchoices=\u2026\n argument.\n\n\nSignature:\n \nChoiceField(choices)\n\n\n\n\nchoices\n - A list of valid values, or a list of \n(key, display_name)\n tuples.\n\n\nallow_blank\n - If set to \nTrue\n then the empty string should be considered a valid value. If set to \nFalse\n then the empty string is considered invalid and will raise a validation error. Defaults to \nFalse\n.\n\n\n\n\nBoth the \nallow_blank\n and \nallow_null\n are valid options on \nChoiceField\n, although it is highly recommended that you only use one and not both. \nallow_blank\n should be preferred for textual choices, and \nallow_null\n should be preferred for numeric or other non-textual choices.\n\n\nMultipleChoiceField\n\n\nA field that can accept a set of zero, one or many values, chosen from a limited set of choices. Takes a single mandatory argument. \nto_internal_value\n returns a \nset\n containing the selected values.\n\n\nSignature:\n \nMultipleChoiceField(choices)\n\n\n\n\nchoices\n - A list of valid values, or a list of \n(key, display_name)\n tuples.\n\n\nallow_blank\n - If set to \nTrue\n then the empty string should be considered a valid value. If set to \nFalse\n then the empty string is considered invalid and will raise a validation error. Defaults to \nFalse\n.\n\n\n\n\nAs with \nChoiceField\n, both the \nallow_blank\n and \nallow_null\n options are valid, although it is highly recommended that you only use one and not both. \nallow_blank\n should be preferred for textual choices, and \nallow_null\n should be preferred for numeric or other non-textual choices.\n\n\n\n\nFile upload fields\n\n\nParsers and file uploads.\n\n\nThe \nFileField\n and \nImageField\n classes are only suitable for use with \nMultiPartParser\n or \nFileUploadParser\n. Most parsers, such as e.g. JSON don't support file uploads.\nDjango's regular \nFILE_UPLOAD_HANDLERS\n are used for handling uploaded files.\n\n\nFileField\n\n\nA file representation.  Performs Django's standard FileField validation.\n\n\nCorresponds to \ndjango.forms.fields.FileField\n.\n\n\nSignature:\n \nFileField(max_length=None, allow_empty_file=False, use_url=UPLOADED_FILES_USE_URL)\n\n\n\n\nmax_length\n - Designates the maximum length for the file name.\n\n\nallow_empty_file\n - Designates if empty files are allowed.\n\n\nuse_url\n - If set to \nTrue\n then URL string values will be used for the output representation. If set to \nFalse\n then filename string values will be used for the output representation. Defaults to the value of the \nUPLOADED_FILES_USE_URL\n settings key, which is \nTrue\n unless set otherwise.\n\n\n\n\nImageField\n\n\nAn image representation. Validates the uploaded file content as matching a known image format.\n\n\nCorresponds to \ndjango.forms.fields.ImageField\n.\n\n\nSignature:\n \nImageField(max_length=None, allow_empty_file=False, use_url=UPLOADED_FILES_USE_URL)\n\n\n\n\nmax_length\n - Designates the maximum length for the file name.\n\n\nallow_empty_file\n - Designates if empty files are allowed.\n\n\nuse_url\n - If set to \nTrue\n then URL string values will be used for the output representation. If set to \nFalse\n then filename string values will be used for the output representation. Defaults to the value of the \nUPLOADED_FILES_USE_URL\n settings key, which is \nTrue\n unless set otherwise.\n\n\n\n\nRequires either the \nPillow\n package or \nPIL\n package.  The \nPillow\n package is recommended, as \nPIL\n is no longer actively maintained.\n\n\n\n\nComposite fields\n\n\nListField\n\n\nA field class that validates a list of objects.\n\n\nSignature\n: \nListField(child)\n\n\n\n\nchild\n - A field instance that should be used for validating the objects in the list. If this argument is not provided then objects in the list will not be validated.\n\n\n\n\nFor example, to validate a list of integers you might use something like the following:\n\n\nscores = serializers.ListField(\n   child=serializers.IntegerField(min_value=0, max_value=100)\n)\n\n\n\nThe \nListField\n class also supports a declarative style that allows you to write reusable list field classes.\n\n\nclass StringListField(serializers.ListField):\n    child = serializers.CharField()\n\n\n\nWe can now reuse our custom \nStringListField\n class throughout our application, without having to provide a \nchild\n argument to it.\n\n\nDictField\n\n\nA field class that validates a dictionary of objects. The keys in \nDictField\n are always assumed to be string values.\n\n\nSignature\n: \nDictField(child)\n\n\n\n\nchild\n - A field instance that should be used for validating the values in the dictionary. If this argument is not provided then values in the mapping will not be validated.\n\n\n\n\nFor example, to create a field that validates a mapping of strings to strings, you would write something like this:\n\n\ndocument = DictField(child=CharField())\n\n\n\nYou can also use the declarative style, as with \nListField\n. For example:\n\n\nclass DocumentField(DictField):\n    child = CharField()\n\n\n\n\n\nMiscellaneous fields\n\n\nReadOnlyField\n\n\nA field class that simply returns the value of the field without modification.\n\n\nThis field is used by default with \nModelSerializer\n when including field names that relate to an attribute rather than a model field.\n\n\nSignature\n: \nReadOnlyField()\n\n\nFor example, is \nhas_expired\n was a property on the \nAccount\n model, then the following serializer would automatically generate it as a \nReadOnlyField\n:\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n    class Meta:\n        model = Account\n        fields = ('id', 'account_name', 'has_expired')\n\n\n\nHiddenField\n\n\nA field class that does not take a value based on user input, but instead takes its value from a default value or callable.\n\n\nSignature\n: \nHiddenField()\n\n\nFor example, to include a field that always provides the current time as part of the serializer validated data, you would use the following:\n\n\nmodified = serializers.HiddenField(default=timezone.now)\n\n\n\nThe \nHiddenField\n class is usually only needed if you have some validation that needs to run based on some pre-provided field values, but you do not want to expose all of those fields to the end user.\n\n\nFor further examples on \nHiddenField\n see the \nvalidators\n documentation.\n\n\nModelField\n\n\nA generic field that can be tied to any arbitrary model field. The \nModelField\n class delegates the task of serialization/deserialization to its associated model field.  This field can be used to create serializer fields for custom model fields, without having to create a new custom serializer field.\n\n\nThis field is used by \nModelSerializer\n to correspond to custom model field classes.\n\n\nSignature:\n \nModelField(model_field=\nDjango ModelField instance\n)\n\n\nThe \nModelField\n class is generally intended for internal use, but can be used by your API if needed.  In order to properly instantiate a \nModelField\n, it must be passed a field that is attached to an instantiated model.  For example: \nModelField(model_field=MyModel()._meta.get_field('custom_field'))\n\n\nSerializerMethodField\n\n\nThis is a read-only field. It gets its value by calling a method on the serializer class it is attached to. It can be used to add any sort of data to the serialized representation of your object.\n\n\nSignature\n: \nSerializerMethodField(method_name=None)\n\n\n\n\nmethod_name\n - The name of the method on the serializer to be called. If not included this defaults to \nget_\nfield_name\n.\n\n\n\n\nThe serializer method referred to by the \nmethod_name\n argument should accept a single argument (in addition to \nself\n), which is the object being serialized. It should return whatever you want to be included in the serialized representation of the object. For example:\n\n\nfrom django.contrib.auth.models import User\nfrom django.utils.timezone import now\nfrom rest_framework import serializers\n\nclass UserSerializer(serializers.ModelSerializer):\n    days_since_joined = serializers.SerializerMethodField()\n\n    class Meta:\n        model = User\n\n    def get_days_since_joined(self, obj):\n        return (now() - obj.date_joined).days\n\n\n\n\n\nCustom fields\n\n\nIf you want to create a custom field, you'll need to subclass \nField\n and then override either one or both of the \n.to_representation()\n and \n.to_internal_value()\n methods.  These two methods are used to convert between the initial datatype, and a primitive, serializable datatype. Primitive datatypes will typically be any of a number, string, boolean, \ndate\n/\ntime\n/\ndatetime\n or \nNone\n. They may also be any list or dictionary like object that only contains other primitive objects. Other types might be supported, depending on the renderer that you are using.\n\n\nThe \n.to_representation()\n method is called to convert the initial datatype into a primitive, serializable datatype.\n\n\nThe \nto_internal_value()\n method is called to restore a primitive datatype into its internal python representation. This method should raise a \nserializers.ValidationError\n if the data is invalid.\n\n\nNote that the \nWritableField\n class that was present in version 2.x no longer exists. You should subclass \nField\n and override \nto_internal_value()\n if the field supports data input.\n\n\nExamples\n\n\nLet's look at an example of serializing a class that represents an RGB color value:\n\n\nclass Color(object):\n    \"\"\"\n    A color represented in the RGB colorspace.\n    \"\"\"\n    def __init__(self, red, green, blue):\n        assert(red \n= 0 and green \n= 0 and blue \n= 0)\n        assert(red \n 256 and green \n 256 and blue \n 256)\n        self.red, self.green, self.blue = red, green, blue\n\nclass ColorField(serializers.Field):\n    \"\"\"\n    Color objects are serialized into 'rgb(#, #, #)' notation.\n    \"\"\"\n    def to_representation(self, obj):\n        return \"rgb(%d, %d, %d)\" % (obj.red, obj.green, obj.blue)\n\n    def to_internal_value(self, data):\n        data = data.strip('rgb(').rstrip(')')\n        red, green, blue = [int(col) for col in data.split(',')]\n        return Color(red, green, blue)\n\n\n\nBy default field values are treated as mapping to an attribute on the object.  If you need to customize how the field value is accessed and set you need to override \n.get_attribute()\n and/or \n.get_value()\n.\n\n\nAs an example, let's create a field that can be used represent the class name of the object being serialized:\n\n\nclass ClassNameField(serializers.Field):\n    def get_attribute(self, obj):\n        # We pass the object instance onto `to_representation`,\n        # not just the field attribute.\n        return obj\n\n    def to_representation(self, obj):\n        \"\"\"\n        Serialize the object's class name.\n        \"\"\"\n        return obj.__class__.__name__\n\n\n\nRaising validation errors\n\n\nOur \nColorField\n class above currently does not perform any data validation.\nTo indicate invalid data, we should raise a \nserializers.ValidationError\n, like so:\n\n\ndef to_internal_value(self, data):\n    if not isinstance(data, six.text_type):\n        msg = 'Incorrect type. Expected a string, but got %s'\n        raise ValidationError(msg % type(data).__name__)\n\n    if not re.match(r'^rgb\\([0-9]+,[0-9]+,[0-9]+\\)$', data):\n        raise ValidationError('Incorrect format. Expected `rgb(#,#,#)`.')\n\n    data = data.strip('rgb(').rstrip(')')\n    red, green, blue = [int(col) for col in data.split(',')]\n\n    if any([col \n 255 or col \n 0 for col in (red, green, blue)]):\n        raise ValidationError('Value out of range. Must be between 0 and 255.')\n\n    return Color(red, green, blue)\n\n\n\nThe \n.fail()\n method is a shortcut for raising \nValidationError\n that takes a message string from the \nerror_messages\n dictionary. For example:\n\n\ndefault_error_messages = {\n    'incorrect_type': 'Incorrect type. Expected a string, but got {input_type}',\n    'incorrect_format': 'Incorrect format. Expected `rgb(#,#,#)`.',\n    'out_of_range': 'Value out of range. Must be between 0 and 255.'\n}\n\ndef to_internal_value(self, data):\n    if not isinstance(data, six.text_type):\n        msg = 'Incorrect type. Expected a string, but got %s'\n        self.fail('incorrect_type', input_type=type(data).__name__)\n\n    if not re.match(r'^rgb\\([0-9]+,[0-9]+,[0-9]+\\)$', data):\n        self.fail('incorrect_format')\n\n    data = data.strip('rgb(').rstrip(')')\n    red, green, blue = [int(col) for col in data.split(',')]\n\n    if any([col \n 255 or col \n 0 for col in (red, green, blue)]):\n        self.fail('out_of_range')\n\n    return Color(red, green, blue)\n\n\n\nThis style keeps you error messages more cleanly separated from your code, and should be preferred.\n\n\nThird party packages\n\n\nThe following third party packages are also available.\n\n\nDRF Compound Fields\n\n\nThe \ndrf-compound-fields\n package provides \"compound\" serializer fields, such as lists of simple values, which can be described by other fields rather than serializers with the \nmany=True\n option. Also provided are fields for typed dictionaries and values that can be either a specific type or a list of items of that type.\n\n\nDRF Extra Fields\n\n\nThe \ndrf-extra-fields\n package provides extra serializer fields for REST framework, including \nBase64ImageField\n and \nPointField\n classes.\n\n\ndjangrestframework-recursive\n\n\nthe \ndjangorestframework-recursive\n package provides a \nRecursiveField\n for serializing and deserializing recursive structures\n\n\ndjango-rest-framework-gis\n\n\nThe \ndjango-rest-framework-gis\n package provides geographic addons for django rest framework like a  \nGeometryField\n field and a GeoJSON serializer.\n\n\ndjango-rest-framework-hstore\n\n\nThe \ndjango-rest-framework-hstore\n package provides an \nHStoreField\n to support \ndjango-hstore\n \nDictionaryField\n model field.", 
+            "text": "Serializer fields\n\n\n\n\nEach field in a Form class is responsible not only for validating data, but also for \"cleaning\" it \n normalizing it to a consistent format.\n\n\n \nDjango documentation\n\n\n\n\nSerializer 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.\n\n\n\n\nNote:\n The serializer fields are declared in \nfields.py\n, but by convention you should import them using \nfrom rest_framework import serializers\n and refer to fields as \nserializers.\nFieldName\n.\n\n\n\n\nCore arguments\n\n\nEach serializer field class constructor takes at least these arguments.  Some Field classes take additional, field-specific arguments, but the following should always be accepted:\n\n\nread_only\n\n\nRead-only fields are included in the API output, but should not be included in the input during create or update operations. Any 'read_only' fields that are incorrectly included in the serializer input will be ignored.\n\n\nSet this to \nTrue\n to ensure that the field is used when serializing a representation, but is not used when creating or updating an instance during deserialization.\n\n\nDefaults to \nFalse\n\n\nwrite_only\n\n\nSet this to \nTrue\n to ensure that the field may be used when updating or creating an instance, but is not included when serializing the representation.\n\n\nDefaults to \nFalse\n\n\nrequired\n\n\nNormally an error will be raised if a field is not supplied during deserialization.\nSet to false if this field is not required to be present during deserialization.\n\n\nSetting this to \nFalse\n also allows the object attribute or dictionary key to be omitted from output when serializing the instance. If the key is not present it will simply not be included in the output representation.\n\n\nDefaults to \nTrue\n.\n\n\nallow_null\n\n\nNormally an error will be raised if \nNone\n is passed to a serializer field. Set this keyword argument to \nTrue\n if \nNone\n should be considered a valid value.\n\n\nDefaults to \nFalse\n\n\ndefault\n\n\nIf set, this gives the default value that will be used for the field if no input value is supplied.  If not set the default behavior is to not populate the attribute at all.\n\n\nMay be set to a function or other callable, in which case the value will be evaluated each time it is used.\n\n\nNote that setting a \ndefault\n value implies that the field is not required. Including both the \ndefault\n and \nrequired\n keyword arguments is invalid and will raise an error.\n\n\nsource\n\n\nThe name of the attribute that will be used to populate the field.  May be a method that only takes a \nself\n argument, such as \nURLField('get_absolute_url')\n, or may use dotted notation to traverse attributes, such as \nEmailField(source='user.email')\n.\n\n\nThe value \nsource='*'\n has a special meaning, and is used to indicate that the entire object should be passed through to the field.  This can be useful for creating nested representations, or for fields which require access to the complete object in order to determine the output representation.\n\n\nDefaults to the name of the field.\n\n\nvalidators\n\n\nA list of validator functions which should be applied to the incoming field input, and which either raise a validation error or simply return. Validator functions should typically raise \nserializers.ValidationError\n, but Django's built-in \nValidationError\n is also supported for compatibility with validators defined in the Django codebase or third party Django packages.\n\n\nerror_messages\n\n\nA dictionary of error codes to error messages.\n\n\nlabel\n\n\nA short text string that may be used as the name of the field in HTML form fields or other descriptive elements.\n\n\nhelp_text\n\n\nA text string that may be used as a description of the field in HTML form fields or other descriptive elements.\n\n\ninitial\n\n\nA value that should be used for pre-populating the value of HTML form fields.\n\n\nstyle\n\n\nA dictionary of key-value pairs that can be used to control how renderers should render the field. The API for this should still be considered experimental, and will be formalized with the 3.1 release.\n\n\nTwo options are currently used in HTML form generation, \n'input_type'\n and \n'base_template'\n.\n\n\n# Use \ninput type=\"password\"\n for the input.\npassword = serializers.CharField(\n    style={'input_type': 'password'}\n)\n\n# Use a radio input instead of a select input.\ncolor_channel = serializers.ChoiceField(\n    choices=['red', 'green', 'blue']\n    style = {'base_template': 'radio.html'}\n}\n\n\n\nNote\n: The \nstyle\n argument replaces the old-style version 2.x \nwidget\n keyword argument. Because REST framework 3 now uses templated HTML form generation, the \nwidget\n option that was used to support Django built-in widgets can no longer be supported. Version 3.3 is planned to include public API support for customizing HTML form generation.\n\n\n\n\nBoolean fields\n\n\nBooleanField\n\n\nA boolean representation.\n\n\nWhen using HTML encoded form input be aware that omitting a value will always be treated as setting a field to \nFalse\n, even if it has a \ndefault=True\n 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.\n\n\nCorresponds to \ndjango.db.models.fields.BooleanField\n.\n\n\nSignature:\n \nBooleanField()\n\n\nNullBooleanField\n\n\nA boolean representation that also accepts \nNone\n as a valid value.\n\n\nCorresponds to \ndjango.db.models.fields.NullBooleanField\n.\n\n\nSignature:\n \nNullBooleanField()\n\n\n\n\nString fields\n\n\nCharField\n\n\nA text representation. Optionally validates the text to be shorter than \nmax_length\n and longer than \nmin_length\n.\n\n\nCorresponds to \ndjango.db.models.fields.CharField\n or \ndjango.db.models.fields.TextField\n.\n\n\nSignature:\n \nCharField(max_length=None, min_length=None, allow_blank=False, trim_whitespace=True)\n\n\n\n\nmax_length\n - Validates that the input contains no more than this number of characters.\n\n\nmin_length\n - Validates that the input contains no fewer than this number of characters.\n\n\nallow_blank\n - If set to \nTrue\n then the empty string should be considered a valid value. If set to \nFalse\n then the empty string is considered invalid and will raise a validation error. Defaults to \nFalse\n.\n\n\ntrim_whitespace\n - If set to \nTrue\n then leading and trailing whitespace is trimmed. Defaults to \nTrue\n.\n\n\n\n\nThe \nallow_null\n option is also available for string fields, although its usage is discouraged in favor of \nallow_blank\n. It is valid to set both \nallow_blank=True\n and \nallow_null=True\n, but doing so means that there will be two differing types of empty value permissible for string representations, which can lead to data inconsistencies and subtle application bugs.\n\n\nEmailField\n\n\nA text representation, validates the text to be a valid e-mail address.\n\n\nCorresponds to \ndjango.db.models.fields.EmailField\n\n\nSignature:\n \nEmailField(max_length=None, min_length=None, allow_blank=False)\n\n\nRegexField\n\n\nA text representation, that validates the given value matches against a certain regular expression.\n\n\nCorresponds to \ndjango.forms.fields.RegexField\n.\n\n\nSignature:\n \nRegexField(regex, max_length=None, min_length=None, allow_blank=False)\n\n\nThe mandatory \nregex\n argument may either be a string, or a compiled python regular expression object.\n\n\nUses Django's \ndjango.core.validators.RegexValidator\n for validation.\n\n\nSlugField\n\n\nA \nRegexField\n that validates the input against the pattern \n[a-zA-Z0-9_-]+\n.\n\n\nCorresponds to \ndjango.db.models.fields.SlugField\n.\n\n\nSignature:\n \nSlugField(max_length=50, min_length=None, allow_blank=False)\n\n\nURLField\n\n\nA \nRegexField\n that validates the input against a URL matching pattern. Expects fully qualified URLs of the form \nhttp://\nhost\n/\npath\n.\n\n\nCorresponds to \ndjango.db.models.fields.URLField\n.  Uses Django's \ndjango.core.validators.URLValidator\n for validation.\n\n\nSignature:\n \nURLField(max_length=200, min_length=None, allow_blank=False)\n\n\nUUIDField\n\n\nA field that ensures the input is a valid UUID string. The \nto_internal_value\n method will return a \nuuid.UUID\n instance. On output the field will return a string in the canonical hyphenated format, for example:\n\n\n\"de305d54-75b4-431b-adb2-eb6b9e546013\"\n\n\n\nSignature:\n \nUUIDField(format='hex_verbose')\n\n\n\n\nformat\n: Determines the representation format of the uuid value\n\n\n'hex_verbose'\n - The cannoncical hex representation, including hyphens: \n\"5ce0e9a5-5ffa-654b-cee0-1238041fb31a\"\n\n\n'hex'\n - The compact hex representation of the UUID, not including hyphens: \n\"5ce0e9a55ffa654bcee01238041fb31a\"\n\n\n'int'\n - A 128 bit integer representation of the UUID: \n\"123456789012312313134124512351145145114\"\n\n\n'urn'\n - RFC 4122 URN representation of the UUID: \n\"urn:uuid:5ce0e9a5-5ffa-654b-cee0-1238041fb31a\"\n\n  Changing the \nformat\n parameters only affects representation values. All formats are accepted by \nto_internal_value\n\n\n\n\n\n\n\n\nFilePathField\n\n\nA field whose choices are limited to the filenames in a certain directory on the filesystem\n\n\nCorresponds to \ndjango.forms.fields.FilePathField\n.\n\n\nSignature:\n \nFilePathField(path, match=None, recursive=False, allow_files=True, allow_folders=False, required=None, **kwargs)\n\n\n\n\npath\n - The absolute filesystem path to a directory from which this FilePathField should get its choice.\n\n\nmatch\n - A regular expression, as a string, that FilePathField will use to filter filenames.\n\n\nrecursive\n - Specifies whether all subdirectories of path should be included.  Default is \nFalse\n.\n\n\nallow_files\n - Specifies whether files in the specified location should be included. Default is \nTrue\n. Either this or \nallow_folders\n must be \nTrue\n.\n\n\nallow_folders\n - Specifies whether folders in the specified location should be included. Default is \nFalse\n. Either this or \nallow_files\n must be \nTrue\n.\n\n\n\n\nIPAddressField\n\n\nA field that ensures the input is a valid IPv4 or IPv6 string.\n\n\nCorresponds to \ndjango.forms.fields.IPAddressField\n and \ndjango.forms.fields.GenericIPAddressField\n.\n\n\nSignature\n: \nIPAddressField(protocol='both', unpack_ipv4=False, **options)\n\n\n\n\nprotocol\n Limits valid inputs to the specified protocol. Accepted values are 'both' (default), 'IPv4' or 'IPv6'. Matching is case insensitive.\n\n\nunpack_ipv4\n Unpacks IPv4 mapped addresses like ::ffff:192.0.2.1. If this option is enabled that address would be unpacked to 192.0.2.1. Default is disabled. Can only be used when protocol is set to 'both'.\n\n\n\n\n\n\nNumeric fields\n\n\nIntegerField\n\n\nAn integer representation.\n\n\nCorresponds to \ndjango.db.models.fields.IntegerField\n, \ndjango.db.models.fields.SmallIntegerField\n, \ndjango.db.models.fields.PositiveIntegerField\n and \ndjango.db.models.fields.PositiveSmallIntegerField\n.\n\n\nSignature\n: \nIntegerField(max_value=None, min_value=None)\n\n\n\n\nmax_value\n Validate that the number provided is no greater than this value.\n\n\nmin_value\n Validate that the number provided is no less than this value.\n\n\n\n\nFloatField\n\n\nA floating point representation.\n\n\nCorresponds to \ndjango.db.models.fields.FloatField\n.\n\n\nSignature\n: \nFloatField(max_value=None, min_value=None)\n\n\n\n\nmax_value\n Validate that the number provided is no greater than this value.\n\n\nmin_value\n Validate that the number provided is no less than this value.\n\n\n\n\nDecimalField\n\n\nA decimal representation, represented in Python by a \nDecimal\n instance.\n\n\nCorresponds to \ndjango.db.models.fields.DecimalField\n.\n\n\nSignature\n: \nDecimalField(max_digits, decimal_places, coerce_to_string=None, max_value=None, min_value=None)\n\n\n\n\nmax_digits\n The maximum number of digits allowed in the number. Note that this number must be greater than or equal to decimal_places.\n\n\ndecimal_places\n The number of decimal places to store with the number.\n\n\ncoerce_to_string\n Set to \nTrue\n if string values should be returned for the representation, or \nFalse\n if \nDecimal\n objects should be returned. Defaults to the same value as the \nCOERCE_DECIMAL_TO_STRING\n settings key, which will be \nTrue\n unless overridden. If \nDecimal\n objects are returned by the serializer, then the final output format will be determined by the renderer.\n\n\nmax_value\n Validate that the number provided is no greater than this value.\n\n\nmin_value\n Validate that the number provided is no less than this value.\n\n\n\n\nExample usage\n\n\nTo validate numbers up to 999 with a resolution of 2 decimal places, you would use:\n\n\nserializers.DecimalField(max_digits=5, decimal_places=2)\n\n\n\nAnd to validate numbers up to anything less than one billion with a resolution of 10 decimal places:\n\n\nserializers.DecimalField(max_digits=19, decimal_places=10)\n\n\n\nThis field also takes an optional argument, \ncoerce_to_string\n. If set to \nTrue\n the representation will be output as a string. If set to \nFalse\n the representation will be left as a \nDecimal\n instance and the final representation will be determined by the renderer.\n\n\nIf unset, this will default to the same value as the \nCOERCE_DECIMAL_TO_STRING\n setting, which is \nTrue\n unless set otherwise.\n\n\n\n\nDate and time fields\n\n\nDateTimeField\n\n\nA date and time representation.\n\n\nCorresponds to \ndjango.db.models.fields.DateTimeField\n.\n\n\nSignature:\n \nDateTimeField(format=None, input_formats=None)\n\n\n\n\nformat\n - A string representing the output format.  If not specified, this defaults to the same value as the \nDATETIME_FORMAT\n settings key, which will be \n'iso-8601'\n unless set. Setting to a format string indicates that \nto_representation\n return values should be coerced to string output. Format strings are described below. Setting this value to \nNone\n indicates that Python \ndatetime\n objects should be returned by \nto_representation\n. In this case the datetime encoding will be determined by the renderer.\n\n\ninput_formats\n - A list of strings representing the input formats which may be used to parse the date.  If not specified, the \nDATETIME_INPUT_FORMATS\n setting will be used, which defaults to \n['iso-8601']\n.\n\n\n\n\nDateTimeField\n format strings.\n\n\nFormat strings may either be \nPython strftime formats\n which explicitly specify the format, or the special string \n'iso-8601'\n, which indicates that \nISO 8601\n style datetimes should be used. (eg \n'2013-01-29T12:34:56.000000Z'\n)\n\n\nWhen a value of \nNone\n is used for the format \ndatetime\n objects will be returned by \nto_representation\n and the final output representation will determined by the renderer class.\n\n\nIn the case of JSON this means the default datetime representation uses the \nECMA 262 date time string specification\n.  This is a subset of ISO 8601 which uses millisecond precision, and includes the 'Z' suffix for the UTC timezone, for example: \n2013-01-29T12:34:56.123Z\n.\n\n\nauto_now\n and \nauto_now_add\n model fields.\n\n\nWhen using \nModelSerializer\n or \nHyperlinkedModelSerializer\n, note that any model fields with \nauto_now=True\n or \nauto_now_add=True\n will use serializer fields that are \nread_only=True\n by default.\n\n\nIf you want to override this behavior, you'll need to declare the \nDateTimeField\n explicitly on the serializer.  For example:\n\n\nclass CommentSerializer(serializers.ModelSerializer):\n    created = serializers.DateTimeField()\n\n    class Meta:\n        model = Comment\n\n\n\nDateField\n\n\nA date representation.\n\n\nCorresponds to \ndjango.db.models.fields.DateField\n\n\nSignature:\n \nDateField(format=None, input_formats=None)\n\n\n\n\nformat\n - A string representing the output format.  If not specified, this defaults to the same value as the \nDATE_FORMAT\n settings key, which will be \n'iso-8601'\n unless set. Setting to a format string indicates that \nto_representation\n return values should be coerced to string output. Format strings are described below. Setting this value to \nNone\n indicates that Python \ndate\n objects should be returned by \nto_representation\n. In this case the date encoding will be determined by the renderer.\n\n\ninput_formats\n - A list of strings representing the input formats which may be used to parse the date.  If not specified, the \nDATE_INPUT_FORMATS\n setting will be used, which defaults to \n['iso-8601']\n.\n\n\n\n\nDateField\n format strings\n\n\nFormat strings may either be \nPython strftime formats\n which explicitly specify the format, or the special string \n'iso-8601'\n, which indicates that \nISO 8601\n style dates should be used. (eg \n'2013-01-29'\n)\n\n\nTimeField\n\n\nA time representation.\n\n\nCorresponds to \ndjango.db.models.fields.TimeField\n\n\nSignature:\n \nTimeField(format=None, input_formats=None)\n\n\n\n\nformat\n - A string representing the output format.  If not specified, this defaults to the same value as the \nTIME_FORMAT\n settings key, which will be \n'iso-8601'\n unless set. Setting to a format string indicates that \nto_representation\n return values should be coerced to string output. Format strings are described below. Setting this value to \nNone\n indicates that Python \ntime\n objects should be returned by \nto_representation\n. In this case the time encoding will be determined by the renderer.\n\n\ninput_formats\n - A list of strings representing the input formats which may be used to parse the date.  If not specified, the \nTIME_INPUT_FORMATS\n setting will be used, which defaults to \n['iso-8601']\n.\n\n\n\n\nTimeField\n format strings\n\n\nFormat strings may either be \nPython strftime formats\n which explicitly specify the format, or the special string \n'iso-8601'\n, which indicates that \nISO 8601\n style times should be used. (eg \n'12:34:56.000000'\n)\n\n\nDurationField\n\n\nA Duration representation.\nCorresponds to \ndjango.db.models.fields.DurationField\n\n\nThe \nvalidated_data\n for these fields will contain a \ndatetime.timedelta\n instance.\nThe representation is a string following this format \n'[DD] [HH:[MM:]]ss[.uuuuuu]'\n.\n\n\nNote:\n This field is only available with Django versions \n= 1.8.\n\n\nSignature:\n \nDurationField()\n\n\n\n\nChoice selection fields\n\n\nChoiceField\n\n\nA field that can accept a value out of a limited set of choices.\n\n\nUsed by \nModelSerializer\n to automatically generate fields if the corresponding model field includes a \nchoices=\u2026\n argument.\n\n\nSignature:\n \nChoiceField(choices)\n\n\n\n\nchoices\n - A list of valid values, or a list of \n(key, display_name)\n tuples.\n\n\nallow_blank\n - If set to \nTrue\n then the empty string should be considered a valid value. If set to \nFalse\n then the empty string is considered invalid and will raise a validation error. Defaults to \nFalse\n.\n\n\nhtml_cutoff\n - If set this will be the maximum number of choices that will be displayed by a HTML select drop down. Can be used to ensure that automatically generated ChoiceFields with very large possible selections do not prevent a template from rendering. Defaults to \nNone\n.\n\n\nhtml_cutoff_text\n - If set this will display a textual indicator if the maximum number of items have been cutoff in an HTML select drop down. Defaults to \n\"More than {count} items\u2026\"\n\n\n\n\nBoth the \nallow_blank\n and \nallow_null\n are valid options on \nChoiceField\n, although it is highly recommended that you only use one and not both. \nallow_blank\n should be preferred for textual choices, and \nallow_null\n should be preferred for numeric or other non-textual choices.\n\n\nMultipleChoiceField\n\n\nA field that can accept a set of zero, one or many values, chosen from a limited set of choices. Takes a single mandatory argument. \nto_internal_value\n returns a \nset\n containing the selected values.\n\n\nSignature:\n \nMultipleChoiceField(choices)\n\n\n\n\nchoices\n - A list of valid values, or a list of \n(key, display_name)\n tuples.\n\n\nallow_blank\n - If set to \nTrue\n then the empty string should be considered a valid value. If set to \nFalse\n then the empty string is considered invalid and will raise a validation error. Defaults to \nFalse\n.\n\n\nhtml_cutoff\n - If set this will be the maximum number of choices that will be displayed by a HTML select drop down. Can be used to ensure that automatically generated ChoiceFields with very large possible selections do not prevent a template from rendering. Defaults to \nNone\n.\n\n\nhtml_cutoff_text\n - If set this will display a textual indicator if the maximum number of items have been cutoff in an HTML select drop down. Defaults to \n\"More than {count} items\u2026\"\n\n\n\n\nAs with \nChoiceField\n, both the \nallow_blank\n and \nallow_null\n options are valid, although it is highly recommended that you only use one and not both. \nallow_blank\n should be preferred for textual choices, and \nallow_null\n should be preferred for numeric or other non-textual choices.\n\n\n\n\nFile upload fields\n\n\nParsers and file uploads.\n\n\nThe \nFileField\n and \nImageField\n classes are only suitable for use with \nMultiPartParser\n or \nFileUploadParser\n. Most parsers, such as e.g. JSON don't support file uploads.\nDjango's regular \nFILE_UPLOAD_HANDLERS\n are used for handling uploaded files.\n\n\nFileField\n\n\nA file representation.  Performs Django's standard FileField validation.\n\n\nCorresponds to \ndjango.forms.fields.FileField\n.\n\n\nSignature:\n \nFileField(max_length=None, allow_empty_file=False, use_url=UPLOADED_FILES_USE_URL)\n\n\n\n\nmax_length\n - Designates the maximum length for the file name.\n\n\nallow_empty_file\n - Designates if empty files are allowed.\n\n\nuse_url\n - If set to \nTrue\n then URL string values will be used for the output representation. If set to \nFalse\n then filename string values will be used for the output representation. Defaults to the value of the \nUPLOADED_FILES_USE_URL\n settings key, which is \nTrue\n unless set otherwise.\n\n\n\n\nImageField\n\n\nAn image representation. Validates the uploaded file content as matching a known image format.\n\n\nCorresponds to \ndjango.forms.fields.ImageField\n.\n\n\nSignature:\n \nImageField(max_length=None, allow_empty_file=False, use_url=UPLOADED_FILES_USE_URL)\n\n\n\n\nmax_length\n - Designates the maximum length for the file name.\n\n\nallow_empty_file\n - Designates if empty files are allowed.\n\n\nuse_url\n - If set to \nTrue\n then URL string values will be used for the output representation. If set to \nFalse\n then filename string values will be used for the output representation. Defaults to the value of the \nUPLOADED_FILES_USE_URL\n settings key, which is \nTrue\n unless set otherwise.\n\n\n\n\nRequires either the \nPillow\n package or \nPIL\n package.  The \nPillow\n package is recommended, as \nPIL\n is no longer actively maintained.\n\n\n\n\nComposite fields\n\n\nListField\n\n\nA field class that validates a list of objects.\n\n\nSignature\n: \nListField(child)\n\n\n\n\nchild\n - A field instance that should be used for validating the objects in the list. If this argument is not provided then objects in the list will not be validated.\n\n\n\n\nFor example, to validate a list of integers you might use something like the following:\n\n\nscores = serializers.ListField(\n   child=serializers.IntegerField(min_value=0, max_value=100)\n)\n\n\n\nThe \nListField\n class also supports a declarative style that allows you to write reusable list field classes.\n\n\nclass StringListField(serializers.ListField):\n    child = serializers.CharField()\n\n\n\nWe can now reuse our custom \nStringListField\n class throughout our application, without having to provide a \nchild\n argument to it.\n\n\nDictField\n\n\nA field class that validates a dictionary of objects. The keys in \nDictField\n are always assumed to be string values.\n\n\nSignature\n: \nDictField(child)\n\n\n\n\nchild\n - A field instance that should be used for validating the values in the dictionary. If this argument is not provided then values in the mapping will not be validated.\n\n\n\n\nFor example, to create a field that validates a mapping of strings to strings, you would write something like this:\n\n\ndocument = DictField(child=CharField())\n\n\n\nYou can also use the declarative style, as with \nListField\n. For example:\n\n\nclass DocumentField(DictField):\n    child = CharField()\n\n\n\n\n\nMiscellaneous fields\n\n\nReadOnlyField\n\n\nA field class that simply returns the value of the field without modification.\n\n\nThis field is used by default with \nModelSerializer\n when including field names that relate to an attribute rather than a model field.\n\n\nSignature\n: \nReadOnlyField()\n\n\nFor example, is \nhas_expired\n was a property on the \nAccount\n model, then the following serializer would automatically generate it as a \nReadOnlyField\n:\n\n\nclass AccountSerializer(serializers.ModelSerializer):\n    class Meta:\n        model = Account\n        fields = ('id', 'account_name', 'has_expired')\n\n\n\nHiddenField\n\n\nA field class that does not take a value based on user input, but instead takes its value from a default value or callable.\n\n\nSignature\n: \nHiddenField()\n\n\nFor example, to include a field that always provides the current time as part of the serializer validated data, you would use the following:\n\n\nmodified = serializers.HiddenField(default=timezone.now)\n\n\n\nThe \nHiddenField\n class is usually only needed if you have some validation that needs to run based on some pre-provided field values, but you do not want to expose all of those fields to the end user.\n\n\nFor further examples on \nHiddenField\n see the \nvalidators\n documentation.\n\n\nModelField\n\n\nA generic field that can be tied to any arbitrary model field. The \nModelField\n class delegates the task of serialization/deserialization to its associated model field.  This field can be used to create serializer fields for custom model fields, without having to create a new custom serializer field.\n\n\nThis field is used by \nModelSerializer\n to correspond to custom model field classes.\n\n\nSignature:\n \nModelField(model_field=\nDjango ModelField instance\n)\n\n\nThe \nModelField\n class is generally intended for internal use, but can be used by your API if needed.  In order to properly instantiate a \nModelField\n, it must be passed a field that is attached to an instantiated model.  For example: \nModelField(model_field=MyModel()._meta.get_field('custom_field'))\n\n\nSerializerMethodField\n\n\nThis is a read-only field. It gets its value by calling a method on the serializer class it is attached to. It can be used to add any sort of data to the serialized representation of your object.\n\n\nSignature\n: \nSerializerMethodField(method_name=None)\n\n\n\n\nmethod_name\n - The name of the method on the serializer to be called. If not included this defaults to \nget_\nfield_name\n.\n\n\n\n\nThe serializer method referred to by the \nmethod_name\n argument should accept a single argument (in addition to \nself\n), which is the object being serialized. It should return whatever you want to be included in the serialized representation of the object. For example:\n\n\nfrom django.contrib.auth.models import User\nfrom django.utils.timezone import now\nfrom rest_framework import serializers\n\nclass UserSerializer(serializers.ModelSerializer):\n    days_since_joined = serializers.SerializerMethodField()\n\n    class Meta:\n        model = User\n\n    def get_days_since_joined(self, obj):\n        return (now() - obj.date_joined).days\n\n\n\n\n\nCustom fields\n\n\nIf you want to create a custom field, you'll need to subclass \nField\n and then override either one or both of the \n.to_representation()\n and \n.to_internal_value()\n methods.  These two methods are used to convert between the initial datatype, and a primitive, serializable datatype. Primitive datatypes will typically be any of a number, string, boolean, \ndate\n/\ntime\n/\ndatetime\n or \nNone\n. They may also be any list or dictionary like object that only contains other primitive objects. Other types might be supported, depending on the renderer that you are using.\n\n\nThe \n.to_representation()\n method is called to convert the initial datatype into a primitive, serializable datatype.\n\n\nThe \nto_internal_value()\n method is called to restore a primitive datatype into its internal python representation. This method should raise a \nserializers.ValidationError\n if the data is invalid.\n\n\nNote that the \nWritableField\n class that was present in version 2.x no longer exists. You should subclass \nField\n and override \nto_internal_value()\n if the field supports data input.\n\n\nExamples\n\n\nLet's look at an example of serializing a class that represents an RGB color value:\n\n\nclass Color(object):\n    \"\"\"\n    A color represented in the RGB colorspace.\n    \"\"\"\n    def __init__(self, red, green, blue):\n        assert(red \n= 0 and green \n= 0 and blue \n= 0)\n        assert(red \n 256 and green \n 256 and blue \n 256)\n        self.red, self.green, self.blue = red, green, blue\n\nclass ColorField(serializers.Field):\n    \"\"\"\n    Color objects are serialized into 'rgb(#, #, #)' notation.\n    \"\"\"\n    def to_representation(self, obj):\n        return \"rgb(%d, %d, %d)\" % (obj.red, obj.green, obj.blue)\n\n    def to_internal_value(self, data):\n        data = data.strip('rgb(').rstrip(')')\n        red, green, blue = [int(col) for col in data.split(',')]\n        return Color(red, green, blue)\n\n\n\nBy default field values are treated as mapping to an attribute on the object.  If you need to customize how the field value is accessed and set you need to override \n.get_attribute()\n and/or \n.get_value()\n.\n\n\nAs an example, let's create a field that can be used represent the class name of the object being serialized:\n\n\nclass ClassNameField(serializers.Field):\n    def get_attribute(self, obj):\n        # We pass the object instance onto `to_representation`,\n        # not just the field attribute.\n        return obj\n\n    def to_representation(self, obj):\n        \"\"\"\n        Serialize the object's class name.\n        \"\"\"\n        return obj.__class__.__name__\n\n\n\nRaising validation errors\n\n\nOur \nColorField\n class above currently does not perform any data validation.\nTo indicate invalid data, we should raise a \nserializers.ValidationError\n, like so:\n\n\ndef to_internal_value(self, data):\n    if not isinstance(data, six.text_type):\n        msg = 'Incorrect type. Expected a string, but got %s'\n        raise ValidationError(msg % type(data).__name__)\n\n    if not re.match(r'^rgb\\([0-9]+,[0-9]+,[0-9]+\\)$', data):\n        raise ValidationError('Incorrect format. Expected `rgb(#,#,#)`.')\n\n    data = data.strip('rgb(').rstrip(')')\n    red, green, blue = [int(col) for col in data.split(',')]\n\n    if any([col \n 255 or col \n 0 for col in (red, green, blue)]):\n        raise ValidationError('Value out of range. Must be between 0 and 255.')\n\n    return Color(red, green, blue)\n\n\n\nThe \n.fail()\n method is a shortcut for raising \nValidationError\n that takes a message string from the \nerror_messages\n dictionary. For example:\n\n\ndefault_error_messages = {\n    'incorrect_type': 'Incorrect type. Expected a string, but got {input_type}',\n    'incorrect_format': 'Incorrect format. Expected `rgb(#,#,#)`.',\n    'out_of_range': 'Value out of range. Must be between 0 and 255.'\n}\n\ndef to_internal_value(self, data):\n    if not isinstance(data, six.text_type):\n        msg = 'Incorrect type. Expected a string, but got %s'\n        self.fail('incorrect_type', input_type=type(data).__name__)\n\n    if not re.match(r'^rgb\\([0-9]+,[0-9]+,[0-9]+\\)$', data):\n        self.fail('incorrect_format')\n\n    data = data.strip('rgb(').rstrip(')')\n    red, green, blue = [int(col) for col in data.split(',')]\n\n    if any([col \n 255 or col \n 0 for col in (red, green, blue)]):\n        self.fail('out_of_range')\n\n    return Color(red, green, blue)\n\n\n\nThis style keeps you error messages more cleanly separated from your code, and should be preferred.\n\n\nThird party packages\n\n\nThe following third party packages are also available.\n\n\nDRF Compound Fields\n\n\nThe \ndrf-compound-fields\n package provides \"compound\" serializer fields, such as lists of simple values, which can be described by other fields rather than serializers with the \nmany=True\n option. Also provided are fields for typed dictionaries and values that can be either a specific type or a list of items of that type.\n\n\nDRF Extra Fields\n\n\nThe \ndrf-extra-fields\n package provides extra serializer fields for REST framework, including \nBase64ImageField\n and \nPointField\n classes.\n\n\ndjangrestframework-recursive\n\n\nthe \ndjangorestframework-recursive\n package provides a \nRecursiveField\n for serializing and deserializing recursive structures\n\n\ndjango-rest-framework-gis\n\n\nThe \ndjango-rest-framework-gis\n package provides geographic addons for django rest framework like a  \nGeometryField\n field and a GeoJSON serializer.\n\n\ndjango-rest-framework-hstore\n\n\nThe \ndjango-rest-framework-hstore\n package provides an \nHStoreField\n to support \ndjango-hstore\n \nDictionaryField\n model field.", 
             "title": "Serializer fields"
         }, 
         {
@@ -1257,7 +1257,7 @@
         }, 
         {
             "location": "/api-guide/fields/#core-arguments", 
-            "text": "Each serializer field class constructor takes at least these arguments.  Some Field classes take additional, field-specific arguments, but the following should always be accepted:  read_only  Read-only fields are included in the API output, but should not be included in the input during create or update operations. Any 'read_only' fields that are incorrectly included in the serializer input will be ignored.  Set this to  True  to ensure that the field is used when serializing a representation, but is not used when creating or updating an instance during deserialization.  Defaults to  False  write_only  Set this to  True  to ensure that the field may be used when updating or creating an instance, but is not included when serializing the representation.  Defaults to  False  required  Normally an error will be raised if a field is not supplied during deserialization.\nSet to false if this field is not required to be present during deserialization.  Setting this to  False  also allows the object attribute or dictionary key to be omitted from output when serializing the instance. If the key is not present it will simply not be included in the output representation.  Defaults to  True .  allow_null  Normally an error will be raised if  None  is passed to a serializer field. Set this keyword argument to  True  if  None  should be considered a valid value.  Defaults to  False  default  If set, this gives the default value that will be used for the field if no input value is supplied.  If not set the default behavior is to not populate the attribute at all.  May be set to a function or other callable, in which case the value will be evaluated each time it is used.  Note that setting a  default  value implies that the field is not required. Including both the  default  and  required  keyword arguments is invalid and will raise an error.  source  The name of the attribute that will be used to populate the field.  May be a method that only takes a  self  argument, such as  URLField('get_absolute_url') , or may use dotted notation to traverse attributes, such as  EmailField(source='user.email') .  The value  source='*'  has a special meaning, and is used to indicate that the entire object should be passed through to the field.  This can be useful for creating nested representations, or for fields which require access to the complete object in order to determine the output representation.  Defaults to the name of the field.  validators  A list of validator functions which should be applied to the incoming field input, and which either raise a validation error or simply return. Validator functions should typically raise  serializers.ValidationError , but Django's built-in  ValidationError  is also supported for compatibility with validators defined in the Django codebase or third party Django packages.  error_messages  A dictionary of error codes to error messages.  label  A short text string that may be used as the name of the field in HTML form fields or other descriptive elements.  help_text  A text string that may be used as a description of the field in HTML form fields or other descriptive elements.  initial  A value that should be used for pre-populating the value of HTML form fields.  style  A dictionary of key-value pairs that can be used to control how renderers should render the field. The API for this should still be considered experimental, and will be formalized with the 3.1 release.  Two options are currently used in HTML form generation,  'input_type'  and  'base_template' .  # Use  input type=\"password\"  for the input.\npassword = serializers.CharField(\n    style={'input_type': 'password'}\n)\n\n# Use a radio input instead of a select input.\ncolor_channel = serializers.ChoiceField(\n    choices=['red', 'green', 'blue']\n    style = {'base_template': 'radio.html'}\n}  Note : The  style  argument replaces the old-style version 2.x  widget  keyword argument. Because REST framework 3 now uses templated HTML form generation, the  widget  option that was used to support Django built-in widgets can no longer be supported. Version 3.1 is planned to include public API support for customizing HTML form generation.", 
+            "text": "Each serializer field class constructor takes at least these arguments.  Some Field classes take additional, field-specific arguments, but the following should always be accepted:  read_only  Read-only fields are included in the API output, but should not be included in the input during create or update operations. Any 'read_only' fields that are incorrectly included in the serializer input will be ignored.  Set this to  True  to ensure that the field is used when serializing a representation, but is not used when creating or updating an instance during deserialization.  Defaults to  False  write_only  Set this to  True  to ensure that the field may be used when updating or creating an instance, but is not included when serializing the representation.  Defaults to  False  required  Normally an error will be raised if a field is not supplied during deserialization.\nSet to false if this field is not required to be present during deserialization.  Setting this to  False  also allows the object attribute or dictionary key to be omitted from output when serializing the instance. If the key is not present it will simply not be included in the output representation.  Defaults to  True .  allow_null  Normally an error will be raised if  None  is passed to a serializer field. Set this keyword argument to  True  if  None  should be considered a valid value.  Defaults to  False  default  If set, this gives the default value that will be used for the field if no input value is supplied.  If not set the default behavior is to not populate the attribute at all.  May be set to a function or other callable, in which case the value will be evaluated each time it is used.  Note that setting a  default  value implies that the field is not required. Including both the  default  and  required  keyword arguments is invalid and will raise an error.  source  The name of the attribute that will be used to populate the field.  May be a method that only takes a  self  argument, such as  URLField('get_absolute_url') , or may use dotted notation to traverse attributes, such as  EmailField(source='user.email') .  The value  source='*'  has a special meaning, and is used to indicate that the entire object should be passed through to the field.  This can be useful for creating nested representations, or for fields which require access to the complete object in order to determine the output representation.  Defaults to the name of the field.  validators  A list of validator functions which should be applied to the incoming field input, and which either raise a validation error or simply return. Validator functions should typically raise  serializers.ValidationError , but Django's built-in  ValidationError  is also supported for compatibility with validators defined in the Django codebase or third party Django packages.  error_messages  A dictionary of error codes to error messages.  label  A short text string that may be used as the name of the field in HTML form fields or other descriptive elements.  help_text  A text string that may be used as a description of the field in HTML form fields or other descriptive elements.  initial  A value that should be used for pre-populating the value of HTML form fields.  style  A dictionary of key-value pairs that can be used to control how renderers should render the field. The API for this should still be considered experimental, and will be formalized with the 3.1 release.  Two options are currently used in HTML form generation,  'input_type'  and  'base_template' .  # Use  input type=\"password\"  for the input.\npassword = serializers.CharField(\n    style={'input_type': 'password'}\n)\n\n# Use a radio input instead of a select input.\ncolor_channel = serializers.ChoiceField(\n    choices=['red', 'green', 'blue']\n    style = {'base_template': 'radio.html'}\n}  Note : The  style  argument replaces the old-style version 2.x  widget  keyword argument. Because REST framework 3 now uses templated HTML form generation, the  widget  option that was used to support Django built-in widgets can no longer be supported. Version 3.3 is planned to include public API support for customizing HTML form generation.", 
             "title": "Core arguments"
         }, 
         {
@@ -1372,12 +1372,12 @@
         }, 
         {
             "location": "/api-guide/fields/#choicefield", 
-            "text": "A field that can accept a value out of a limited set of choices.  Used by  ModelSerializer  to automatically generate fields if the corresponding model field includes a  choices=\u2026  argument.  Signature:   ChoiceField(choices)   choices  - A list of valid values, or a list of  (key, display_name)  tuples.  allow_blank  - If set to  True  then the empty string should be considered a valid value. If set to  False  then the empty string is considered invalid and will raise a validation error. Defaults to  False .   Both the  allow_blank  and  allow_null  are valid options on  ChoiceField , although it is highly recommended that you only use one and not both.  allow_blank  should be preferred for textual choices, and  allow_null  should be preferred for numeric or other non-textual choices.", 
+            "text": "A field that can accept a value out of a limited set of choices.  Used by  ModelSerializer  to automatically generate fields if the corresponding model field includes a  choices=\u2026  argument.  Signature:   ChoiceField(choices)   choices  - A list of valid values, or a list of  (key, display_name)  tuples.  allow_blank  - If set to  True  then the empty string should be considered a valid value. If set to  False  then the empty string is considered invalid and will raise a validation error. Defaults to  False .  html_cutoff  - If set this will be the maximum number of choices that will be displayed by a HTML select drop down. Can be used to ensure that automatically generated ChoiceFields with very large possible selections do not prevent a template from rendering. Defaults to  None .  html_cutoff_text  - If set this will display a textual indicator if the maximum number of items have been cutoff in an HTML select drop down. Defaults to  \"More than {count} items\u2026\"   Both the  allow_blank  and  allow_null  are valid options on  ChoiceField , although it is highly recommended that you only use one and not both.  allow_blank  should be preferred for textual choices, and  allow_null  should be preferred for numeric or other non-textual choices.", 
             "title": "ChoiceField"
         }, 
         {
             "location": "/api-guide/fields/#multiplechoicefield", 
-            "text": "A field that can accept a set of zero, one or many values, chosen from a limited set of choices. Takes a single mandatory argument.  to_internal_value  returns a  set  containing the selected values.  Signature:   MultipleChoiceField(choices)   choices  - A list of valid values, or a list of  (key, display_name)  tuples.  allow_blank  - If set to  True  then the empty string should be considered a valid value. If set to  False  then the empty string is considered invalid and will raise a validation error. Defaults to  False .   As with  ChoiceField , both the  allow_blank  and  allow_null  options are valid, although it is highly recommended that you only use one and not both.  allow_blank  should be preferred for textual choices, and  allow_null  should be preferred for numeric or other non-textual choices.", 
+            "text": "A field that can accept a set of zero, one or many values, chosen from a limited set of choices. Takes a single mandatory argument.  to_internal_value  returns a  set  containing the selected values.  Signature:   MultipleChoiceField(choices)   choices  - A list of valid values, or a list of  (key, display_name)  tuples.  allow_blank  - If set to  True  then the empty string should be considered a valid value. If set to  False  then the empty string is considered invalid and will raise a validation error. Defaults to  False .  html_cutoff  - If set this will be the maximum number of choices that will be displayed by a HTML select drop down. Can be used to ensure that automatically generated ChoiceFields with very large possible selections do not prevent a template from rendering. Defaults to  None .  html_cutoff_text  - If set this will display a textual indicator if the maximum number of items have been cutoff in an HTML select drop down. Defaults to  \"More than {count} items\u2026\"   As with  ChoiceField , both the  allow_blank  and  allow_null  options are valid, although it is highly recommended that you only use one and not both.  allow_blank  should be preferred for textual choices, and  allow_null  should be preferred for numeric or other non-textual choices.", 
             "title": "MultipleChoiceField"
         }, 
         {
@@ -1477,12 +1477,12 @@
         }, 
         {
             "location": "/api-guide/relations/", 
-            "text": "Serializer relations\n\n\n\n\nBad programmers worry about the code.\nGood programmers worry about data structures and their relationships.\n\n\n \nLinus Torvalds\n\n\n\n\nRelational fields are used to represent model relationships.  They can be applied to \nForeignKey\n, \nManyToManyField\n and \nOneToOneField\n relationships, as well as to reverse relationships, and custom relationships such as \nGenericForeignKey\n.\n\n\n\n\nNote:\n The relational fields are declared in \nrelations.py\n, but by convention you should import them from the \nserializers\n module, using \nfrom rest_framework import serializers\n and refer to fields as \nserializers.\nFieldName\n.\n\n\n\n\nInspecting automatically generated relationships.\n\n\nWhen using the \nModelSerializer\n class, serializer fields and relationships will be automatically generated for you. Inspecting these automatically generated fields can be a useful tool for determining how to customize the relationship style.\n\n\nTo do so, open the Django shell, using \npython manage.py shell\n, then import the serializer class, instantiate it, and print the object representation\u2026\n\n\n from myapp.serializers import AccountSerializer\n\n serializer = AccountSerializer()\n\n print repr(serializer)  # Or `print(repr(serializer))` in Python 3.x.\nAccountSerializer():\n    id = IntegerField(label='ID', read_only=True)\n    name = CharField(allow_blank=True, max_length=100, required=False)\n    owner = PrimaryKeyRelatedField(queryset=User.objects.all())\n\n\n\nAPI Reference\n\n\nIn order to explain the various types of relational fields, we'll use a couple of simple models for our examples.  Our models will be for music albums, and the tracks listed on each album.\n\n\nclass Album(models.Model):\n    album_name = models.CharField(max_length=100)\n    artist = models.CharField(max_length=100)\n\nclass Track(models.Model):\n    album = models.ForeignKey(Album, related_name='tracks')\n    order = models.IntegerField()\n    title = models.CharField(max_length=100)\n    duration = models.IntegerField()\n\n    class Meta:\n        unique_together = ('album', 'order')\n        ordering = ['order']\n\n    def __unicode__(self):\n        return '%d: %s' % (self.order, self.title)\n\n\n\nStringRelatedField\n\n\nStringRelatedField\n may be used to represent the target of the relationship using its \n__unicode__\n method.\n\n\nFor example, the following serializer.\n\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    tracks = serializers.StringRelatedField(many=True)\n\n    class Meta:\n        model = Album\n        fields = ('album_name', 'artist', 'tracks')\n\n\n\nWould serialize to the following representation.\n\n\n{\n    'album_name': 'Things We Lost In The Fire',\n    'artist': 'Low',\n    'tracks': [\n        '1: Sunflower',\n        '2: Whitetail',\n        '3: Dinosaur Act',\n        ...\n    ]\n}\n\n\n\nThis field is read only.\n\n\nArguments\n:\n\n\n\n\nmany\n - If applied to a to-many relationship, you should set this argument to \nTrue\n.\n\n\n\n\nPrimaryKeyRelatedField\n\n\nPrimaryKeyRelatedField\n may be used to represent the target of the relationship using its primary key.\n\n\nFor example, the following serializer:\n\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    tracks = serializers.PrimaryKeyRelatedField(many=True, read_only=True)\n\n    class Meta:\n        model = Album\n        fields = ('album_name', 'artist', 'tracks')\n\n\n\nWould serialize to a representation like this:\n\n\n{\n    'album_name': 'The Roots',\n    'artist': 'Undun',\n    'tracks': [\n        89,\n        90,\n        91,\n        ...\n    ]\n}\n\n\n\nBy default this field is read-write, although you can change this behavior using the \nread_only\n flag.\n\n\nArguments\n:\n\n\n\n\nqueryset\n - The queryset used for model instance lookups when validating the field input. Relationships must either set a queryset explicitly, or set \nread_only=True\n.\n\n\nmany\n - If applied to a to-many relationship, you should set this argument to \nTrue\n.\n\n\nallow_null\n - If set to \nTrue\n, the field will accept values of \nNone\n or the empty string for nullable relationships. Defaults to \nFalse\n.\n\n\npk_field\n - Set to a field to control serialization/deserialization of the primary key's value. For example, \npk_field=UUIDField(format='hex')\n would serialize a UUID primary key into its compact hex representation.\n\n\n\n\nHyperlinkedRelatedField\n\n\nHyperlinkedRelatedField\n may be used to represent the target of the relationship using a hyperlink.\n\n\nFor example, the following serializer:\n\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    tracks = serializers.HyperlinkedRelatedField(\n        many=True,\n        read_only=True,\n        view_name='track-detail'\n    )\n\n    class Meta:\n        model = Album\n        fields = ('album_name', 'artist', 'tracks')\n\n\n\nWould serialize to a representation like this:\n\n\n{\n    'album_name': 'Graceland',\n    'artist': 'Paul Simon',\n    'tracks': [\n        'http://www.example.com/api/tracks/45/',\n        'http://www.example.com/api/tracks/46/',\n        'http://www.example.com/api/tracks/47/',\n        ...\n    ]\n}\n\n\n\nBy default this field is read-write, although you can change this behavior using the \nread_only\n flag.\n\n\n\n\nNote\n: This field is designed for objects that map to a URL that accepts a single URL keyword argument, as set using the \nlookup_field\n and \nlookup_url_kwarg\n arguments.\n\n\nThis is suitable for URLs that contain a single primary key or slug argument as part of the URL.\n\n\nIf you require more complex hyperlinked representation you'll need to customize the field, as described in the \ncustom hyperlinked fields\n section, below.\n\n\n\n\nArguments\n:\n\n\n\n\nview_name\n - The view name that should be used as the target of the relationship.  If you're using \nthe standard router classes\n this will be a string with the format \nmodelname\n-detail\n. \nrequired\n.\n\n\nqueryset\n - The queryset used for model instance lookups when validating the field input. Relationships must either set a queryset explicitly, or set \nread_only=True\n.\n\n\nmany\n - If applied to a to-many relationship, you should set this argument to \nTrue\n.\n\n\nallow_null\n - If set to \nTrue\n, the field will accept values of \nNone\n or the empty string for nullable relationships. Defaults to \nFalse\n.\n\n\nlookup_field\n - The field on the target that should be used for the lookup.  Should correspond to a URL keyword argument on the referenced view.  Default is \n'pk'\n.\n\n\nlookup_url_kwarg\n - The name of the keyword argument defined in the URL conf that corresponds to the lookup field. Defaults to using the same value as \nlookup_field\n.\n\n\nformat\n - If using format suffixes, hyperlinked fields will use the same format suffix for the target unless overridden by using the \nformat\n argument.\n\n\n\n\nSlugRelatedField\n\n\nSlugRelatedField\n may be used to represent the target of the relationship using a field on the target.\n\n\nFor example, the following serializer:\n\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    tracks = serializers.SlugRelatedField(\n        many=True,\n        read_only=True,\n        slug_field='title'\n     )\n\n    class Meta:\n        model = Album\n        fields = ('album_name', 'artist', 'tracks')\n\n\n\nWould serialize to a representation like this:\n\n\n{\n    'album_name': 'Dear John',\n    'artist': 'Loney Dear',\n    'tracks': [\n        'Airport Surroundings',\n        'Everything Turns to You',\n        'I Was Only Going Out',\n        ...\n    ]\n}\n\n\n\nBy default this field is read-write, although you can change this behavior using the \nread_only\n flag.\n\n\nWhen using \nSlugRelatedField\n as a read-write field, you will normally want to ensure that the slug field corresponds to a model field with \nunique=True\n.\n\n\nArguments\n:\n\n\n\n\nslug_field\n - The field on the target that should be used to represent it.  This should be a field that uniquely identifies any given instance.  For example, \nusername\n.  \nrequired\n\n\nqueryset\n - The queryset used for model instance lookups when validating the field input. Relationships must either set a queryset explicitly, or set \nread_only=True\n.\n\n\nmany\n - If applied to a to-many relationship, you should set this argument to \nTrue\n.\n\n\nallow_null\n - If set to \nTrue\n, the field will accept values of \nNone\n or the empty string for nullable relationships. Defaults to \nFalse\n.\n\n\n\n\nHyperlinkedIdentityField\n\n\nThis field can be applied as an identity relationship, such as the \n'url'\n field on  a HyperlinkedModelSerializer.  It can also be used for an attribute on the object.  For example, the following serializer:\n\n\nclass AlbumSerializer(serializers.HyperlinkedModelSerializer):\n    track_listing = serializers.HyperlinkedIdentityField(view_name='track-list')\n\n    class Meta:\n        model = Album\n        fields = ('album_name', 'artist', 'track_listing')\n\n\n\nWould serialize to a representation like this:\n\n\n{\n    'album_name': 'The Eraser',\n    'artist': 'Thom Yorke',\n    'track_listing': 'http://www.example.com/api/track_list/12/',\n}\n\n\n\nThis field is always read-only.\n\n\nArguments\n:\n\n\n\n\nview_name\n - The view name that should be used as the target of the relationship.  If you're using \nthe standard router classes\n this will be a string with the format \nmodel_name\n-detail\n.  \nrequired\n.\n\n\nlookup_field\n - The field on the target that should be used for the lookup.  Should correspond to a URL keyword argument on the referenced view.  Default is \n'pk'\n.\n\n\nlookup_url_kwarg\n - The name of the keyword argument defined in the URL conf that corresponds to the lookup field. Defaults to using the same value as \nlookup_field\n.\n\n\nformat\n - If using format suffixes, hyperlinked fields will use the same format suffix for the target unless overridden by using the \nformat\n argument.\n\n\n\n\n\n\nNested relationships\n\n\nNested relationships can be expressed by using serializers as fields.\n\n\nIf the field is used to represent a to-many relationship, you should add the \nmany=True\n flag to the serializer field.\n\n\nExample\n\n\nFor example, the following serializer:\n\n\nclass TrackSerializer(serializers.ModelSerializer):\n    class Meta:\n        model = Track\n        fields = ('order', 'title')\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    tracks = TrackSerializer(many=True, read_only=True)\n\n    class Meta:\n        model = Album\n        fields = ('album_name', 'artist', 'tracks')\n\n\n\nWould serialize to a nested representation like this:\n\n\n album = Album.objects.create(album_name=\"The Grey Album\", artist='Danger Mouse')\n\n Track.objects.create(album=album, order=1, title='Public Service Announcement', duration=245)\n\nTrack: Track object\n\n\n Track.objects.create(album=album, order=2, title='What More Can I Say', duration=264)\n\nTrack: Track object\n\n\n Track.objects.create(album=album, order=3, title='Encore', duration=159)\n\nTrack: Track object\n\n\n serializer = AlbumSerializer(instance=album)\n\n serializer.data\n{\n    'album_name': 'The Grey Album',\n    'artist': 'Danger Mouse',\n    'tracks': [\n        {'order': 1, 'title': 'Public Service Announcement', 'duration': 245},\n        {'order': 2, 'title': 'What More Can I Say', 'duration': 264},\n        {'order': 3, 'title': 'Encore', 'duration': 159},\n        ...\n    ],\n}\n\n\n\nWritable nested serializers\n\n\nBe default nested serializers are read-only. If you want to to support write-operations to a nested serializer field you'll need to create either or both of the \ncreate()\n and/or \nupdate()\n methods, in order to explicitly specify how the child relationships should be saved.\n\n\nclass TrackSerializer(serializers.ModelSerializer):\n    class Meta:\n        model = Track\n        fields = ('order', 'title')\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    tracks = TrackSerializer(many=True)\n\n    class Meta:\n        model = Album\n        fields = ('album_name', 'artist', 'tracks')\n\n    def create(self, validated_data):\n        tracks_data = validated_data.pop('tracks')\n        album = Album.objects.create(**validated_data)\n        for track_data in tracks_data:\n            Track.objects.create(album=album, **track_data)\n        return album\n\n\n data = {\n    'album_name': 'The Grey Album',\n    'artist': 'Danger Mouse',\n    'tracks': [\n        {'order': 1, 'title': 'Public Service Announcement', 'duration': 245},\n        {'order': 2, 'title': 'What More Can I Say', 'duration': 264},\n        {'order': 3, 'title': 'Encore', 'duration': 159},\n    ],\n}\n\n serializer = AlbumSerializer(data=data)\n\n serializer.is_valid()\nTrue\n\n serializer.save()\n\nAlbum: Album object\n\n\n\n\nCustom relational fields\n\n\nTo implement a custom relational field, you should override \nRelatedField\n, and implement the \n.to_representation(self, value)\n method. This method takes the target of the field as the \nvalue\n argument, and should return the representation that should be used to serialize the target. The \nvalue\n argument will typically be a model instance.\n\n\nIf you want to implement a read-write relational field, you must also implement the \n.to_internal_value(self, data)\n method.\n\n\nExample\n\n\nFor example, we could define a relational field to serialize a track to a custom string representation, using its ordering, title, and duration.\n\n\nimport time\n\nclass TrackListingField(serializers.RelatedField):\n    def to_representation(self, value):\n        duration = time.strftime('%M:%S', time.gmtime(value.duration))\n        return 'Track %d: %s (%s)' % (value.order, value.name, duration)\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    tracks = TrackListingField(many=True)\n\n    class Meta:\n        model = Album\n        fields = ('album_name', 'artist', 'tracks')\n\n\n\nThis custom field would then serialize to the following representation.\n\n\n{\n    'album_name': 'Sometimes I Wish We Were an Eagle',\n    'artist': 'Bill Callahan',\n    'tracks': [\n        'Track 1: Jim Cain (04:39)',\n        'Track 2: Eid Ma Clack Shaw (04:19)',\n        'Track 3: The Wind and the Dove (04:34)',\n        ...\n    ]\n}\n\n\n\n\n\nCustom hyperlinked fields\n\n\nIn some cases you may need to customize the behavior of a hyperlinked field, in order to represent URLs that require more than a single lookup field.\n\n\nYou can achieve this by overriding \nHyperlinkedRelatedField\n. There are two methods that may be overridden:\n\n\nget_url(self, obj, view_name, request, format)\n\n\nThe \nget_url\n method is used to map the object instance to its URL representation.\n\n\nMay raise a \nNoReverseMatch\n if the \nview_name\n and \nlookup_field\n\nattributes are not configured to correctly match the URL conf.\n\n\nget_object(self, queryset, view_name, view_args, view_kwargs)\n\n\nIf you want to support a writable hyperlinked field then you'll also want to override \nget_object\n, in order to map incoming URLs back to the object they represent. For read-only hyperlinked fields there is no need to override this method.\n\n\nThe return value of this method should the object that corresponds to the matched URL conf arguments.\n\n\nMay raise an \nObjectDoesNotExist\n exception.\n\n\nExample\n\n\nSay we have a URL for a customer object that takes two keyword arguments, like so:\n\n\n/api/\norganization_slug\n/customers/\ncustomer_pk\n/\n\n\n\nThis cannot be represented with the default implementation, which accepts only a single lookup field.\n\n\nIn this case we'd need to override \nHyperlinkedRelatedField\n to get the behavior we want:\n\n\nfrom rest_framework import serializers\nfrom rest_framework.reverse import reverse\n\nclass CustomerHyperlink(serializers.HyperlinkedRelatedField):\n    # We define these as class attributes, so we don't need to pass them as arguments.\n    view_name = 'customer-detail'\n    queryset = Customer.objects.all()\n\n    def get_url(self, obj, view_name, request, format):\n        url_kwargs = {\n            'organization_slug': obj.organization.slug,\n            'customer_pk': obj.pk\n        }\n        return reverse(view_name, url_kwargs, request=request, format=format)\n\n    def get_object(self, view_name, view_args, view_kwargs):\n        lookup_kwargs = {\n           'organization__slug': view_kwargs['organization_slug'],\n           'pk': view_kwargs['customer_pk']\n        }\n        return self.get_queryset().get(**lookup_kwargs)\n\n\n\nNote that if you wanted to use this style together with the generic views then you'd also need to override \n.get_object\n on the view in order to get the correct lookup behavior.\n\n\nGenerally we recommend a flat style for API representations where possible, but the nested URL style can also be reasonable when used in moderation.\n\n\n\n\nFurther notes\n\n\nThe \nqueryset\n argument\n\n\nThe \nqueryset\n argument is only ever required for \nwritable\n relationship field, in which case it is used for performing the model instance lookup, that maps from the primitive user input, into a model instance.\n\n\nIn version 2.x a serializer class could \nsometimes\n automatically determine the \nqueryset\n argument \nif\n a \nModelSerializer\n class was being used.\n\n\nThis behavior is now replaced with \nalways\n using an explicit \nqueryset\n argument for writable relational fields.\n\n\nDoing so reduces the amount of hidden 'magic' that \nModelSerializer\n provides, makes the behavior of the field more clear, and ensures that it is trivial to move between using the \nModelSerializer\n shortcut, or using fully explicit \nSerializer\n classes.\n\n\nCustomizing the HTML display\n\n\nThe built-in \n__str__\n method of the model will be used to generate string representations of the objects used to populate the \nchoices\n property. These choices are used to populate select HTML inputs in the browsable API.\n\n\nTo provide customized representations for such inputs, override \ndisplay_value()\n of a \nRelatedField\n subclass. This method will receive a model object, and should return a string suitable for representing it. For example:\n\n\nclass TrackPrimaryKeyRelatedField(serializers.PrimaryKeyRelatedField):\n    def display_value(self, instance):\n        return 'Track: %s' % (instance.title)\n\n\n\nReverse relations\n\n\nNote that reverse relationships are not automatically included by the \nModelSerializer\n and \nHyperlinkedModelSerializer\n classes.  To include a reverse relationship, you must explicitly add it to the fields list.  For example:\n\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    class Meta:\n        fields = ('tracks', ...)\n\n\n\nYou'll normally want to ensure that you've set an appropriate \nrelated_name\n argument on the relationship, that you can use as the field name.  For example:\n\n\nclass Track(models.Model):\n    album = models.ForeignKey(Album, related_name='tracks')\n    ...\n\n\n\nIf you have not set a related name for the reverse relationship, you'll need to use the automatically generated related name in the \nfields\n argument.  For example:\n\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    class Meta:\n        fields = ('track_set', ...)\n\n\n\nSee the Django documentation on \nreverse relationships\n for more details.\n\n\nGeneric relationships\n\n\nIf you want to serialize a generic foreign key, you need to define a custom field, to determine explicitly how you want serialize the targets of the relationship.\n\n\nFor example, given the following model for a tag, which has a generic relationship with other arbitrary models:\n\n\nclass TaggedItem(models.Model):\n    \"\"\"\n    Tags arbitrary model instances using a generic relation.\n\n    See: https://docs.djangoproject.com/en/dev/ref/contrib/contenttypes/\n    \"\"\"\n    tag_name = models.SlugField()\n    content_type = models.ForeignKey(ContentType)\n    object_id = models.PositiveIntegerField()\n    tagged_object = GenericForeignKey('content_type', 'object_id')\n\n    def __unicode__(self):\n        return self.tag\n\n\n\nAnd the following two models, which may be have associated tags:\n\n\nclass Bookmark(models.Model):\n    \"\"\"\n    A bookmark consists of a URL, and 0 or more descriptive tags.\n    \"\"\"\n    url = models.URLField()\n    tags = GenericRelation(TaggedItem)\n\n\nclass Note(models.Model):\n    \"\"\"\n    A note consists of some text, and 0 or more descriptive tags.\n    \"\"\"\n    text = models.CharField(max_length=1000)\n    tags = GenericRelation(TaggedItem)\n\n\n\nWe could define a custom field that could be used to serialize tagged instances, using the type of each instance to determine how it should be serialized.\n\n\nclass TaggedObjectRelatedField(serializers.RelatedField):\n    \"\"\"\n    A custom field to use for the `tagged_object` generic relationship.\n    \"\"\"\n\n    def to_representation(self, value):\n        \"\"\"\n        Serialize tagged objects to a simple textual representation.\n        \"\"\"\n        if isinstance(value, Bookmark):\n            return 'Bookmark: ' + value.url\n        elif isinstance(value, Note):\n            return 'Note: ' + value.text\n        raise Exception('Unexpected type of tagged object')\n\n\n\nIf you need the target of the relationship to have a nested representation, you can use the required serializers inside the \n.to_representation()\n method:\n\n\n    def to_representation(self, value):\n        \"\"\"\n        Serialize bookmark instances using a bookmark serializer,\n        and note instances using a note serializer.\n        \"\"\"\n        if isinstance(value, Bookmark):\n            serializer = BookmarkSerializer(value)\n        elif isinstance(value, Note):\n            serializer = NoteSerializer(value)\n        else:\n            raise Exception('Unexpected type of tagged object')\n\n        return serializer.data\n\n\n\nNote that reverse generic keys, expressed using the \nGenericRelation\n field, can be serialized using the regular relational field types, since the type of the target in the relationship is always known.\n\n\nFor more information see \nthe Django documentation on generic relations\n.\n\n\nManyToManyFields with a Through Model\n\n\nBy default, relational fields that target a \nManyToManyField\n with a\n\nthrough\n model specified are set to read-only.\n\n\nIf you explicitly specify a relational field pointing to a\n\nManyToManyField\n with a through model, be sure to set \nread_only\n\nto \nTrue\n.\n\n\n\n\nThird Party Packages\n\n\nThe following third party packages are also available.\n\n\nDRF Nested Routers\n\n\nThe \ndrf-nested-routers package\n provides routers and relationship fields for working with nested resources.", 
+            "text": "Serializer relations\n\n\n\n\nBad programmers worry about the code.\nGood programmers worry about data structures and their relationships.\n\n\n \nLinus Torvalds\n\n\n\n\nRelational fields are used to represent model relationships.  They can be applied to \nForeignKey\n, \nManyToManyField\n and \nOneToOneField\n relationships, as well as to reverse relationships, and custom relationships such as \nGenericForeignKey\n.\n\n\n\n\nNote:\n The relational fields are declared in \nrelations.py\n, but by convention you should import them from the \nserializers\n module, using \nfrom rest_framework import serializers\n and refer to fields as \nserializers.\nFieldName\n.\n\n\n\n\nInspecting relationships.\n\n\nWhen using the \nModelSerializer\n class, serializer fields and relationships will be automatically generated for you. Inspecting these automatically generated fields can be a useful tool for determining how to customize the relationship style.\n\n\nTo do so, open the Django shell, using \npython manage.py shell\n, then import the serializer class, instantiate it, and print the object representation\u2026\n\n\n from myapp.serializers import AccountSerializer\n\n serializer = AccountSerializer()\n\n print repr(serializer)  # Or `print(repr(serializer))` in Python 3.x.\nAccountSerializer():\n    id = IntegerField(label='ID', read_only=True)\n    name = CharField(allow_blank=True, max_length=100, required=False)\n    owner = PrimaryKeyRelatedField(queryset=User.objects.all())\n\n\n\nAPI Reference\n\n\nIn order to explain the various types of relational fields, we'll use a couple of simple models for our examples.  Our models will be for music albums, and the tracks listed on each album.\n\n\nclass Album(models.Model):\n    album_name = models.CharField(max_length=100)\n    artist = models.CharField(max_length=100)\n\nclass Track(models.Model):\n    album = models.ForeignKey(Album, related_name='tracks')\n    order = models.IntegerField()\n    title = models.CharField(max_length=100)\n    duration = models.IntegerField()\n\n    class Meta:\n        unique_together = ('album', 'order')\n        ordering = ['order']\n\n    def __unicode__(self):\n        return '%d: %s' % (self.order, self.title)\n\n\n\nStringRelatedField\n\n\nStringRelatedField\n may be used to represent the target of the relationship using its \n__unicode__\n method.\n\n\nFor example, the following serializer.\n\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    tracks = serializers.StringRelatedField(many=True)\n\n    class Meta:\n        model = Album\n        fields = ('album_name', 'artist', 'tracks')\n\n\n\nWould serialize to the following representation.\n\n\n{\n    'album_name': 'Things We Lost In The Fire',\n    'artist': 'Low',\n    'tracks': [\n        '1: Sunflower',\n        '2: Whitetail',\n        '3: Dinosaur Act',\n        ...\n    ]\n}\n\n\n\nThis field is read only.\n\n\nArguments\n:\n\n\n\n\nmany\n - If applied to a to-many relationship, you should set this argument to \nTrue\n.\n\n\n\n\nPrimaryKeyRelatedField\n\n\nPrimaryKeyRelatedField\n may be used to represent the target of the relationship using its primary key.\n\n\nFor example, the following serializer:\n\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    tracks = serializers.PrimaryKeyRelatedField(many=True, read_only=True)\n\n    class Meta:\n        model = Album\n        fields = ('album_name', 'artist', 'tracks')\n\n\n\nWould serialize to a representation like this:\n\n\n{\n    'album_name': 'The Roots',\n    'artist': 'Undun',\n    'tracks': [\n        89,\n        90,\n        91,\n        ...\n    ]\n}\n\n\n\nBy default this field is read-write, although you can change this behavior using the \nread_only\n flag.\n\n\nArguments\n:\n\n\n\n\nqueryset\n - The queryset used for model instance lookups when validating the field input. Relationships must either set a queryset explicitly, or set \nread_only=True\n.\n\n\nmany\n - If applied to a to-many relationship, you should set this argument to \nTrue\n.\n\n\nallow_null\n - If set to \nTrue\n, the field will accept values of \nNone\n or the empty string for nullable relationships. Defaults to \nFalse\n.\n\n\npk_field\n - Set to a field to control serialization/deserialization of the primary key's value. For example, \npk_field=UUIDField(format='hex')\n would serialize a UUID primary key into its compact hex representation.\n\n\n\n\nHyperlinkedRelatedField\n\n\nHyperlinkedRelatedField\n may be used to represent the target of the relationship using a hyperlink.\n\n\nFor example, the following serializer:\n\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    tracks = serializers.HyperlinkedRelatedField(\n        many=True,\n        read_only=True,\n        view_name='track-detail'\n    )\n\n    class Meta:\n        model = Album\n        fields = ('album_name', 'artist', 'tracks')\n\n\n\nWould serialize to a representation like this:\n\n\n{\n    'album_name': 'Graceland',\n    'artist': 'Paul Simon',\n    'tracks': [\n        'http://www.example.com/api/tracks/45/',\n        'http://www.example.com/api/tracks/46/',\n        'http://www.example.com/api/tracks/47/',\n        ...\n    ]\n}\n\n\n\nBy default this field is read-write, although you can change this behavior using the \nread_only\n flag.\n\n\n\n\nNote\n: This field is designed for objects that map to a URL that accepts a single URL keyword argument, as set using the \nlookup_field\n and \nlookup_url_kwarg\n arguments.\n\n\nThis is suitable for URLs that contain a single primary key or slug argument as part of the URL.\n\n\nIf you require more complex hyperlinked representation you'll need to customize the field, as described in the \ncustom hyperlinked fields\n section, below.\n\n\n\n\nArguments\n:\n\n\n\n\nview_name\n - The view name that should be used as the target of the relationship.  If you're using \nthe standard router classes\n this will be a string with the format \nmodelname\n-detail\n. \nrequired\n.\n\n\nqueryset\n - The queryset used for model instance lookups when validating the field input. Relationships must either set a queryset explicitly, or set \nread_only=True\n.\n\n\nmany\n - If applied to a to-many relationship, you should set this argument to \nTrue\n.\n\n\nallow_null\n - If set to \nTrue\n, the field will accept values of \nNone\n or the empty string for nullable relationships. Defaults to \nFalse\n.\n\n\nlookup_field\n - The field on the target that should be used for the lookup.  Should correspond to a URL keyword argument on the referenced view.  Default is \n'pk'\n.\n\n\nlookup_url_kwarg\n - The name of the keyword argument defined in the URL conf that corresponds to the lookup field. Defaults to using the same value as \nlookup_field\n.\n\n\nformat\n - If using format suffixes, hyperlinked fields will use the same format suffix for the target unless overridden by using the \nformat\n argument.\n\n\n\n\nSlugRelatedField\n\n\nSlugRelatedField\n may be used to represent the target of the relationship using a field on the target.\n\n\nFor example, the following serializer:\n\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    tracks = serializers.SlugRelatedField(\n        many=True,\n        read_only=True,\n        slug_field='title'\n     )\n\n    class Meta:\n        model = Album\n        fields = ('album_name', 'artist', 'tracks')\n\n\n\nWould serialize to a representation like this:\n\n\n{\n    'album_name': 'Dear John',\n    'artist': 'Loney Dear',\n    'tracks': [\n        'Airport Surroundings',\n        'Everything Turns to You',\n        'I Was Only Going Out',\n        ...\n    ]\n}\n\n\n\nBy default this field is read-write, although you can change this behavior using the \nread_only\n flag.\n\n\nWhen using \nSlugRelatedField\n as a read-write field, you will normally want to ensure that the slug field corresponds to a model field with \nunique=True\n.\n\n\nArguments\n:\n\n\n\n\nslug_field\n - The field on the target that should be used to represent it.  This should be a field that uniquely identifies any given instance.  For example, \nusername\n.  \nrequired\n\n\nqueryset\n - The queryset used for model instance lookups when validating the field input. Relationships must either set a queryset explicitly, or set \nread_only=True\n.\n\n\nmany\n - If applied to a to-many relationship, you should set this argument to \nTrue\n.\n\n\nallow_null\n - If set to \nTrue\n, the field will accept values of \nNone\n or the empty string for nullable relationships. Defaults to \nFalse\n.\n\n\n\n\nHyperlinkedIdentityField\n\n\nThis field can be applied as an identity relationship, such as the \n'url'\n field on  a HyperlinkedModelSerializer.  It can also be used for an attribute on the object.  For example, the following serializer:\n\n\nclass AlbumSerializer(serializers.HyperlinkedModelSerializer):\n    track_listing = serializers.HyperlinkedIdentityField(view_name='track-list')\n\n    class Meta:\n        model = Album\n        fields = ('album_name', 'artist', 'track_listing')\n\n\n\nWould serialize to a representation like this:\n\n\n{\n    'album_name': 'The Eraser',\n    'artist': 'Thom Yorke',\n    'track_listing': 'http://www.example.com/api/track_list/12/',\n}\n\n\n\nThis field is always read-only.\n\n\nArguments\n:\n\n\n\n\nview_name\n - The view name that should be used as the target of the relationship.  If you're using \nthe standard router classes\n this will be a string with the format \nmodel_name\n-detail\n.  \nrequired\n.\n\n\nlookup_field\n - The field on the target that should be used for the lookup.  Should correspond to a URL keyword argument on the referenced view.  Default is \n'pk'\n.\n\n\nlookup_url_kwarg\n - The name of the keyword argument defined in the URL conf that corresponds to the lookup field. Defaults to using the same value as \nlookup_field\n.\n\n\nformat\n - If using format suffixes, hyperlinked fields will use the same format suffix for the target unless overridden by using the \nformat\n argument.\n\n\n\n\n\n\nNested relationships\n\n\nNested relationships can be expressed by using serializers as fields.\n\n\nIf the field is used to represent a to-many relationship, you should add the \nmany=True\n flag to the serializer field.\n\n\nExample\n\n\nFor example, the following serializer:\n\n\nclass TrackSerializer(serializers.ModelSerializer):\n    class Meta:\n        model = Track\n        fields = ('order', 'title')\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    tracks = TrackSerializer(many=True, read_only=True)\n\n    class Meta:\n        model = Album\n        fields = ('album_name', 'artist', 'tracks')\n\n\n\nWould serialize to a nested representation like this:\n\n\n album = Album.objects.create(album_name=\"The Grey Album\", artist='Danger Mouse')\n\n Track.objects.create(album=album, order=1, title='Public Service Announcement', duration=245)\n\nTrack: Track object\n\n\n Track.objects.create(album=album, order=2, title='What More Can I Say', duration=264)\n\nTrack: Track object\n\n\n Track.objects.create(album=album, order=3, title='Encore', duration=159)\n\nTrack: Track object\n\n\n serializer = AlbumSerializer(instance=album)\n\n serializer.data\n{\n    'album_name': 'The Grey Album',\n    'artist': 'Danger Mouse',\n    'tracks': [\n        {'order': 1, 'title': 'Public Service Announcement', 'duration': 245},\n        {'order': 2, 'title': 'What More Can I Say', 'duration': 264},\n        {'order': 3, 'title': 'Encore', 'duration': 159},\n        ...\n    ],\n}\n\n\n\nWritable nested serializers\n\n\nBe default nested serializers are read-only. If you want to to support write-operations to a nested serializer field you'll need to create either or both of the \ncreate()\n and/or \nupdate()\n methods, in order to explicitly specify how the child relationships should be saved.\n\n\nclass TrackSerializer(serializers.ModelSerializer):\n    class Meta:\n        model = Track\n        fields = ('order', 'title')\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    tracks = TrackSerializer(many=True)\n\n    class Meta:\n        model = Album\n        fields = ('album_name', 'artist', 'tracks')\n\n    def create(self, validated_data):\n        tracks_data = validated_data.pop('tracks')\n        album = Album.objects.create(**validated_data)\n        for track_data in tracks_data:\n            Track.objects.create(album=album, **track_data)\n        return album\n\n\n data = {\n    'album_name': 'The Grey Album',\n    'artist': 'Danger Mouse',\n    'tracks': [\n        {'order': 1, 'title': 'Public Service Announcement', 'duration': 245},\n        {'order': 2, 'title': 'What More Can I Say', 'duration': 264},\n        {'order': 3, 'title': 'Encore', 'duration': 159},\n    ],\n}\n\n serializer = AlbumSerializer(data=data)\n\n serializer.is_valid()\nTrue\n\n serializer.save()\n\nAlbum: Album object\n\n\n\n\nCustom relational fields\n\n\nTo implement a custom relational field, you should override \nRelatedField\n, and implement the \n.to_representation(self, value)\n method. This method takes the target of the field as the \nvalue\n argument, and should return the representation that should be used to serialize the target. The \nvalue\n argument will typically be a model instance.\n\n\nIf you want to implement a read-write relational field, you must also implement the \n.to_internal_value(self, data)\n method.\n\n\nExample\n\n\nFor example, we could define a relational field to serialize a track to a custom string representation, using its ordering, title, and duration.\n\n\nimport time\n\nclass TrackListingField(serializers.RelatedField):\n    def to_representation(self, value):\n        duration = time.strftime('%M:%S', time.gmtime(value.duration))\n        return 'Track %d: %s (%s)' % (value.order, value.name, duration)\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    tracks = TrackListingField(many=True)\n\n    class Meta:\n        model = Album\n        fields = ('album_name', 'artist', 'tracks')\n\n\n\nThis custom field would then serialize to the following representation.\n\n\n{\n    'album_name': 'Sometimes I Wish We Were an Eagle',\n    'artist': 'Bill Callahan',\n    'tracks': [\n        'Track 1: Jim Cain (04:39)',\n        'Track 2: Eid Ma Clack Shaw (04:19)',\n        'Track 3: The Wind and the Dove (04:34)',\n        ...\n    ]\n}\n\n\n\n\n\nCustom hyperlinked fields\n\n\nIn some cases you may need to customize the behavior of a hyperlinked field, in order to represent URLs that require more than a single lookup field.\n\n\nYou can achieve this by overriding \nHyperlinkedRelatedField\n. There are two methods that may be overridden:\n\n\nget_url(self, obj, view_name, request, format)\n\n\nThe \nget_url\n method is used to map the object instance to its URL representation.\n\n\nMay raise a \nNoReverseMatch\n if the \nview_name\n and \nlookup_field\n\nattributes are not configured to correctly match the URL conf.\n\n\nget_object(self, queryset, view_name, view_args, view_kwargs)\n\n\nIf you want to support a writable hyperlinked field then you'll also want to override \nget_object\n, in order to map incoming URLs back to the object they represent. For read-only hyperlinked fields there is no need to override this method.\n\n\nThe return value of this method should the object that corresponds to the matched URL conf arguments.\n\n\nMay raise an \nObjectDoesNotExist\n exception.\n\n\nExample\n\n\nSay we have a URL for a customer object that takes two keyword arguments, like so:\n\n\n/api/\norganization_slug\n/customers/\ncustomer_pk\n/\n\n\n\nThis cannot be represented with the default implementation, which accepts only a single lookup field.\n\n\nIn this case we'd need to override \nHyperlinkedRelatedField\n to get the behavior we want:\n\n\nfrom rest_framework import serializers\nfrom rest_framework.reverse import reverse\n\nclass CustomerHyperlink(serializers.HyperlinkedRelatedField):\n    # We define these as class attributes, so we don't need to pass them as arguments.\n    view_name = 'customer-detail'\n    queryset = Customer.objects.all()\n\n    def get_url(self, obj, view_name, request, format):\n        url_kwargs = {\n            'organization_slug': obj.organization.slug,\n            'customer_pk': obj.pk\n        }\n        return reverse(view_name, url_kwargs, request=request, format=format)\n\n    def get_object(self, view_name, view_args, view_kwargs):\n        lookup_kwargs = {\n           'organization__slug': view_kwargs['organization_slug'],\n           'pk': view_kwargs['customer_pk']\n        }\n        return self.get_queryset().get(**lookup_kwargs)\n\n\n\nNote that if you wanted to use this style together with the generic views then you'd also need to override \n.get_object\n on the view in order to get the correct lookup behavior.\n\n\nGenerally we recommend a flat style for API representations where possible, but the nested URL style can also be reasonable when used in moderation.\n\n\n\n\nFurther notes\n\n\nThe \nqueryset\n argument\n\n\nThe \nqueryset\n argument is only ever required for \nwritable\n relationship field, in which case it is used for performing the model instance lookup, that maps from the primitive user input, into a model instance.\n\n\nIn version 2.x a serializer class could \nsometimes\n automatically determine the \nqueryset\n argument \nif\n a \nModelSerializer\n class was being used.\n\n\nThis behavior is now replaced with \nalways\n using an explicit \nqueryset\n argument for writable relational fields.\n\n\nDoing so reduces the amount of hidden 'magic' that \nModelSerializer\n provides, makes the behavior of the field more clear, and ensures that it is trivial to move between using the \nModelSerializer\n shortcut, or using fully explicit \nSerializer\n classes.\n\n\nCustomizing the HTML display\n\n\nThe built-in \n__str__\n method of the model will be used to generate string representations of the objects used to populate the \nchoices\n property. These choices are used to populate select HTML inputs in the browsable API.\n\n\nTo provide customized representations for such inputs, override \ndisplay_value()\n of a \nRelatedField\n subclass. This method will receive a model object, and should return a string suitable for representing it. For example:\n\n\nclass TrackPrimaryKeyRelatedField(serializers.PrimaryKeyRelatedField):\n    def display_value(self, instance):\n        return 'Track: %s' % (instance.title)\n\n\n\nSelect field cutoffs\n\n\nWhen rendered in the browsable API relational fields will default to only displaying a maximum of 1000 selectable items. If more items are present then a disabled option with \"More than 1000 items\u2026\" will be displayed.\n\n\nThis behavior is intended to prevent a template from being unable to render in an acceptable timespan due to a very large number of relationships being displayed.\n\n\nThere are two keyword arguments you can use to control this behavior:\n\n\n\n\nhtml_cutoff\n - If set this will be the maximum number of choices that will be displayed by a HTML select drop down. Set to \nNone\n to disable any limiting. Defaults to \n1000\n.\n\n\nhtml_cutoff_text\n - If set this will display a textual indicator if the maximum number of items have been cutoff in an HTML select drop down. Defaults to \n\"More than {count} items\u2026\"\n\n\n\n\nIn cases where the cutoff is being enforced you may want to instead use a plain input field in the HTML form. You can do so using the \nstyle\n keyword argument. For example:\n\n\nassigned_to = serializers.SlugRelatedField(\n   queryset=User.objects.all(),\n   slug field='username',\n   style={'base_template': 'input.html'}\n)\n\n\n\nReverse relations\n\n\nNote that reverse relationships are not automatically included by the \nModelSerializer\n and \nHyperlinkedModelSerializer\n classes.  To include a reverse relationship, you must explicitly add it to the fields list.  For example:\n\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    class Meta:\n        fields = ('tracks', ...)\n\n\n\nYou'll normally want to ensure that you've set an appropriate \nrelated_name\n argument on the relationship, that you can use as the field name.  For example:\n\n\nclass Track(models.Model):\n    album = models.ForeignKey(Album, related_name='tracks')\n    ...\n\n\n\nIf you have not set a related name for the reverse relationship, you'll need to use the automatically generated related name in the \nfields\n argument.  For example:\n\n\nclass AlbumSerializer(serializers.ModelSerializer):\n    class Meta:\n        fields = ('track_set', ...)\n\n\n\nSee the Django documentation on \nreverse relationships\n for more details.\n\n\nGeneric relationships\n\n\nIf you want to serialize a generic foreign key, you need to define a custom field, to determine explicitly how you want serialize the targets of the relationship.\n\n\nFor example, given the following model for a tag, which has a generic relationship with other arbitrary models:\n\n\nclass TaggedItem(models.Model):\n    \"\"\"\n    Tags arbitrary model instances using a generic relation.\n\n    See: https://docs.djangoproject.com/en/dev/ref/contrib/contenttypes/\n    \"\"\"\n    tag_name = models.SlugField()\n    content_type = models.ForeignKey(ContentType)\n    object_id = models.PositiveIntegerField()\n    tagged_object = GenericForeignKey('content_type', 'object_id')\n\n    def __unicode__(self):\n        return self.tag\n\n\n\nAnd the following two models, which may be have associated tags:\n\n\nclass Bookmark(models.Model):\n    \"\"\"\n    A bookmark consists of a URL, and 0 or more descriptive tags.\n    \"\"\"\n    url = models.URLField()\n    tags = GenericRelation(TaggedItem)\n\n\nclass Note(models.Model):\n    \"\"\"\n    A note consists of some text, and 0 or more descriptive tags.\n    \"\"\"\n    text = models.CharField(max_length=1000)\n    tags = GenericRelation(TaggedItem)\n\n\n\nWe could define a custom field that could be used to serialize tagged instances, using the type of each instance to determine how it should be serialized.\n\n\nclass TaggedObjectRelatedField(serializers.RelatedField):\n    \"\"\"\n    A custom field to use for the `tagged_object` generic relationship.\n    \"\"\"\n\n    def to_representation(self, value):\n        \"\"\"\n        Serialize tagged objects to a simple textual representation.\n        \"\"\"\n        if isinstance(value, Bookmark):\n            return 'Bookmark: ' + value.url\n        elif isinstance(value, Note):\n            return 'Note: ' + value.text\n        raise Exception('Unexpected type of tagged object')\n\n\n\nIf you need the target of the relationship to have a nested representation, you can use the required serializers inside the \n.to_representation()\n method:\n\n\n    def to_representation(self, value):\n        \"\"\"\n        Serialize bookmark instances using a bookmark serializer,\n        and note instances using a note serializer.\n        \"\"\"\n        if isinstance(value, Bookmark):\n            serializer = BookmarkSerializer(value)\n        elif isinstance(value, Note):\n            serializer = NoteSerializer(value)\n        else:\n            raise Exception('Unexpected type of tagged object')\n\n        return serializer.data\n\n\n\nNote that reverse generic keys, expressed using the \nGenericRelation\n field, can be serialized using the regular relational field types, since the type of the target in the relationship is always known.\n\n\nFor more information see \nthe Django documentation on generic relations\n.\n\n\nManyToManyFields with a Through Model\n\n\nBy default, relational fields that target a \nManyToManyField\n with a\n\nthrough\n model specified are set to read-only.\n\n\nIf you explicitly specify a relational field pointing to a\n\nManyToManyField\n with a through model, be sure to set \nread_only\n\nto \nTrue\n.\n\n\n\n\nThird Party Packages\n\n\nThe following third party packages are also available.\n\n\nDRF Nested Routers\n\n\nThe \ndrf-nested-routers package\n provides routers and relationship fields for working with nested resources.", 
             "title": "Serializer relations"
         }, 
         {
             "location": "/api-guide/relations/#serializer-relations", 
-            "text": "Bad programmers worry about the code.\nGood programmers worry about data structures and their relationships.    Linus Torvalds   Relational fields are used to represent model relationships.  They can be applied to  ForeignKey ,  ManyToManyField  and  OneToOneField  relationships, as well as to reverse relationships, and custom relationships such as  GenericForeignKey .   Note:  The relational fields are declared in  relations.py , but by convention you should import them from the  serializers  module, using  from rest_framework import serializers  and refer to fields as  serializers. FieldName .   Inspecting automatically generated relationships.  When using the  ModelSerializer  class, serializer fields and relationships will be automatically generated for you. Inspecting these automatically generated fields can be a useful tool for determining how to customize the relationship style.  To do so, open the Django shell, using  python manage.py shell , then import the serializer class, instantiate it, and print the object representation\u2026   from myapp.serializers import AccountSerializer  serializer = AccountSerializer()  print repr(serializer)  # Or `print(repr(serializer))` in Python 3.x.\nAccountSerializer():\n    id = IntegerField(label='ID', read_only=True)\n    name = CharField(allow_blank=True, max_length=100, required=False)\n    owner = PrimaryKeyRelatedField(queryset=User.objects.all())", 
+            "text": "Bad programmers worry about the code.\nGood programmers worry about data structures and their relationships.    Linus Torvalds   Relational fields are used to represent model relationships.  They can be applied to  ForeignKey ,  ManyToManyField  and  OneToOneField  relationships, as well as to reverse relationships, and custom relationships such as  GenericForeignKey .   Note:  The relational fields are declared in  relations.py , but by convention you should import them from the  serializers  module, using  from rest_framework import serializers  and refer to fields as  serializers. FieldName .   Inspecting relationships.  When using the  ModelSerializer  class, serializer fields and relationships will be automatically generated for you. Inspecting these automatically generated fields can be a useful tool for determining how to customize the relationship style.  To do so, open the Django shell, using  python manage.py shell , then import the serializer class, instantiate it, and print the object representation\u2026   from myapp.serializers import AccountSerializer  serializer = AccountSerializer()  print repr(serializer)  # Or `print(repr(serializer))` in Python 3.x.\nAccountSerializer():\n    id = IntegerField(label='ID', read_only=True)\n    name = CharField(allow_blank=True, max_length=100, required=False)\n    owner = PrimaryKeyRelatedField(queryset=User.objects.all())", 
             "title": "Serializer relations"
         }, 
         {
@@ -1565,6 +1565,11 @@
             "text": "The built-in  __str__  method of the model will be used to generate string representations of the objects used to populate the  choices  property. These choices are used to populate select HTML inputs in the browsable API.  To provide customized representations for such inputs, override  display_value()  of a  RelatedField  subclass. This method will receive a model object, and should return a string suitable for representing it. For example:  class TrackPrimaryKeyRelatedField(serializers.PrimaryKeyRelatedField):\n    def display_value(self, instance):\n        return 'Track: %s' % (instance.title)", 
             "title": "Customizing the HTML display"
         }, 
+        {
+            "location": "/api-guide/relations/#select-field-cutoffs", 
+            "text": "When rendered in the browsable API relational fields will default to only displaying a maximum of 1000 selectable items. If more items are present then a disabled option with \"More than 1000 items\u2026\" will be displayed.  This behavior is intended to prevent a template from being unable to render in an acceptable timespan due to a very large number of relationships being displayed.  There are two keyword arguments you can use to control this behavior:   html_cutoff  - If set this will be the maximum number of choices that will be displayed by a HTML select drop down. Set to  None  to disable any limiting. Defaults to  1000 .  html_cutoff_text  - If set this will display a textual indicator if the maximum number of items have been cutoff in an HTML select drop down. Defaults to  \"More than {count} items\u2026\"   In cases where the cutoff is being enforced you may want to instead use a plain input field in the HTML form. You can do so using the  style  keyword argument. For example:  assigned_to = serializers.SlugRelatedField(\n   queryset=User.objects.all(),\n   slug field='username',\n   style={'base_template': 'input.html'}\n)", 
+            "title": "Select field cutoffs"
+        }, 
         {
             "location": "/api-guide/relations/#reverse-relations", 
             "text": "Note that reverse relationships are not automatically included by the  ModelSerializer  and  HyperlinkedModelSerializer  classes.  To include a reverse relationship, you must explicitly add it to the fields list.  For example:  class AlbumSerializer(serializers.ModelSerializer):\n    class Meta:\n        fields = ('tracks', ...)  You'll normally want to ensure that you've set an appropriate  related_name  argument on the relationship, that you can use as the field name.  For example:  class Track(models.Model):\n    album = models.ForeignKey(Album, related_name='tracks')\n    ...  If you have not set a related name for the reverse relationship, you'll need to use the automatically generated related name in the  fields  argument.  For example:  class AlbumSerializer(serializers.ModelSerializer):\n    class Meta:\n        fields = ('track_set', ...)  See the Django documentation on  reverse relationships  for more details.", 
@@ -1917,7 +1922,7 @@
         }, 
         {
             "location": "/api-guide/filtering/", 
-            "text": "Filtering\n\n\n\n\nThe 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.\n\n\n \nDjango documentation\n\n\n\n\nThe 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.\n\n\nThe simplest way to filter the queryset of any view that subclasses \nGenericAPIView\n is to override the \n.get_queryset()\n method.\n\n\nOverriding this method allows you to customize the queryset returned by the view in a number of different ways.\n\n\nFiltering against the current user\n\n\nYou might want to filter the queryset to ensure that only results relevant to the currently authenticated user making the request are returned.\n\n\nYou can do so by filtering based on the value of \nrequest.user\n.\n\n\nFor example:\n\n\nfrom myapp.models import Purchase\nfrom myapp.serializers import PurchaseSerializer\nfrom rest_framework import generics\n\nclass PurchaseList(generics.ListAPIView):\n    serializer_class = PurchaseSerializer\n\n    def get_queryset(self):\n        \"\"\"\n        This view should return a list of all the purchases\n        for the currently authenticated user.\n        \"\"\"\n        user = self.request.user\n        return Purchase.objects.filter(purchaser=user)\n\n\n\nFiltering against the URL\n\n\nAnother style of filtering might involve restricting the queryset based on some part of the URL.\n\n\nFor example if your URL config contained an entry like this:\n\n\nurl('^purchases/(?P\nusername\n.+)/$', PurchaseList.as_view()),\n\n\n\nYou could then write a view that returned a purchase queryset filtered by the username portion of the URL:\n\n\nclass PurchaseList(generics.ListAPIView):\n    serializer_class = PurchaseSerializer\n\n    def get_queryset(self):\n        \"\"\"\n        This view should return a list of all the purchases for\n        the user as determined by the username portion of the URL.\n        \"\"\"\n        username = self.kwargs['username']\n        return Purchase.objects.filter(purchaser__username=username)\n\n\n\nFiltering against query parameters\n\n\nA final example of filtering the initial queryset would be to determine the initial queryset based on query parameters in the url.\n\n\nWe can override \n.get_queryset()\n to deal with URLs such as \nhttp://example.com/api/purchases?username=denvercoder9\n, and filter the queryset only if the \nusername\n parameter is included in the URL:\n\n\nclass PurchaseList(generics.ListAPIView):\n    serializer_class = PurchaseSerializer\n\n    def get_queryset(self):\n        \"\"\"\n        Optionally restricts the returned purchases to a given user,\n        by filtering against a `username` query parameter in the URL.\n        \"\"\"\n        queryset = Purchase.objects.all()\n        username = self.request.query_params.get('username', None)\n        if username is not None:\n            queryset = queryset.filter(purchaser__username=username)\n        return queryset\n\n\n\n\n\nGeneric Filtering\n\n\nAs well as being able to override the default queryset, REST framework also includes support for generic filtering backends that allow you to easily construct complex searches and filters.\n\n\nSetting filter backends\n\n\nThe default filter backends may be set globally, using the \nDEFAULT_FILTER_BACKENDS\n setting.  For example.\n\n\nREST_FRAMEWORK = {\n    'DEFAULT_FILTER_BACKENDS': ('rest_framework.filters.DjangoFilterBackend',)\n}\n\n\n\nYou can also set the filter backends on a per-view, or per-viewset basis,\nusing the \nGenericAPIView\n class based views.\n\n\nfrom django.contrib.auth.models import User\nfrom myapp.serializers import UserSerializer\nfrom rest_framework import filters\nfrom rest_framework import generics\n\nclass UserListView(generics.ListAPIView):\n    queryset = User.objects.all()\n    serializer = UserSerializer\n    filter_backends = (filters.DjangoFilterBackend,)\n\n\n\nFiltering and object lookups\n\n\nNote that if a filter backend is configured for a view, then as well as being used to filter list views, it will also be used to filter the querysets used for returning a single object.\n\n\nFor instance, given the previous example, and a product with an id of \n4675\n, the following URL would either return the corresponding object, or return a 404 response, depending on if the filtering conditions were met by the given product instance:\n\n\nhttp://example.com/api/products/4675/?category=clothing\nmax_price=10.00\n\n\n\nOverriding the initial queryset\n\n\nNote that you can use both an overridden \n.get_queryset()\n and generic filtering together, and everything will work as expected.  For example, if \nProduct\n had a many-to-many relationship with \nUser\n, named \npurchase\n, you might want to write a view like this:\n\n\nclass PurchasedProductsList(generics.ListAPIView):\n    \"\"\"\n    Return a list of all the products that the authenticated\n    user has ever purchased, with optional filtering.\n    \"\"\"\n    model = Product\n    serializer_class = ProductSerializer\n    filter_class = ProductFilter\n\n    def get_queryset(self):\n        user = self.request.user\n        return user.purchase_set.all()\n\n\n\n\n\nAPI Guide\n\n\nDjangoFilterBackend\n\n\nThe \nDjangoFilterBackend\n class supports highly customizable field filtering, using the \ndjango-filter package\n.\n\n\nTo use REST framework's \nDjangoFilterBackend\n, first install \ndjango-filter\n.\n\n\npip install django-filter\n\n\n\nSpecifying filter fields\n\n\nIf all you need is simple equality-based filtering, you can set a \nfilter_fields\n attribute on the view, or viewset, listing the set of fields you wish to filter against.\n\n\nclass ProductList(generics.ListAPIView):\n    queryset = Product.objects.all()\n    serializer_class = ProductSerializer\n    filter_backends = (filters.DjangoFilterBackend,)\n    filter_fields = ('category', 'in_stock')\n\n\n\nThis will automatically create a \nFilterSet\n class for the given fields, and will allow you to make requests such as:\n\n\nhttp://example.com/api/products?category=clothing\nin_stock=True\n\n\n\nSpecifying a FilterSet\n\n\nFor more advanced filtering requirements you can specify a \nFilterSet\n class that should be used by the view.  For example:\n\n\nimport django_filters\nfrom myapp.models import Product\nfrom myapp.serializers import ProductSerializer\nfrom rest_framework import generics\n\nclass ProductFilter(django_filters.FilterSet):\n    min_price = django_filters.NumberFilter(name=\"price\", lookup_type='gte')\n    max_price = django_filters.NumberFilter(name=\"price\", lookup_type='lte')\n    class Meta:\n        model = Product\n        fields = ['category', 'in_stock', 'min_price', 'max_price']\n\nclass ProductList(generics.ListAPIView):\n    queryset = Product.objects.all()\n    serializer_class = ProductSerializer\n    filter_backends = (filters.DjangoFilterBackend,)\n    filter_class = ProductFilter\n\n\n\nWhich will allow you to make requests such as:\n\n\nhttp://example.com/api/products?category=clothing\nmax_price=10.00\n\n\n\nYou can also span relationships using \ndjango-filter\n, let's assume that each\nproduct has foreign key to \nManufacturer\n model, so we create filter that\nfilters using \nManufacturer\n name. For example:\n\n\nimport django_filters\nfrom myapp.models import Product\nfrom myapp.serializers import ProductSerializer\nfrom rest_framework import generics\n\nclass ProductFilter(django_filters.FilterSet):\n    class Meta:\n        model = Product\n        fields = ['category', 'in_stock', 'manufacturer__name']\n\n\n\nThis enables us to make queries like:\n\n\nhttp://example.com/api/products?manufacturer__name=foo\n\n\n\nThis is nice, but it exposes the Django's double underscore convention as part of the API.  If you instead want to explicitly name the filter argument you can instead explicitly include it on the \nFilterSet\n class:\n\n\nimport django_filters\nfrom myapp.models import Product\nfrom myapp.serializers import ProductSerializer\nfrom rest_framework import generics\n\nclass ProductFilter(django_filters.FilterSet):\n    manufacturer = django_filters.CharFilter(name=\"manufacturer__name\")\n\n    class Meta:\n        model = Product\n        fields = ['category', 'in_stock', 'manufacturer']\n\n\n\nAnd now you can execute:\n\n\nhttp://example.com/api/products?manufacturer=foo\n\n\n\nFor more details on using filter sets see the \ndjango-filter documentation\n.\n\n\n\n\nHints \n Tips\n\n\n\n\nBy default filtering is not enabled.  If you want to use \nDjangoFilterBackend\n remember to make sure it is installed by using the \n'DEFAULT_FILTER_BACKENDS'\n setting.\n\n\nWhen using boolean fields, you should use the values \nTrue\n and \nFalse\n in the URL query parameters, rather than \n0\n, \n1\n, \ntrue\n or \nfalse\n.  (The allowed boolean values are currently hardwired in Django's \nNullBooleanSelect implementation\n.)\n\n\ndjango-filter\n supports filtering across relationships, using Django's double-underscore syntax.\n\n\nFor Django 1.3 support, make sure to install \ndjango-filter\n version 0.5.4, as later versions drop support for 1.3.\n\n\n\n\n\n\nSearchFilter\n\n\nThe \nSearchFilter\n class supports simple single query parameter based searching, and is based on the \nDjango admin's search functionality\n.\n\n\nThe \nSearchFilter\n class will only be applied if the view has a \nsearch_fields\n attribute set.  The \nsearch_fields\n attribute should be a list of names of text type fields on the model, such as \nCharField\n or \nTextField\n.\n\n\nclass UserListView(generics.ListAPIView):\n    queryset = User.objects.all()\n    serializer = UserSerializer\n    filter_backends = (filters.SearchFilter,)\n    search_fields = ('username', 'email')\n\n\n\nThis will allow the client to filter the items in the list by making queries such as:\n\n\nhttp://example.com/api/users?search=russell\n\n\n\nYou can also perform a related lookup on a ForeignKey or ManyToManyField with the lookup API double-underscore notation:\n\n\nsearch_fields = ('username', 'email', 'profile__profession')\n\n\n\nBy default, searches will use case-insensitive partial matches.  The search parameter may contain multiple search terms, which should be whitespace and/or comma separated.  If multiple search terms are used then objects will be returned in the list only if all the provided terms are matched.\n\n\nThe search behavior may be restricted by prepending various characters to the \nsearch_fields\n.\n\n\n\n\n'^' Starts-with search.\n\n\n'=' Exact matches.\n\n\n'@' Full-text search.  (Currently only supported Django's MySQL backend.)\n\n\n\n\nFor example:\n\n\nsearch_fields = ('=username', '=email')\n\n\n\nBy default, the search parameter is named \n'search\n', but this may be overridden with the \nSEARCH_PARAM\n setting.\n\n\nFor more details, see the \nDjango documentation\n.\n\n\n\n\nOrderingFilter\n\n\nThe \nOrderingFilter\n class supports simple query parameter controlled ordering of results.  By default, the query parameter is named \n'ordering'\n, but this may by overridden with the \nORDERING_PARAM\n setting.\n\n\nFor example, to order users by username:\n\n\nhttp://example.com/api/users?ordering=username\n\n\n\nThe client may also specify reverse orderings by prefixing the field name with '-', like so:\n\n\nhttp://example.com/api/users?ordering=-username\n\n\n\nMultiple orderings may also be specified:\n\n\nhttp://example.com/api/users?ordering=account,username\n\n\n\nSpecifying which fields may be ordered against\n\n\nIt's recommended that you explicitly specify which fields the API should allowing in the ordering filter.  You can do this by setting an \nordering_fields\n attribute on the view, like so:\n\n\nclass UserListView(generics.ListAPIView):\n    queryset = User.objects.all()\n    serializer_class = UserSerializer\n    filter_backends = (filters.OrderingFilter,)\n    ordering_fields = ('username', 'email')\n\n\n\nThis helps prevent unexpected data leakage, such as allowing users to order against a password hash field or other sensitive data.\n\n\nIf you \ndon't\n specify an \nordering_fields\n attribute on the view, the filter class will default to allowing the user to filter on any readable fields on the serializer specified by the \nserializer_class\n attribute.\n\n\nIf you are confident that the queryset being used by the view doesn't contain any sensitive data, you can also explicitly specify that a view should allow ordering on \nany\n model field or queryset aggregate, by using the special value \n'__all__'\n.\n\n\nclass BookingsListView(generics.ListAPIView):\n    queryset = Booking.objects.all()\n    serializer_class = BookingSerializer\n    filter_backends = (filters.OrderingFilter,)\n    ordering_fields = '__all__'\n\n\n\nSpecifying a default ordering\n\n\nIf an \nordering\n attribute is set on the view, this will be used as the default ordering.\n\n\nTypically you'd instead control this by setting \norder_by\n on the initial queryset, but using the \nordering\n parameter on the view allows you to specify the ordering in a way that it can then be passed automatically as context to a rendered template.  This makes it possible to automatically render column headers differently if they are being used to order the results.\n\n\nclass UserListView(generics.ListAPIView):\n    queryset = User.objects.all()\n    serializer_class = UserSerializer\n    filter_backends = (filters.OrderingFilter,)\n    ordering_fields = ('username', 'email')\n    ordering = ('username',)\n\n\n\nThe \nordering\n attribute may be either a string or a list/tuple of strings.\n\n\n\n\nDjangoObjectPermissionsFilter\n\n\nThe \nDjangoObjectPermissionsFilter\n is intended to be used together with the \ndjango-guardian\n package, with custom \n'view'\n permissions added.  The filter will ensure that querysets only returns objects for which the user has the appropriate view permission.\n\n\nThis filter class must be used with views that provide either a \nqueryset\n or a \nmodel\n attribute.\n\n\nIf you're using \nDjangoObjectPermissionsFilter\n, you'll probably also want to add an appropriate object permissions class, to ensure that users can only operate on instances if they have the appropriate object permissions.  The easiest way to do this is to subclass \nDjangoObjectPermissions\n and add \n'view'\n permissions to the \nperms_map\n attribute.\n\n\nA complete example using both \nDjangoObjectPermissionsFilter\n and \nDjangoObjectPermissions\n might look something like this.\n\n\npermissions.py\n:\n\n\nclass CustomObjectPermissions(permissions.DjangoObjectPermissions):\n    \"\"\"\n    Similar to `DjangoObjectPermissions`, but adding 'view' permissions.\n    \"\"\"\n    perms_map = {\n        'GET': ['%(app_label)s.view_%(model_name)s'],\n        'OPTIONS': ['%(app_label)s.view_%(model_name)s'],\n        'HEAD': ['%(app_label)s.view_%(model_name)s'],\n        'POST': ['%(app_label)s.add_%(model_name)s'],\n        'PUT': ['%(app_label)s.change_%(model_name)s'],\n        'PATCH': ['%(app_label)s.change_%(model_name)s'],\n        'DELETE': ['%(app_label)s.delete_%(model_name)s'],\n    }\n\n\n\nviews.py\n:\n\n\nclass EventViewSet(viewsets.ModelViewSet):\n    \"\"\"\n    Viewset that only lists events if user has 'view' permissions, and only\n    allows operations on individual events if user has appropriate 'view', 'add',\n    'change' or 'delete' permissions.\n    \"\"\"\n    queryset = Event.objects.all()\n    serializer = EventSerializer\n    filter_backends = (filters.DjangoObjectPermissionsFilter,)\n    permission_classes = (myapp.permissions.CustomObjectPermissions,)\n\n\n\nFor more information on adding \n'view'\n permissions for models, see the \nrelevant section\n of the \ndjango-guardian\n documentation, and \nthis blogpost\n.\n\n\n\n\nCustom generic filtering\n\n\nYou can also provide your own generic filtering backend, or write an installable app for other developers to use.\n\n\nTo do so override \nBaseFilterBackend\n, and override the \n.filter_queryset(self, request, queryset, view)\n method.  The method should return a new, filtered queryset.\n\n\nAs well as allowing clients to perform searches and filtering, generic filter backends can be useful for restricting which objects should be visible to any given request or user.\n\n\nExample\n\n\nFor example, you might need to restrict users to only being able to see objects they created.\n\n\nclass IsOwnerFilterBackend(filters.BaseFilterBackend):\n    \"\"\"\n    Filter that only allows users to see their own objects.\n    \"\"\"\n    def filter_queryset(self, request, queryset, view):\n        return queryset.filter(owner=request.user)\n\n\n\nWe could achieve the same behavior by overriding \nget_queryset()\n on the views, but using a filter backend allows you to more easily add this restriction to multiple views, or to apply it across the entire API.\n\n\nThird party packages\n\n\nThe following third party packages provide additional filter implementations.\n\n\nDjango REST framework filters package\n\n\nThe \ndjango-rest-framework-filters package\n works together with the \nDjangoFilterBackend\n class, and allows you to easily create filters across relationships, or create multiple filter lookup types for a given field.\n\n\nDjango REST framework full word search filter\n\n\nThe \ndjangorestframework-word-filter\n developed as alternative to \nfilters.SearchFilter\n which will search full word in text, or exact match.", 
+            "text": "Filtering\n\n\n\n\nThe 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.\n\n\n \nDjango documentation\n\n\n\n\nThe 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.\n\n\nThe simplest way to filter the queryset of any view that subclasses \nGenericAPIView\n is to override the \n.get_queryset()\n method.\n\n\nOverriding this method allows you to customize the queryset returned by the view in a number of different ways.\n\n\nFiltering against the current user\n\n\nYou might want to filter the queryset to ensure that only results relevant to the currently authenticated user making the request are returned.\n\n\nYou can do so by filtering based on the value of \nrequest.user\n.\n\n\nFor example:\n\n\nfrom myapp.models import Purchase\nfrom myapp.serializers import PurchaseSerializer\nfrom rest_framework import generics\n\nclass PurchaseList(generics.ListAPIView):\n    serializer_class = PurchaseSerializer\n\n    def get_queryset(self):\n        \"\"\"\n        This view should return a list of all the purchases\n        for the currently authenticated user.\n        \"\"\"\n        user = self.request.user\n        return Purchase.objects.filter(purchaser=user)\n\n\n\nFiltering against the URL\n\n\nAnother style of filtering might involve restricting the queryset based on some part of the URL.\n\n\nFor example if your URL config contained an entry like this:\n\n\nurl('^purchases/(?P\nusername\n.+)/$', PurchaseList.as_view()),\n\n\n\nYou could then write a view that returned a purchase queryset filtered by the username portion of the URL:\n\n\nclass PurchaseList(generics.ListAPIView):\n    serializer_class = PurchaseSerializer\n\n    def get_queryset(self):\n        \"\"\"\n        This view should return a list of all the purchases for\n        the user as determined by the username portion of the URL.\n        \"\"\"\n        username = self.kwargs['username']\n        return Purchase.objects.filter(purchaser__username=username)\n\n\n\nFiltering against query parameters\n\n\nA final example of filtering the initial queryset would be to determine the initial queryset based on query parameters in the url.\n\n\nWe can override \n.get_queryset()\n to deal with URLs such as \nhttp://example.com/api/purchases?username=denvercoder9\n, and filter the queryset only if the \nusername\n parameter is included in the URL:\n\n\nclass PurchaseList(generics.ListAPIView):\n    serializer_class = PurchaseSerializer\n\n    def get_queryset(self):\n        \"\"\"\n        Optionally restricts the returned purchases to a given user,\n        by filtering against a `username` query parameter in the URL.\n        \"\"\"\n        queryset = Purchase.objects.all()\n        username = self.request.query_params.get('username', None)\n        if username is not None:\n            queryset = queryset.filter(purchaser__username=username)\n        return queryset\n\n\n\n\n\nGeneric Filtering\n\n\nAs well as being able to override the default queryset, REST framework also includes support for generic filtering backends that allow you to easily construct complex searches and filters.\n\n\nSetting filter backends\n\n\nThe default filter backends may be set globally, using the \nDEFAULT_FILTER_BACKENDS\n setting.  For example.\n\n\nREST_FRAMEWORK = {\n    'DEFAULT_FILTER_BACKENDS': ('rest_framework.filters.DjangoFilterBackend',)\n}\n\n\n\nYou can also set the filter backends on a per-view, or per-viewset basis,\nusing the \nGenericAPIView\n class based views.\n\n\nfrom django.contrib.auth.models import User\nfrom myapp.serializers import UserSerializer\nfrom rest_framework import filters\nfrom rest_framework import generics\n\nclass UserListView(generics.ListAPIView):\n    queryset = User.objects.all()\n    serializer = UserSerializer\n    filter_backends = (filters.DjangoFilterBackend,)\n\n\n\nFiltering and object lookups\n\n\nNote that if a filter backend is configured for a view, then as well as being used to filter list views, it will also be used to filter the querysets used for returning a single object.\n\n\nFor instance, given the previous example, and a product with an id of \n4675\n, the following URL would either return the corresponding object, or return a 404 response, depending on if the filtering conditions were met by the given product instance:\n\n\nhttp://example.com/api/products/4675/?category=clothing\nmax_price=10.00\n\n\n\nOverriding the initial queryset\n\n\nNote that you can use both an overridden \n.get_queryset()\n and generic filtering together, and everything will work as expected.  For example, if \nProduct\n had a many-to-many relationship with \nUser\n, named \npurchase\n, you might want to write a view like this:\n\n\nclass PurchasedProductsList(generics.ListAPIView):\n    \"\"\"\n    Return a list of all the products that the authenticated\n    user has ever purchased, with optional filtering.\n    \"\"\"\n    model = Product\n    serializer_class = ProductSerializer\n    filter_class = ProductFilter\n\n    def get_queryset(self):\n        user = self.request.user\n        return user.purchase_set.all()\n\n\n\n\n\nAPI Guide\n\n\nDjangoFilterBackend\n\n\nThe \nDjangoFilterBackend\n class supports highly customizable field filtering, using the \ndjango-filter package\n.\n\n\nTo use REST framework's \nDjangoFilterBackend\n, first install \ndjango-filter\n.\n\n\npip install django-filter\n\n\n\nSpecifying filter fields\n\n\nIf all you need is simple equality-based filtering, you can set a \nfilter_fields\n attribute on the view, or viewset, listing the set of fields you wish to filter against.\n\n\nclass ProductList(generics.ListAPIView):\n    queryset = Product.objects.all()\n    serializer_class = ProductSerializer\n    filter_backends = (filters.DjangoFilterBackend,)\n    filter_fields = ('category', 'in_stock')\n\n\n\nThis will automatically create a \nFilterSet\n class for the given fields, and will allow you to make requests such as:\n\n\nhttp://example.com/api/products?category=clothing\nin_stock=True\n\n\n\nSpecifying a FilterSet\n\n\nFor more advanced filtering requirements you can specify a \nFilterSet\n class that should be used by the view.  For example:\n\n\nimport django_filters\nfrom myapp.models import Product\nfrom myapp.serializers import ProductSerializer\nfrom rest_framework import filters\nfrom rest_framework import generics\n\nclass ProductFilter(django_filters.FilterSet):\n    min_price = django_filters.NumberFilter(name=\"price\", lookup_type='gte')\n    max_price = django_filters.NumberFilter(name=\"price\", lookup_type='lte')\n    class Meta:\n        model = Product\n        fields = ['category', 'in_stock', 'min_price', 'max_price']\n\nclass ProductList(generics.ListAPIView):\n    queryset = Product.objects.all()\n    serializer_class = ProductSerializer\n    filter_backends = (filters.DjangoFilterBackend,)\n    filter_class = ProductFilter\n\n\n\nWhich will allow you to make requests such as:\n\n\nhttp://example.com/api/products?category=clothing\nmax_price=10.00\n\n\n\nYou can also span relationships using \ndjango-filter\n, let's assume that each\nproduct has foreign key to \nManufacturer\n model, so we create filter that\nfilters using \nManufacturer\n name. For example:\n\n\nimport django_filters\nfrom myapp.models import Product\nfrom myapp.serializers import ProductSerializer\nfrom rest_framework import generics\n\nclass ProductFilter(django_filters.FilterSet):\n    class Meta:\n        model = Product\n        fields = ['category', 'in_stock', 'manufacturer__name']\n\n\n\nThis enables us to make queries like:\n\n\nhttp://example.com/api/products?manufacturer__name=foo\n\n\n\nThis is nice, but it exposes the Django's double underscore convention as part of the API.  If you instead want to explicitly name the filter argument you can instead explicitly include it on the \nFilterSet\n class:\n\n\nimport django_filters\nfrom myapp.models import Product\nfrom myapp.serializers import ProductSerializer\nfrom rest_framework import generics\n\nclass ProductFilter(django_filters.FilterSet):\n    manufacturer = django_filters.CharFilter(name=\"manufacturer__name\")\n\n    class Meta:\n        model = Product\n        fields = ['category', 'in_stock', 'manufacturer']\n\n\n\nAnd now you can execute:\n\n\nhttp://example.com/api/products?manufacturer=foo\n\n\n\nFor more details on using filter sets see the \ndjango-filter documentation\n.\n\n\n\n\nHints \n Tips\n\n\n\n\nBy default filtering is not enabled.  If you want to use \nDjangoFilterBackend\n remember to make sure it is installed by using the \n'DEFAULT_FILTER_BACKENDS'\n setting.\n\n\nWhen using boolean fields, you should use the values \nTrue\n and \nFalse\n in the URL query parameters, rather than \n0\n, \n1\n, \ntrue\n or \nfalse\n.  (The allowed boolean values are currently hardwired in Django's \nNullBooleanSelect implementation\n.)\n\n\ndjango-filter\n supports filtering across relationships, using Django's double-underscore syntax.\n\n\nFor Django 1.3 support, make sure to install \ndjango-filter\n version 0.5.4, as later versions drop support for 1.3.\n\n\n\n\n\n\nSearchFilter\n\n\nThe \nSearchFilter\n class supports simple single query parameter based searching, and is based on the \nDjango admin's search functionality\n.\n\n\nThe \nSearchFilter\n class will only be applied if the view has a \nsearch_fields\n attribute set.  The \nsearch_fields\n attribute should be a list of names of text type fields on the model, such as \nCharField\n or \nTextField\n.\n\n\nclass UserListView(generics.ListAPIView):\n    queryset = User.objects.all()\n    serializer = UserSerializer\n    filter_backends = (filters.SearchFilter,)\n    search_fields = ('username', 'email')\n\n\n\nThis will allow the client to filter the items in the list by making queries such as:\n\n\nhttp://example.com/api/users?search=russell\n\n\n\nYou can also perform a related lookup on a ForeignKey or ManyToManyField with the lookup API double-underscore notation:\n\n\nsearch_fields = ('username', 'email', 'profile__profession')\n\n\n\nBy default, searches will use case-insensitive partial matches.  The search parameter may contain multiple search terms, which should be whitespace and/or comma separated.  If multiple search terms are used then objects will be returned in the list only if all the provided terms are matched.\n\n\nThe search behavior may be restricted by prepending various characters to the \nsearch_fields\n.\n\n\n\n\n'^' Starts-with search.\n\n\n'=' Exact matches.\n\n\n'@' Full-text search.  (Currently only supported Django's MySQL backend.)\n\n\n'$' Regex search.\n\n\n\n\nFor example:\n\n\nsearch_fields = ('=username', '=email')\n\n\n\nBy default, the search parameter is named \n'search\n', but this may be overridden with the \nSEARCH_PARAM\n setting.\n\n\nFor more details, see the \nDjango documentation\n.\n\n\n\n\nOrderingFilter\n\n\nThe \nOrderingFilter\n class supports simple query parameter controlled ordering of results.  By default, the query parameter is named \n'ordering'\n, but this may by overridden with the \nORDERING_PARAM\n setting.\n\n\nFor example, to order users by username:\n\n\nhttp://example.com/api/users?ordering=username\n\n\n\nThe client may also specify reverse orderings by prefixing the field name with '-', like so:\n\n\nhttp://example.com/api/users?ordering=-username\n\n\n\nMultiple orderings may also be specified:\n\n\nhttp://example.com/api/users?ordering=account,username\n\n\n\nSpecifying which fields may be ordered against\n\n\nIt's recommended that you explicitly specify which fields the API should allowing in the ordering filter.  You can do this by setting an \nordering_fields\n attribute on the view, like so:\n\n\nclass UserListView(generics.ListAPIView):\n    queryset = User.objects.all()\n    serializer_class = UserSerializer\n    filter_backends = (filters.OrderingFilter,)\n    ordering_fields = ('username', 'email')\n\n\n\nThis helps prevent unexpected data leakage, such as allowing users to order against a password hash field or other sensitive data.\n\n\nIf you \ndon't\n specify an \nordering_fields\n attribute on the view, the filter class will default to allowing the user to filter on any readable fields on the serializer specified by the \nserializer_class\n attribute.\n\n\nIf you are confident that the queryset being used by the view doesn't contain any sensitive data, you can also explicitly specify that a view should allow ordering on \nany\n model field or queryset aggregate, by using the special value \n'__all__'\n.\n\n\nclass BookingsListView(generics.ListAPIView):\n    queryset = Booking.objects.all()\n    serializer_class = BookingSerializer\n    filter_backends = (filters.OrderingFilter,)\n    ordering_fields = '__all__'\n\n\n\nSpecifying a default ordering\n\n\nIf an \nordering\n attribute is set on the view, this will be used as the default ordering.\n\n\nTypically you'd instead control this by setting \norder_by\n on the initial queryset, but using the \nordering\n parameter on the view allows you to specify the ordering in a way that it can then be passed automatically as context to a rendered template.  This makes it possible to automatically render column headers differently if they are being used to order the results.\n\n\nclass UserListView(generics.ListAPIView):\n    queryset = User.objects.all()\n    serializer_class = UserSerializer\n    filter_backends = (filters.OrderingFilter,)\n    ordering_fields = ('username', 'email')\n    ordering = ('username',)\n\n\n\nThe \nordering\n attribute may be either a string or a list/tuple of strings.\n\n\n\n\nDjangoObjectPermissionsFilter\n\n\nThe \nDjangoObjectPermissionsFilter\n is intended to be used together with the \ndjango-guardian\n package, with custom \n'view'\n permissions added.  The filter will ensure that querysets only returns objects for which the user has the appropriate view permission.\n\n\nThis filter class must be used with views that provide either a \nqueryset\n or a \nmodel\n attribute.\n\n\nIf you're using \nDjangoObjectPermissionsFilter\n, you'll probably also want to add an appropriate object permissions class, to ensure that users can only operate on instances if they have the appropriate object permissions.  The easiest way to do this is to subclass \nDjangoObjectPermissions\n and add \n'view'\n permissions to the \nperms_map\n attribute.\n\n\nA complete example using both \nDjangoObjectPermissionsFilter\n and \nDjangoObjectPermissions\n might look something like this.\n\n\npermissions.py\n:\n\n\nclass CustomObjectPermissions(permissions.DjangoObjectPermissions):\n    \"\"\"\n    Similar to `DjangoObjectPermissions`, but adding 'view' permissions.\n    \"\"\"\n    perms_map = {\n        'GET': ['%(app_label)s.view_%(model_name)s'],\n        'OPTIONS': ['%(app_label)s.view_%(model_name)s'],\n        'HEAD': ['%(app_label)s.view_%(model_name)s'],\n        'POST': ['%(app_label)s.add_%(model_name)s'],\n        'PUT': ['%(app_label)s.change_%(model_name)s'],\n        'PATCH': ['%(app_label)s.change_%(model_name)s'],\n        'DELETE': ['%(app_label)s.delete_%(model_name)s'],\n    }\n\n\n\nviews.py\n:\n\n\nclass EventViewSet(viewsets.ModelViewSet):\n    \"\"\"\n    Viewset that only lists events if user has 'view' permissions, and only\n    allows operations on individual events if user has appropriate 'view', 'add',\n    'change' or 'delete' permissions.\n    \"\"\"\n    queryset = Event.objects.all()\n    serializer = EventSerializer\n    filter_backends = (filters.DjangoObjectPermissionsFilter,)\n    permission_classes = (myapp.permissions.CustomObjectPermissions,)\n\n\n\nFor more information on adding \n'view'\n permissions for models, see the \nrelevant section\n of the \ndjango-guardian\n documentation, and \nthis blogpost\n.\n\n\n\n\nCustom generic filtering\n\n\nYou can also provide your own generic filtering backend, or write an installable app for other developers to use.\n\n\nTo do so override \nBaseFilterBackend\n, and override the \n.filter_queryset(self, request, queryset, view)\n method.  The method should return a new, filtered queryset.\n\n\nAs well as allowing clients to perform searches and filtering, generic filter backends can be useful for restricting which objects should be visible to any given request or user.\n\n\nExample\n\n\nFor example, you might need to restrict users to only being able to see objects they created.\n\n\nclass IsOwnerFilterBackend(filters.BaseFilterBackend):\n    \"\"\"\n    Filter that only allows users to see their own objects.\n    \"\"\"\n    def filter_queryset(self, request, queryset, view):\n        return queryset.filter(owner=request.user)\n\n\n\nWe could achieve the same behavior by overriding \nget_queryset()\n on the views, but using a filter backend allows you to more easily add this restriction to multiple views, or to apply it across the entire API.\n\n\nThird party packages\n\n\nThe following third party packages provide additional filter implementations.\n\n\nDjango REST framework filters package\n\n\nThe \ndjango-rest-framework-filters package\n works together with the \nDjangoFilterBackend\n class, and allows you to easily create filters across relationships, or create multiple filter lookup types for a given field.\n\n\nDjango REST framework full word search filter\n\n\nThe \ndjangorestframework-word-filter\n developed as alternative to \nfilters.SearchFilter\n which will search full word in text, or exact match.", 
             "title": "Filtering"
         }, 
         {
@@ -1967,12 +1972,12 @@
         }, 
         {
             "location": "/api-guide/filtering/#djangofilterbackend", 
-            "text": "The  DjangoFilterBackend  class supports highly customizable field filtering, using the  django-filter package .  To use REST framework's  DjangoFilterBackend , first install  django-filter .  pip install django-filter  Specifying filter fields  If all you need is simple equality-based filtering, you can set a  filter_fields  attribute on the view, or viewset, listing the set of fields you wish to filter against.  class ProductList(generics.ListAPIView):\n    queryset = Product.objects.all()\n    serializer_class = ProductSerializer\n    filter_backends = (filters.DjangoFilterBackend,)\n    filter_fields = ('category', 'in_stock')  This will automatically create a  FilterSet  class for the given fields, and will allow you to make requests such as:  http://example.com/api/products?category=clothing in_stock=True  Specifying a FilterSet  For more advanced filtering requirements you can specify a  FilterSet  class that should be used by the view.  For example:  import django_filters\nfrom myapp.models import Product\nfrom myapp.serializers import ProductSerializer\nfrom rest_framework import generics\n\nclass ProductFilter(django_filters.FilterSet):\n    min_price = django_filters.NumberFilter(name=\"price\", lookup_type='gte')\n    max_price = django_filters.NumberFilter(name=\"price\", lookup_type='lte')\n    class Meta:\n        model = Product\n        fields = ['category', 'in_stock', 'min_price', 'max_price']\n\nclass ProductList(generics.ListAPIView):\n    queryset = Product.objects.all()\n    serializer_class = ProductSerializer\n    filter_backends = (filters.DjangoFilterBackend,)\n    filter_class = ProductFilter  Which will allow you to make requests such as:  http://example.com/api/products?category=clothing max_price=10.00  You can also span relationships using  django-filter , let's assume that each\nproduct has foreign key to  Manufacturer  model, so we create filter that\nfilters using  Manufacturer  name. For example:  import django_filters\nfrom myapp.models import Product\nfrom myapp.serializers import ProductSerializer\nfrom rest_framework import generics\n\nclass ProductFilter(django_filters.FilterSet):\n    class Meta:\n        model = Product\n        fields = ['category', 'in_stock', 'manufacturer__name']  This enables us to make queries like:  http://example.com/api/products?manufacturer__name=foo  This is nice, but it exposes the Django's double underscore convention as part of the API.  If you instead want to explicitly name the filter argument you can instead explicitly include it on the  FilterSet  class:  import django_filters\nfrom myapp.models import Product\nfrom myapp.serializers import ProductSerializer\nfrom rest_framework import generics\n\nclass ProductFilter(django_filters.FilterSet):\n    manufacturer = django_filters.CharFilter(name=\"manufacturer__name\")\n\n    class Meta:\n        model = Product\n        fields = ['category', 'in_stock', 'manufacturer']  And now you can execute:  http://example.com/api/products?manufacturer=foo  For more details on using filter sets see the  django-filter documentation .   Hints   Tips   By default filtering is not enabled.  If you want to use  DjangoFilterBackend  remember to make sure it is installed by using the  'DEFAULT_FILTER_BACKENDS'  setting.  When using boolean fields, you should use the values  True  and  False  in the URL query parameters, rather than  0 ,  1 ,  true  or  false .  (The allowed boolean values are currently hardwired in Django's  NullBooleanSelect implementation .)  django-filter  supports filtering across relationships, using Django's double-underscore syntax.  For Django 1.3 support, make sure to install  django-filter  version 0.5.4, as later versions drop support for 1.3.", 
+            "text": "The  DjangoFilterBackend  class supports highly customizable field filtering, using the  django-filter package .  To use REST framework's  DjangoFilterBackend , first install  django-filter .  pip install django-filter  Specifying filter fields  If all you need is simple equality-based filtering, you can set a  filter_fields  attribute on the view, or viewset, listing the set of fields you wish to filter against.  class ProductList(generics.ListAPIView):\n    queryset = Product.objects.all()\n    serializer_class = ProductSerializer\n    filter_backends = (filters.DjangoFilterBackend,)\n    filter_fields = ('category', 'in_stock')  This will automatically create a  FilterSet  class for the given fields, and will allow you to make requests such as:  http://example.com/api/products?category=clothing in_stock=True  Specifying a FilterSet  For more advanced filtering requirements you can specify a  FilterSet  class that should be used by the view.  For example:  import django_filters\nfrom myapp.models import Product\nfrom myapp.serializers import ProductSerializer\nfrom rest_framework import filters\nfrom rest_framework import generics\n\nclass ProductFilter(django_filters.FilterSet):\n    min_price = django_filters.NumberFilter(name=\"price\", lookup_type='gte')\n    max_price = django_filters.NumberFilter(name=\"price\", lookup_type='lte')\n    class Meta:\n        model = Product\n        fields = ['category', 'in_stock', 'min_price', 'max_price']\n\nclass ProductList(generics.ListAPIView):\n    queryset = Product.objects.all()\n    serializer_class = ProductSerializer\n    filter_backends = (filters.DjangoFilterBackend,)\n    filter_class = ProductFilter  Which will allow you to make requests such as:  http://example.com/api/products?category=clothing max_price=10.00  You can also span relationships using  django-filter , let's assume that each\nproduct has foreign key to  Manufacturer  model, so we create filter that\nfilters using  Manufacturer  name. For example:  import django_filters\nfrom myapp.models import Product\nfrom myapp.serializers import ProductSerializer\nfrom rest_framework import generics\n\nclass ProductFilter(django_filters.FilterSet):\n    class Meta:\n        model = Product\n        fields = ['category', 'in_stock', 'manufacturer__name']  This enables us to make queries like:  http://example.com/api/products?manufacturer__name=foo  This is nice, but it exposes the Django's double underscore convention as part of the API.  If you instead want to explicitly name the filter argument you can instead explicitly include it on the  FilterSet  class:  import django_filters\nfrom myapp.models import Product\nfrom myapp.serializers import ProductSerializer\nfrom rest_framework import generics\n\nclass ProductFilter(django_filters.FilterSet):\n    manufacturer = django_filters.CharFilter(name=\"manufacturer__name\")\n\n    class Meta:\n        model = Product\n        fields = ['category', 'in_stock', 'manufacturer']  And now you can execute:  http://example.com/api/products?manufacturer=foo  For more details on using filter sets see the  django-filter documentation .   Hints   Tips   By default filtering is not enabled.  If you want to use  DjangoFilterBackend  remember to make sure it is installed by using the  'DEFAULT_FILTER_BACKENDS'  setting.  When using boolean fields, you should use the values  True  and  False  in the URL query parameters, rather than  0 ,  1 ,  true  or  false .  (The allowed boolean values are currently hardwired in Django's  NullBooleanSelect implementation .)  django-filter  supports filtering across relationships, using Django's double-underscore syntax.  For Django 1.3 support, make sure to install  django-filter  version 0.5.4, as later versions drop support for 1.3.", 
             "title": "DjangoFilterBackend"
         }, 
         {
             "location": "/api-guide/filtering/#searchfilter", 
-            "text": "The  SearchFilter  class supports simple single query parameter based searching, and is based on the  Django admin's search functionality .  The  SearchFilter  class will only be applied if the view has a  search_fields  attribute set.  The  search_fields  attribute should be a list of names of text type fields on the model, such as  CharField  or  TextField .  class UserListView(generics.ListAPIView):\n    queryset = User.objects.all()\n    serializer = UserSerializer\n    filter_backends = (filters.SearchFilter,)\n    search_fields = ('username', 'email')  This will allow the client to filter the items in the list by making queries such as:  http://example.com/api/users?search=russell  You can also perform a related lookup on a ForeignKey or ManyToManyField with the lookup API double-underscore notation:  search_fields = ('username', 'email', 'profile__profession')  By default, searches will use case-insensitive partial matches.  The search parameter may contain multiple search terms, which should be whitespace and/or comma separated.  If multiple search terms are used then objects will be returned in the list only if all the provided terms are matched.  The search behavior may be restricted by prepending various characters to the  search_fields .   '^' Starts-with search.  '=' Exact matches.  '@' Full-text search.  (Currently only supported Django's MySQL backend.)   For example:  search_fields = ('=username', '=email')  By default, the search parameter is named  'search ', but this may be overridden with the  SEARCH_PARAM  setting.  For more details, see the  Django documentation .", 
+            "text": "The  SearchFilter  class supports simple single query parameter based searching, and is based on the  Django admin's search functionality .  The  SearchFilter  class will only be applied if the view has a  search_fields  attribute set.  The  search_fields  attribute should be a list of names of text type fields on the model, such as  CharField  or  TextField .  class UserListView(generics.ListAPIView):\n    queryset = User.objects.all()\n    serializer = UserSerializer\n    filter_backends = (filters.SearchFilter,)\n    search_fields = ('username', 'email')  This will allow the client to filter the items in the list by making queries such as:  http://example.com/api/users?search=russell  You can also perform a related lookup on a ForeignKey or ManyToManyField with the lookup API double-underscore notation:  search_fields = ('username', 'email', 'profile__profession')  By default, searches will use case-insensitive partial matches.  The search parameter may contain multiple search terms, which should be whitespace and/or comma separated.  If multiple search terms are used then objects will be returned in the list only if all the provided terms are matched.  The search behavior may be restricted by prepending various characters to the  search_fields .   '^' Starts-with search.  '=' Exact matches.  '@' Full-text search.  (Currently only supported Django's MySQL backend.)  '$' Regex search.   For example:  search_fields = ('=username', '=email')  By default, the search parameter is named  'search ', but this may be overridden with the  SEARCH_PARAM  setting.  For more details, see the  Django documentation .", 
             "title": "SearchFilter"
         }, 
         {
@@ -2997,7 +3002,7 @@
         }, 
         {
             "location": "/topics/release-notes/", 
-            "text": "Release Notes\n\n\n\n\nRelease Early, Release Often\n\n\n Eric S. Raymond, \nThe Cathedral and the Bazaar\n.\n\n\n\n\nVersioning\n\n\nMinor version numbers (0.0.x) are used for changes that are API compatible.  You should be able to upgrade between minor point releases without any other code changes.\n\n\nMedium version numbers (0.x.0) may include API changes, in line with the \ndeprecation policy\n.  You should read the release notes carefully before upgrading between medium point releases.\n\n\nMajor version numbers (x.0.0) are reserved for substantial project milestones.\n\n\nDeprecation policy\n\n\nREST framework releases follow a formal deprecation policy, which is in line with \nDjango's deprecation policy\n.\n\n\nThe timeline for deprecation of a feature present in version 1.0 would work as follows:\n\n\n\n\n\n\nVersion 1.1 would remain \nfully backwards compatible\n with 1.0, but would raise \nPendingDeprecationWarning\n warnings if you use the feature that are due to be deprecated.  These warnings are \nsilent by default\n, but can be explicitly enabled when you're ready to start migrating any required changes.  For example if you start running your tests using \npython -Wd manage.py test\n, you'll be warned of any API changes you need to make.\n\n\n\n\n\n\nVersion 1.2 would escalate these warnings to \nDeprecationWarning\n, which is loud by default.\n\n\n\n\n\n\nVersion 1.3 would remove the deprecated bits of API entirely.\n\n\n\n\n\n\nNote that in line with Django's policy, any parts of the framework not mentioned in the documentation should generally be considered private API, and may be subject to change.\n\n\nUpgrading\n\n\nTo upgrade Django REST framework to the latest version, use pip:\n\n\npip install -U djangorestframework\n\n\n\nYou can determine your currently installed version using \npip freeze\n:\n\n\npip freeze | grep djangorestframework\n\n\n\n\n\n3.2.x series\n\n\n3.2.2\n\n\nDate\n: \n13th August 2015\n.\n\n\n\n\nAdd \ndisplay_value()\n method for use when displaying relational field select inputs. (\n#3254\n)\n\n\nFix issue with \nBooleanField\n checkboxes incorrectly displaying as checked. (\n#3258\n)\n\n\nEnsure empty checkboxes properly set \nBooleanField\n to \nFalse\n in all cases. (\n#2776\n)\n\n\nAllow \nWSGIRequest.FILES\n property without raising incorrect deprecated error. (\n#3261\n)\n\n\nResolve issue with rendering nested serializers in forms. (\n#3260\n)\n\n\nRaise an error if user accidentally pass a serializer instance to a response, rather than data. (\n#3241\n)\n\n\n\n\n3.2.1\n\n\nDate\n: \n7th August 2015\n.\n\n\n\n\nFix for relational select widgets rendering without any choices. (\n#3237\n)\n\n\nFix for \n1\n, \n0\n rendering as \ntrue\n, \nfalse\n in the admin interface. \n#3227\n)\n\n\nFix for ListFields with single value in HTML form input. (\n#3238\n)\n\n\nAllow \nrequest.FILES\n for compat with Django's \nHTTPRequest\n class. (\n#3239\n)\n\n\n\n\n3.2.0\n\n\nDate\n: \n6th August 2015\n.\n\n\n\n\nAdd \nAdminRenderer\n. (\n#2926\n)\n\n\nAdd \nFilePathField\n. (\n#1854\n)\n\n\nAdd \nallow_empty\n to \nListField\n. (\n#2250\n)\n\n\nSupport django-guardian 1.3. (\n#3165\n)\n\n\nSupport grouped choices. (\n#3225\n)\n\n\nSupport error forms in browsable API. (\n#3024\n)\n\n\nAllow permission classes to customize the error message. (\n#2539\n)\n\n\nSupport \nsource=\nmethod\n on hyperlinked fields. (\n#2690\n)\n\n\nListField(allow_null=True)\n now allows null as the list value, not null items in the list. (\n#2766\n)\n\n\nManyToMany()\n maps to \nallow_empty=False\n, \nManyToMany(blank=True)\n maps to \nallow_empty=True\n. (\n#2804\n)\n\n\nSupport custom serialization styles for primary key fields. (\n#2789\n)\n\n\nOPTIONS\n requests support nested representations. (\n#2915\n)\n\n\nSet \nview.action == \"metadata\"\n for viewsets with \nOPTIONS\n requests. (\n#3115\n)\n\n\nSupport \nallow_blank\n on \nUUIDField\n. ([#3130][gh#3130])\n\n\nDo not display view docstrings with 401 or 403 response codes. (\n#3216\n)\n\n\nResolve Django 1.8 deprecation warnings. (\n#2886\n)\n\n\nFix for \nDecimalField\n validation. (\n#3139\n)\n\n\nFix behavior of \nallow_blank=False\n when used with \ntrim_whitespace=True\n. (\n#2712\n)\n\n\nFix issue with some field combinations incorrectly mapping to an invalid \nallow_blank\n argument. (\n#3011\n)\n\n\nFix for output representations with prefetches and modified querysets. (\n#2704\n, \n#2727\n)\n\n\nFix assertion error when CursorPagination is provided with certains invalid query parameters. (#2920)\ngh2920\n.\n\n\nFix \nUnicodeDecodeError\n when invalid characters included in header with \nTokenAuthentication\n. (\n#2928\n)\n\n\nFix transaction rollbacks with \n@non_atomic_requests\n decorator. (\n#3016\n)\n\n\nFix duplicate results issue with Oracle databases using \nSearchFilter\n. (\n#2935\n)\n\n\nFix checkbox alignment and rendering in browsable API forms. (\n#2783\n)\n\n\nFix for unsaved file objects which should use \n\"url\": null\n in the representation. (\n#2759\n)\n\n\nFix field value rendering in browsable API. (\n#2416\n)\n\n\nFix \nHStoreField\n to include \nallow_blank=True\n in \nDictField\n mapping. (\n#2659\n)\n\n\nNumerous other cleanups, improvements to error messaging, private API \n minor fixes.\n\n\n\n\n\n\n3.1.x series\n\n\n3.1.3\n\n\nDate\n: \n4th June 2015\n.\n\n\n\n\nAdd \nDurationField\n. (\n#2481\n, \n#2989\n)\n\n\nAdd \nformat\n argument to \nUUIDField\n. (\n#2788\n, \n#3000\n)\n\n\nMultipleChoiceField\n empties incorrectly on a partial update using multipart/form-data (\n#2993\n, \n#2894\n)\n\n\nFix a bug in options related to read-only \nRelatedField\n. (\n#2981\n, \n#2811\n)\n\n\nFix nested serializers with \nunique_together\n relations. (\n#2975\n)\n\n\nAllow unexpected values for \nChoiceField\n/\nMultipleChoiceField\n representations. (\n#2839\n, \n#2940\n)\n\n\nRollback the transaction on error if \nATOMIC_REQUESTS\n is set. (\n#2887\n, \n#2034\n)\n\n\nSet the action on a view when override_method regardless of its None-ness. (\n#2933\n)\n\n\nDecimalField\n accepts \n2E+2\n as 200 and validates decimal place correctly. (\n#2948\n, \n#2947\n)\n\n\nSupport basic authentication with custom \nUserModel\n that change \nusername\n. (\n#2952\n)\n\n\nIPAddressField\n improvements. (\n#2747\n, \n#2618\n, \n#3008\n)\n\n\nImprove \nDecimalField\n for easier subclassing. (\n#2695\n)\n\n\n\n\n3.1.2\n\n\nDate\n: \n13rd May 2015\n.\n\n\n\n\nDateField.to_representation\n can handle str and empty values. (\n#2656\n, \n#2687\n, \n#2869\n)\n\n\nUse default reason phrases from HTTP standard. (\n#2764\n, \n#2763\n)\n\n\nRaise error when \nModelSerializer\n used with abstract model. (\n#2757\n, \n#2630\n)\n\n\nHandle reversal of non-API view_name in \nHyperLinkedRelatedField\n (\n#2724\n, \n#2711\n)\n\n\nDont require pk strictly for related fields. (\n#2745\n, \n#2754\n)\n\n\nMetadata detects null boolean field type. (\n#2762\n)\n\n\nProper handling of depth in nested serializers. (\n#2798\n)\n\n\nDisplay viewset without paginator. (\n#2807\n)\n\n\nDon't check for deprecated \n.model\n attribute in permissions (\n#2818\n)\n\n\nRestrict integer field to integers and strings. (\n#2835\n, \n#2836\n)\n\n\nImprove \nIntegerField\n to use compiled decimal regex. (\n#2853\n)\n\n\nPrevent empty \nqueryset\n to raise AssertionError. (\n#2862\n)\n\n\nDjangoModelPermissions\n rely on \nget_queryset\n. (\n#2863\n)\n\n\nCheck \nAcceptHeaderVersioning\n with content negotiation in place. (\n#2868\n)\n\n\nAllow \nDjangoObjectPermissions\n to use views that define \nget_queryset\n. (\n#2905\n)\n\n\n\n\n3.1.1\n\n\nDate\n: \n23rd March 2015\n.\n\n\n\n\nSecurity fix\n: Escape tab switching cookie name in browsable API.\n\n\nDisplay input forms in browsable API if \nserializer_class\n is used, even when \nget_serializer\n method does not exist on the view. (\n#2743\n)\n\n\nUse a password input for the AuthTokenSerializer. (\n#2741\n)\n\n\nFix missing anchor closing tag after next button. (\n#2691\n)\n\n\nFix \nlookup_url_kwarg\n handling in viewsets. (\n#2685\n, \n#2591\n)\n\n\nFix problem with importing \nrest_framework.views\n in \napps.py\n (\n#2678\n)\n\n\nLimitOffsetPagination raises \nTypeError\n if PAGE_SIZE not set (\n#2667\n, \n#2700\n)\n\n\nGerman translation for \nmin_value\n field error message references \nmax_value\n. (\n#2645\n)\n\n\nRemove \nMergeDict\n. (\n#2640\n)\n\n\nSupport serializing unsaved models with related fields. (\n#2637\n, \n#2641\n)\n\n\nAllow blank/null on radio.html choices. (\n#2631\n)\n\n\n\n\n3.1.0\n\n\nDate\n: \n5th March 2015\n.\n\n\nFor full details see the \n3.1 release announcement\n.\n\n\n\n\n3.0.x series\n\n\n3.0.5\n\n\nDate\n: \n10th February 2015\n.\n\n\n\n\nFix a bug where \n_closable_objects\n breaks pickling. (\n#1850\n, \n#2492\n)\n\n\nAllow non-standard \nUser\n models with \nThrottling\n. (\n#2524\n)\n\n\nSupport custom \nUser.db_table\n in TokenAuthentication migration. (\n#2479\n)\n\n\nFix misleading \nAttributeError\n tracebacks on \nRequest\n objects. (\n#2530\n, \n#2108\n)\n\n\nManyRelatedField.get_value\n clearing field on partial update. (\n#2475\n)\n\n\nRemoved '.model' shortcut from code. (\n#2486\n)\n\n\nFix \ndetail_route\n and \nlist_route\n mutable argument. (\n#2518\n)\n\n\nPrefetching the user object when getting the token in \nTokenAuthentication\n. (\n#2519\n)\n\n\n\n\n3.0.4\n\n\nDate\n: \n28th January 2015\n.\n\n\n\n\nDjango 1.8a1 support. (\n#2425\n, \n#2446\n, \n#2441\n)\n\n\nAdd \nDictField\n and support Django 1.8 \nHStoreField\n. (\n#2451\n, \n#2106\n)\n\n\nAdd \nUUIDField\n and support Django 1.8 \nUUIDField\n. (\n#2448\n, \n#2433\n, \n#2432\n)\n\n\nBaseRenderer.render\n now raises \nNotImplementedError\n. (\n#2434\n)\n\n\nFix timedelta JSON serialization on Python 2.6. (\n#2430\n)\n\n\nResultDict\n and \nResultList\n now appear as standard dict/list. (\n#2421\n)\n\n\nFix visible \nHiddenField\n in the HTML form of the web browsable API page. (\n#2410\n)\n\n\nUse \nOrderedDict\n for \nRelatedField.choices\n. (\n#2408\n)\n\n\nFix ident format when using \nHTTP_X_FORWARDED_FOR\n. (\n#2401\n)\n\n\nFix invalid key with memcached while using throttling. (\n#2400\n)\n\n\nFix \nFileUploadParser\n with version 3.x. (\n#2399\n)\n\n\nFix the serializer inheritance. (\n#2388\n)\n\n\nFix caching issues with \nReturnDict\n. (\n#2360\n)\n\n\n\n\n3.0.3\n\n\nDate\n: \n8th January 2015\n.\n\n\n\n\nFix \nMinValueValidator\n on \nmodels.DateField\n. (\n#2369\n)\n\n\nFix serializer missing context when pagination is used. (\n#2355\n)\n\n\nNamespaced router URLs are now supported by the \nDefaultRouter\n. (\n#2351\n)\n\n\nrequired=False\n allows omission of value for output. (\n#2342\n)\n\n\nUse textarea input for \nmodels.TextField\n. (\n#2340\n)\n\n\nUse custom \nListSerializer\n for pagination if required. (\n#2331\n, \n#2327\n)\n\n\nBetter behavior with null and '' for blank HTML fields. (\n#2330\n)\n\n\nEnsure fields in \nexclude\n are model fields. (\n#2319\n)\n\n\nFix \nIntegerField\n and \nmax_length\n argument incompatibility. (\n#2317\n)\n\n\nFix the YAML encoder for 3.0 serializers. (\n#2315\n, \n#2283\n)\n\n\nFix the behavior of empty HTML fields. (\n#2311\n, \n#1101\n)\n\n\nFix Metaclass attribute depth ignoring fields attribute. (\n#2287\n)\n\n\nFix \nformat_suffix_patterns\n to work with Django's \ni18n_patterns\n. (\n#2278\n)\n\n\nAbility to customize router URLs for custom actions, using \nurl_path\n. (\n#2010\n)\n\n\nDon't install Django REST Framework as egg. (\n#2386\n)\n\n\n\n\n3.0.2\n\n\nDate\n: \n17th December 2014\n.\n\n\n\n\nEnsure \nrequest.user\n is made available to response middleware. (\n#2155\n)\n\n\nClient.logout()\n also cancels any existing \nforce_authenticate\n. (\n#2218\n, \n#2259\n)\n\n\nExtra assertions and better checks to preventing incorrect serializer API use. (\n#2228\n, \n#2234\n, \n#2262\n, \n#2263\n, \n#2266\n, \n#2267\n, \n#2289\n, \n#2291\n)\n\n\nFixed \nmin_length\n message for \nCharField\n. (\n#2255\n)\n\n\nFix \nUnicodeDecodeError\n, which can occur on serializer \nrepr\n.  (\n#2270\n, \n#2279\n)\n\n\nFix empty HTML values when a default is provided. (\n#2280\n, \n#2294\n)\n\n\nFix \nSlugRelatedField\n raising \nUnicodeEncodeError\n when used as a multiple choice input. (\n#2290\n)\n\n\n\n\n3.0.1\n\n\nDate\n: \n11th December 2014\n.\n\n\n\n\nMore helpful error message when the default Serializer \ncreate()\n fails. (\n#2013\n)\n\n\nRaise error when attempting to save serializer if data is not valid. (\n#2098\n)\n\n\nFix \nFileUploadParser\n breaks with empty file names and multiple upload handlers. (\n#2109\n)\n\n\nImprove \nBindingDict\n to support standard dict-functions. (\n#2135\n, \n#2163\n)\n\n\nAdd \nvalidate()\n to \nListSerializer\n. (\n#2168\n, \n#2225\n, \n#2232\n)\n\n\nFix JSONP renderer failing to escape some characters. (\n#2169\n, \n#2195\n)\n\n\nAdd missing default style for \nFileField\n. (\n#2172\n)\n\n\nActions are required when calling \nViewSet.as_view()\n. (\n#2175\n)\n\n\nAdd \nallow_blank\n to \nChoiceField\n. (\n#2184\n, \n#2239\n)\n\n\nCosmetic fixes in the HTML renderer. (\n#2187\n)\n\n\nRaise error if \nfields\n on serializer is not a list of strings. (\n#2193\n, \n#2213\n)\n\n\nImprove checks for nested creates and updates. (\n#2194\n, \n#2196\n)\n\n\nvalidated_attrs\n argument renamed to \nvalidated_data\n in \nSerializer\n \ncreate()\n/\nupdate()\n. (\n#2197\n)\n\n\nRemove deprecated code to reflect the dropped Django versions. (\n#2200\n)\n\n\nBetter serializer errors for nested writes. (\n#2202\n, \n#2215\n)\n\n\nFix pagination and custom permissions incompatibility. (\n#2205\n)\n\n\nRaise error if \nfields\n on serializer is not a list of strings. (\n#2213\n)\n\n\nAdd missing translation markers for relational fields. (\n#2231\n)\n\n\nImprove field lookup behavior for dicts/mappings. (\n#2244\n, \n#2243\n)\n\n\nOptimized hyperlinked PK. (\n#2242\n)\n\n\n\n\n3.0.0\n\n\nDate\n: 1st December 2014\n\n\nFor full details see the \n3.0 release announcement\n.\n\n\n\n\nFor older release notes, \nplease see the version 2.x documentation\n.", 
+            "text": "Release Notes\n\n\n\n\nRelease Early, Release Often\n\n\n Eric S. Raymond, \nThe Cathedral and the Bazaar\n.\n\n\n\n\nVersioning\n\n\nMinor version numbers (0.0.x) are used for changes that are API compatible.  You should be able to upgrade between minor point releases without any other code changes.\n\n\nMedium version numbers (0.x.0) may include API changes, in line with the \ndeprecation policy\n.  You should read the release notes carefully before upgrading between medium point releases.\n\n\nMajor version numbers (x.0.0) are reserved for substantial project milestones.\n\n\nDeprecation policy\n\n\nREST framework releases follow a formal deprecation policy, which is in line with \nDjango's deprecation policy\n.\n\n\nThe timeline for deprecation of a feature present in version 1.0 would work as follows:\n\n\n\n\n\n\nVersion 1.1 would remain \nfully backwards compatible\n with 1.0, but would raise \nPendingDeprecationWarning\n warnings if you use the feature that are due to be deprecated.  These warnings are \nsilent by default\n, but can be explicitly enabled when you're ready to start migrating any required changes.  For example if you start running your tests using \npython -Wd manage.py test\n, you'll be warned of any API changes you need to make.\n\n\n\n\n\n\nVersion 1.2 would escalate these warnings to \nDeprecationWarning\n, which is loud by default.\n\n\n\n\n\n\nVersion 1.3 would remove the deprecated bits of API entirely.\n\n\n\n\n\n\nNote that in line with Django's policy, any parts of the framework not mentioned in the documentation should generally be considered private API, and may be subject to change.\n\n\nUpgrading\n\n\nTo upgrade Django REST framework to the latest version, use pip:\n\n\npip install -U djangorestframework\n\n\n\nYou can determine your currently installed version using \npip freeze\n:\n\n\npip freeze | grep djangorestframework\n\n\n\n\n\n3.2.x series\n\n\n3.2.3\n\n\nDate\n: \n24th August 2015\n.\n\n\n\n\nAdded \nhtml_cutoff\n and \nhtml_cutoff_text\n for limiting select dropdowns. (\n#3313\n)\n\n\nAdded regex style to \nSearchFilter\n. (\n#3316\n)\n\n\nResolve issues with setting blank HTML fields. (\n#3318\n) (\n#3321\n)\n\n\nCorrectly display existing 'select multiple' values in browsable API forms. (\n#3290\n)\n\n\nResolve duplicated validation message for \nIPAddressField\n. ([#3249[gh3249]) (\n#3250\n)\n\n\nFix to ensure admin renderer continues to work when pagination is disabled. (\n#3275\n)\n\n\nResolve error with \nLimitOffsetPagination\n when count=0, offset=0. (\n#3303\n)\n\n\n\n\n3.2.2\n\n\nDate\n: \n13th August 2015\n.\n\n\n\n\nAdd \ndisplay_value()\n method for use when displaying relational field select inputs. (\n#3254\n)\n\n\nFix issue with \nBooleanField\n checkboxes incorrectly displaying as checked. (\n#3258\n)\n\n\nEnsure empty checkboxes properly set \nBooleanField\n to \nFalse\n in all cases. (\n#2776\n)\n\n\nAllow \nWSGIRequest.FILES\n property without raising incorrect deprecated error. (\n#3261\n)\n\n\nResolve issue with rendering nested serializers in forms. (\n#3260\n)\n\n\nRaise an error if user accidentally pass a serializer instance to a response, rather than data. (\n#3241\n)\n\n\n\n\n3.2.1\n\n\nDate\n: \n7th August 2015\n.\n\n\n\n\nFix for relational select widgets rendering without any choices. (\n#3237\n)\n\n\nFix for \n1\n, \n0\n rendering as \ntrue\n, \nfalse\n in the admin interface. \n#3227\n)\n\n\nFix for ListFields with single value in HTML form input. (\n#3238\n)\n\n\nAllow \nrequest.FILES\n for compat with Django's \nHTTPRequest\n class. (\n#3239\n)\n\n\n\n\n3.2.0\n\n\nDate\n: \n6th August 2015\n.\n\n\n\n\nAdd \nAdminRenderer\n. (\n#2926\n)\n\n\nAdd \nFilePathField\n. (\n#1854\n)\n\n\nAdd \nallow_empty\n to \nListField\n. (\n#2250\n)\n\n\nSupport django-guardian 1.3. (\n#3165\n)\n\n\nSupport grouped choices. (\n#3225\n)\n\n\nSupport error forms in browsable API. (\n#3024\n)\n\n\nAllow permission classes to customize the error message. (\n#2539\n)\n\n\nSupport \nsource=\nmethod\n on hyperlinked fields. (\n#2690\n)\n\n\nListField(allow_null=True)\n now allows null as the list value, not null items in the list. (\n#2766\n)\n\n\nManyToMany()\n maps to \nallow_empty=False\n, \nManyToMany(blank=True)\n maps to \nallow_empty=True\n. (\n#2804\n)\n\n\nSupport custom serialization styles for primary key fields. (\n#2789\n)\n\n\nOPTIONS\n requests support nested representations. (\n#2915\n)\n\n\nSet \nview.action == \"metadata\"\n for viewsets with \nOPTIONS\n requests. (\n#3115\n)\n\n\nSupport \nallow_blank\n on \nUUIDField\n. ([#3130][gh#3130])\n\n\nDo not display view docstrings with 401 or 403 response codes. (\n#3216\n)\n\n\nResolve Django 1.8 deprecation warnings. (\n#2886\n)\n\n\nFix for \nDecimalField\n validation. (\n#3139\n)\n\n\nFix behavior of \nallow_blank=False\n when used with \ntrim_whitespace=True\n. (\n#2712\n)\n\n\nFix issue with some field combinations incorrectly mapping to an invalid \nallow_blank\n argument. (\n#3011\n)\n\n\nFix for output representations with prefetches and modified querysets. (\n#2704\n, \n#2727\n)\n\n\nFix assertion error when CursorPagination is provided with certains invalid query parameters. (#2920)\ngh2920\n.\n\n\nFix \nUnicodeDecodeError\n when invalid characters included in header with \nTokenAuthentication\n. (\n#2928\n)\n\n\nFix transaction rollbacks with \n@non_atomic_requests\n decorator. (\n#3016\n)\n\n\nFix duplicate results issue with Oracle databases using \nSearchFilter\n. (\n#2935\n)\n\n\nFix checkbox alignment and rendering in browsable API forms. (\n#2783\n)\n\n\nFix for unsaved file objects which should use \n\"url\": null\n in the representation. (\n#2759\n)\n\n\nFix field value rendering in browsable API. (\n#2416\n)\n\n\nFix \nHStoreField\n to include \nallow_blank=True\n in \nDictField\n mapping. (\n#2659\n)\n\n\nNumerous other cleanups, improvements to error messaging, private API \n minor fixes.\n\n\n\n\n\n\n3.1.x series\n\n\n3.1.3\n\n\nDate\n: \n4th June 2015\n.\n\n\n\n\nAdd \nDurationField\n. (\n#2481\n, \n#2989\n)\n\n\nAdd \nformat\n argument to \nUUIDField\n. (\n#2788\n, \n#3000\n)\n\n\nMultipleChoiceField\n empties incorrectly on a partial update using multipart/form-data (\n#2993\n, \n#2894\n)\n\n\nFix a bug in options related to read-only \nRelatedField\n. (\n#2981\n, \n#2811\n)\n\n\nFix nested serializers with \nunique_together\n relations. (\n#2975\n)\n\n\nAllow unexpected values for \nChoiceField\n/\nMultipleChoiceField\n representations. (\n#2839\n, \n#2940\n)\n\n\nRollback the transaction on error if \nATOMIC_REQUESTS\n is set. (\n#2887\n, \n#2034\n)\n\n\nSet the action on a view when override_method regardless of its None-ness. (\n#2933\n)\n\n\nDecimalField\n accepts \n2E+2\n as 200 and validates decimal place correctly. (\n#2948\n, \n#2947\n)\n\n\nSupport basic authentication with custom \nUserModel\n that change \nusername\n. (\n#2952\n)\n\n\nIPAddressField\n improvements. (\n#2747\n, \n#2618\n, \n#3008\n)\n\n\nImprove \nDecimalField\n for easier subclassing. (\n#2695\n)\n\n\n\n\n3.1.2\n\n\nDate\n: \n13rd May 2015\n.\n\n\n\n\nDateField.to_representation\n can handle str and empty values. (\n#2656\n, \n#2687\n, \n#2869\n)\n\n\nUse default reason phrases from HTTP standard. (\n#2764\n, \n#2763\n)\n\n\nRaise error when \nModelSerializer\n used with abstract model. (\n#2757\n, \n#2630\n)\n\n\nHandle reversal of non-API view_name in \nHyperLinkedRelatedField\n (\n#2724\n, \n#2711\n)\n\n\nDont require pk strictly for related fields. (\n#2745\n, \n#2754\n)\n\n\nMetadata detects null boolean field type. (\n#2762\n)\n\n\nProper handling of depth in nested serializers. (\n#2798\n)\n\n\nDisplay viewset without paginator. (\n#2807\n)\n\n\nDon't check for deprecated \n.model\n attribute in permissions (\n#2818\n)\n\n\nRestrict integer field to integers and strings. (\n#2835\n, \n#2836\n)\n\n\nImprove \nIntegerField\n to use compiled decimal regex. (\n#2853\n)\n\n\nPrevent empty \nqueryset\n to raise AssertionError. (\n#2862\n)\n\n\nDjangoModelPermissions\n rely on \nget_queryset\n. (\n#2863\n)\n\n\nCheck \nAcceptHeaderVersioning\n with content negotiation in place. (\n#2868\n)\n\n\nAllow \nDjangoObjectPermissions\n to use views that define \nget_queryset\n. (\n#2905\n)\n\n\n\n\n3.1.1\n\n\nDate\n: \n23rd March 2015\n.\n\n\n\n\nSecurity fix\n: Escape tab switching cookie name in browsable API.\n\n\nDisplay input forms in browsable API if \nserializer_class\n is used, even when \nget_serializer\n method does not exist on the view. (\n#2743\n)\n\n\nUse a password input for the AuthTokenSerializer. (\n#2741\n)\n\n\nFix missing anchor closing tag after next button. (\n#2691\n)\n\n\nFix \nlookup_url_kwarg\n handling in viewsets. (\n#2685\n, \n#2591\n)\n\n\nFix problem with importing \nrest_framework.views\n in \napps.py\n (\n#2678\n)\n\n\nLimitOffsetPagination raises \nTypeError\n if PAGE_SIZE not set (\n#2667\n, \n#2700\n)\n\n\nGerman translation for \nmin_value\n field error message references \nmax_value\n. (\n#2645\n)\n\n\nRemove \nMergeDict\n. (\n#2640\n)\n\n\nSupport serializing unsaved models with related fields. (\n#2637\n, \n#2641\n)\n\n\nAllow blank/null on radio.html choices. (\n#2631\n)\n\n\n\n\n3.1.0\n\n\nDate\n: \n5th March 2015\n.\n\n\nFor full details see the \n3.1 release announcement\n.\n\n\n\n\n3.0.x series\n\n\n3.0.5\n\n\nDate\n: \n10th February 2015\n.\n\n\n\n\nFix a bug where \n_closable_objects\n breaks pickling. (\n#1850\n, \n#2492\n)\n\n\nAllow non-standard \nUser\n models with \nThrottling\n. (\n#2524\n)\n\n\nSupport custom \nUser.db_table\n in TokenAuthentication migration. (\n#2479\n)\n\n\nFix misleading \nAttributeError\n tracebacks on \nRequest\n objects. (\n#2530\n, \n#2108\n)\n\n\nManyRelatedField.get_value\n clearing field on partial update. (\n#2475\n)\n\n\nRemoved '.model' shortcut from code. (\n#2486\n)\n\n\nFix \ndetail_route\n and \nlist_route\n mutable argument. (\n#2518\n)\n\n\nPrefetching the user object when getting the token in \nTokenAuthentication\n. (\n#2519\n)\n\n\n\n\n3.0.4\n\n\nDate\n: \n28th January 2015\n.\n\n\n\n\nDjango 1.8a1 support. (\n#2425\n, \n#2446\n, \n#2441\n)\n\n\nAdd \nDictField\n and support Django 1.8 \nHStoreField\n. (\n#2451\n, \n#2106\n)\n\n\nAdd \nUUIDField\n and support Django 1.8 \nUUIDField\n. (\n#2448\n, \n#2433\n, \n#2432\n)\n\n\nBaseRenderer.render\n now raises \nNotImplementedError\n. (\n#2434\n)\n\n\nFix timedelta JSON serialization on Python 2.6. (\n#2430\n)\n\n\nResultDict\n and \nResultList\n now appear as standard dict/list. (\n#2421\n)\n\n\nFix visible \nHiddenField\n in the HTML form of the web browsable API page. (\n#2410\n)\n\n\nUse \nOrderedDict\n for \nRelatedField.choices\n. (\n#2408\n)\n\n\nFix ident format when using \nHTTP_X_FORWARDED_FOR\n. (\n#2401\n)\n\n\nFix invalid key with memcached while using throttling. (\n#2400\n)\n\n\nFix \nFileUploadParser\n with version 3.x. (\n#2399\n)\n\n\nFix the serializer inheritance. (\n#2388\n)\n\n\nFix caching issues with \nReturnDict\n. (\n#2360\n)\n\n\n\n\n3.0.3\n\n\nDate\n: \n8th January 2015\n.\n\n\n\n\nFix \nMinValueValidator\n on \nmodels.DateField\n. (\n#2369\n)\n\n\nFix serializer missing context when pagination is used. (\n#2355\n)\n\n\nNamespaced router URLs are now supported by the \nDefaultRouter\n. (\n#2351\n)\n\n\nrequired=False\n allows omission of value for output. (\n#2342\n)\n\n\nUse textarea input for \nmodels.TextField\n. (\n#2340\n)\n\n\nUse custom \nListSerializer\n for pagination if required. (\n#2331\n, \n#2327\n)\n\n\nBetter behavior with null and '' for blank HTML fields. (\n#2330\n)\n\n\nEnsure fields in \nexclude\n are model fields. (\n#2319\n)\n\n\nFix \nIntegerField\n and \nmax_length\n argument incompatibility. (\n#2317\n)\n\n\nFix the YAML encoder for 3.0 serializers. (\n#2315\n, \n#2283\n)\n\n\nFix the behavior of empty HTML fields. (\n#2311\n, \n#1101\n)\n\n\nFix Metaclass attribute depth ignoring fields attribute. (\n#2287\n)\n\n\nFix \nformat_suffix_patterns\n to work with Django's \ni18n_patterns\n. (\n#2278\n)\n\n\nAbility to customize router URLs for custom actions, using \nurl_path\n. (\n#2010\n)\n\n\nDon't install Django REST Framework as egg. (\n#2386\n)\n\n\n\n\n3.0.2\n\n\nDate\n: \n17th December 2014\n.\n\n\n\n\nEnsure \nrequest.user\n is made available to response middleware. (\n#2155\n)\n\n\nClient.logout()\n also cancels any existing \nforce_authenticate\n. (\n#2218\n, \n#2259\n)\n\n\nExtra assertions and better checks to preventing incorrect serializer API use. (\n#2228\n, \n#2234\n, \n#2262\n, \n#2263\n, \n#2266\n, \n#2267\n, \n#2289\n, \n#2291\n)\n\n\nFixed \nmin_length\n message for \nCharField\n. (\n#2255\n)\n\n\nFix \nUnicodeDecodeError\n, which can occur on serializer \nrepr\n.  (\n#2270\n, \n#2279\n)\n\n\nFix empty HTML values when a default is provided. (\n#2280\n, \n#2294\n)\n\n\nFix \nSlugRelatedField\n raising \nUnicodeEncodeError\n when used as a multiple choice input. (\n#2290\n)\n\n\n\n\n3.0.1\n\n\nDate\n: \n11th December 2014\n.\n\n\n\n\nMore helpful error message when the default Serializer \ncreate()\n fails. (\n#2013\n)\n\n\nRaise error when attempting to save serializer if data is not valid. (\n#2098\n)\n\n\nFix \nFileUploadParser\n breaks with empty file names and multiple upload handlers. (\n#2109\n)\n\n\nImprove \nBindingDict\n to support standard dict-functions. (\n#2135\n, \n#2163\n)\n\n\nAdd \nvalidate()\n to \nListSerializer\n. (\n#2168\n, \n#2225\n, \n#2232\n)\n\n\nFix JSONP renderer failing to escape some characters. (\n#2169\n, \n#2195\n)\n\n\nAdd missing default style for \nFileField\n. (\n#2172\n)\n\n\nActions are required when calling \nViewSet.as_view()\n. (\n#2175\n)\n\n\nAdd \nallow_blank\n to \nChoiceField\n. (\n#2184\n, \n#2239\n)\n\n\nCosmetic fixes in the HTML renderer. (\n#2187\n)\n\n\nRaise error if \nfields\n on serializer is not a list of strings. (\n#2193\n, \n#2213\n)\n\n\nImprove checks for nested creates and updates. (\n#2194\n, \n#2196\n)\n\n\nvalidated_attrs\n argument renamed to \nvalidated_data\n in \nSerializer\n \ncreate()\n/\nupdate()\n. (\n#2197\n)\n\n\nRemove deprecated code to reflect the dropped Django versions. (\n#2200\n)\n\n\nBetter serializer errors for nested writes. (\n#2202\n, \n#2215\n)\n\n\nFix pagination and custom permissions incompatibility. (\n#2205\n)\n\n\nRaise error if \nfields\n on serializer is not a list of strings. (\n#2213\n)\n\n\nAdd missing translation markers for relational fields. (\n#2231\n)\n\n\nImprove field lookup behavior for dicts/mappings. (\n#2244\n, \n#2243\n)\n\n\nOptimized hyperlinked PK. (\n#2242\n)\n\n\n\n\n3.0.0\n\n\nDate\n: 1st December 2014\n\n\nFor full details see the \n3.0 release announcement\n.\n\n\n\n\nFor older release notes, \nplease see the version 2.x documentation\n.", 
             "title": "Release Notes"
         }, 
         {
@@ -3022,7 +3027,7 @@
         }, 
         {
             "location": "/topics/release-notes/#32x-series", 
-            "text": "3.2.2  Date :  13th August 2015 .   Add  display_value()  method for use when displaying relational field select inputs. ( #3254 )  Fix issue with  BooleanField  checkboxes incorrectly displaying as checked. ( #3258 )  Ensure empty checkboxes properly set  BooleanField  to  False  in all cases. ( #2776 )  Allow  WSGIRequest.FILES  property without raising incorrect deprecated error. ( #3261 )  Resolve issue with rendering nested serializers in forms. ( #3260 )  Raise an error if user accidentally pass a serializer instance to a response, rather than data. ( #3241 )   3.2.1  Date :  7th August 2015 .   Fix for relational select widgets rendering without any choices. ( #3237 )  Fix for  1 ,  0  rendering as  true ,  false  in the admin interface.  #3227 )  Fix for ListFields with single value in HTML form input. ( #3238 )  Allow  request.FILES  for compat with Django's  HTTPRequest  class. ( #3239 )   3.2.0  Date :  6th August 2015 .   Add  AdminRenderer . ( #2926 )  Add  FilePathField . ( #1854 )  Add  allow_empty  to  ListField . ( #2250 )  Support django-guardian 1.3. ( #3165 )  Support grouped choices. ( #3225 )  Support error forms in browsable API. ( #3024 )  Allow permission classes to customize the error message. ( #2539 )  Support  source= method  on hyperlinked fields. ( #2690 )  ListField(allow_null=True)  now allows null as the list value, not null items in the list. ( #2766 )  ManyToMany()  maps to  allow_empty=False ,  ManyToMany(blank=True)  maps to  allow_empty=True . ( #2804 )  Support custom serialization styles for primary key fields. ( #2789 )  OPTIONS  requests support nested representations. ( #2915 )  Set  view.action == \"metadata\"  for viewsets with  OPTIONS  requests. ( #3115 )  Support  allow_blank  on  UUIDField . ([#3130][gh#3130])  Do not display view docstrings with 401 or 403 response codes. ( #3216 )  Resolve Django 1.8 deprecation warnings. ( #2886 )  Fix for  DecimalField  validation. ( #3139 )  Fix behavior of  allow_blank=False  when used with  trim_whitespace=True . ( #2712 )  Fix issue with some field combinations incorrectly mapping to an invalid  allow_blank  argument. ( #3011 )  Fix for output representations with prefetches and modified querysets. ( #2704 ,  #2727 )  Fix assertion error when CursorPagination is provided with certains invalid query parameters. (#2920) gh2920 .  Fix  UnicodeDecodeError  when invalid characters included in header with  TokenAuthentication . ( #2928 )  Fix transaction rollbacks with  @non_atomic_requests  decorator. ( #3016 )  Fix duplicate results issue with Oracle databases using  SearchFilter . ( #2935 )  Fix checkbox alignment and rendering in browsable API forms. ( #2783 )  Fix for unsaved file objects which should use  \"url\": null  in the representation. ( #2759 )  Fix field value rendering in browsable API. ( #2416 )  Fix  HStoreField  to include  allow_blank=True  in  DictField  mapping. ( #2659 )  Numerous other cleanups, improvements to error messaging, private API   minor fixes.", 
+            "text": "3.2.3  Date :  24th August 2015 .   Added  html_cutoff  and  html_cutoff_text  for limiting select dropdowns. ( #3313 )  Added regex style to  SearchFilter . ( #3316 )  Resolve issues with setting blank HTML fields. ( #3318 ) ( #3321 )  Correctly display existing 'select multiple' values in browsable API forms. ( #3290 )  Resolve duplicated validation message for  IPAddressField . ([#3249[gh3249]) ( #3250 )  Fix to ensure admin renderer continues to work when pagination is disabled. ( #3275 )  Resolve error with  LimitOffsetPagination  when count=0, offset=0. ( #3303 )   3.2.2  Date :  13th August 2015 .   Add  display_value()  method for use when displaying relational field select inputs. ( #3254 )  Fix issue with  BooleanField  checkboxes incorrectly displaying as checked. ( #3258 )  Ensure empty checkboxes properly set  BooleanField  to  False  in all cases. ( #2776 )  Allow  WSGIRequest.FILES  property without raising incorrect deprecated error. ( #3261 )  Resolve issue with rendering nested serializers in forms. ( #3260 )  Raise an error if user accidentally pass a serializer instance to a response, rather than data. ( #3241 )   3.2.1  Date :  7th August 2015 .   Fix for relational select widgets rendering without any choices. ( #3237 )  Fix for  1 ,  0  rendering as  true ,  false  in the admin interface.  #3227 )  Fix for ListFields with single value in HTML form input. ( #3238 )  Allow  request.FILES  for compat with Django's  HTTPRequest  class. ( #3239 )   3.2.0  Date :  6th August 2015 .   Add  AdminRenderer . ( #2926 )  Add  FilePathField . ( #1854 )  Add  allow_empty  to  ListField . ( #2250 )  Support django-guardian 1.3. ( #3165 )  Support grouped choices. ( #3225 )  Support error forms in browsable API. ( #3024 )  Allow permission classes to customize the error message. ( #2539 )  Support  source= method  on hyperlinked fields. ( #2690 )  ListField(allow_null=True)  now allows null as the list value, not null items in the list. ( #2766 )  ManyToMany()  maps to  allow_empty=False ,  ManyToMany(blank=True)  maps to  allow_empty=True . ( #2804 )  Support custom serialization styles for primary key fields. ( #2789 )  OPTIONS  requests support nested representations. ( #2915 )  Set  view.action == \"metadata\"  for viewsets with  OPTIONS  requests. ( #3115 )  Support  allow_blank  on  UUIDField . ([#3130][gh#3130])  Do not display view docstrings with 401 or 403 response codes. ( #3216 )  Resolve Django 1.8 deprecation warnings. ( #2886 )  Fix for  DecimalField  validation. ( #3139 )  Fix behavior of  allow_blank=False  when used with  trim_whitespace=True . ( #2712 )  Fix issue with some field combinations incorrectly mapping to an invalid  allow_blank  argument. ( #3011 )  Fix for output representations with prefetches and modified querysets. ( #2704 ,  #2727 )  Fix assertion error when CursorPagination is provided with certains invalid query parameters. (#2920) gh2920 .  Fix  UnicodeDecodeError  when invalid characters included in header with  TokenAuthentication . ( #2928 )  Fix transaction rollbacks with  @non_atomic_requests  decorator. ( #3016 )  Fix duplicate results issue with Oracle databases using  SearchFilter . ( #2935 )  Fix checkbox alignment and rendering in browsable API forms. ( #2783 )  Fix for unsaved file objects which should use  \"url\": null  in the representation. ( #2759 )  Fix field value rendering in browsable API. ( #2416 )  Fix  HStoreField  to include  allow_blank=True  in  DictField  mapping. ( #2659 )  Numerous other cleanups, improvements to error messaging, private API   minor fixes.", 
             "title": "3.2.x series"
         }, 
         {
diff --git a/sitemap.xml b/sitemap.xml
index f1e568f61..626dc1786 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -4,7 +4,7 @@
     
     
      http://www.django-rest-framework.org//
-     2015-08-13
+     2015-08-24
      daily
     
     
@@ -13,43 +13,43 @@
         
     
      http://www.django-rest-framework.org//tutorial/quickstart/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//tutorial/1-serialization/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//tutorial/2-requests-and-responses/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//tutorial/3-class-based-views/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//tutorial/4-authentication-and-permissions/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//tutorial/5-relationships-and-hyperlinked-apis/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//tutorial/6-viewsets-and-routers/
-     2015-08-13
+     2015-08-24
      daily
     
         
@@ -59,157 +59,157 @@
         
     
      http://www.django-rest-framework.org//api-guide/requests/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/responses/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/views/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/generic-views/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/viewsets/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/routers/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/parsers/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/renderers/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/serializers/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/fields/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/relations/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/validators/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/authentication/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/permissions/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/throttling/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/filtering/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/pagination/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/versioning/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/content-negotiation/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/metadata/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/format-suffixes/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/reverse/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/exceptions/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/status-codes/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/testing/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//api-guide/settings/
-     2015-08-13
+     2015-08-24
      daily
     
         
@@ -219,85 +219,85 @@
         
     
      http://www.django-rest-framework.org//topics/documenting-your-api/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//topics/internationalization/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//topics/ajax-csrf-cors/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//topics/browser-enhancements/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//topics/browsable-api/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//topics/rest-hypermedia-hateoas/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//topics/third-party-resources/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//topics/contributing/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//topics/project-management/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//topics/3.0-announcement/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//topics/3.1-announcement/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//topics/3.2-announcement/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//topics/kickstarter-announcement/
-     2015-08-13
+     2015-08-24
      daily
     
         
     
      http://www.django-rest-framework.org//topics/release-notes/
-     2015-08-13
+     2015-08-24
      daily
     
         
diff --git a/topics/funding/index.html b/topics/funding/index.html
new file mode 100644
index 000000000..4b0160082
--- /dev/null
+++ b/topics/funding/index.html
@@ -0,0 +1,709 @@
+
+
+
+
+  
+  
+  Funding - Django REST framework
+  
+  
+  
+  
+  
+
+  
+  
+  
+  
+  
+
+  
+  
+
+  
+
+  
+
+
+
+  
    
+        
    
+      
    
+        
    
+          GitHub
+          
+          
+           Search
+          
+            
+            
+            
+          
+          Django REST framework
+          
    
+            
+            
+            
+            
+          
    
+          
+
+        
    
+      
    
+    
    
+
+    
    
+      
    
+        
+        
+
+        
    
+          
    
+            
    
+              
+
+            
    
+          
    
+
+          
    
+            
+              
+
+              
+
+
+
+
    Funding
    
+
    If you use REST framework commercially we strongly encourage you to invest in its continued development by signing up for a paid plan.
    
+
    We believe that collaboratively funded software can offer outstanding returns on investment, by allowing users and clients to collectively share the cost of development.
    
+
    Signing up for a paid plan will:
    
+
      
+
    • Directly contribute to faster releases, more features and higher quality software.
      • 
+
    • Allow more time to be invested in documentation, issue triage and community support.
      • 
+
    • Safeguard the future development of REST framework.
      • 
+
    
+
    REST framework will always be open source and permissively licensed, but we firmly believe it is in the commercial best-interest for users of the project to fund its ongoing development.
    
+
    
+
    Making the business case
    
+
    Our successful Kickstarter campaign demonstrates the cost-reward ratio of shared development funding.
    
+
    With typical corporate fundings of just £100-£1000 per organization we successfully delivered:
    
+
      
+
    • The comprehensive 3.0 serializer redesign.
      • 
+
    • Pagination API including new offset/limit and cursor pagination implementations, plus  on-page controls.
      • 
+
    • The versioning API, including URL based and header based versioning schemes.
      • 
+
    • Customizable exception handling.
      • 
+
    • The metadata APIs for handling OPTIONS requests.
      • 
+
    • Templated HTML form support, including HTML forms with nested list and objects.
      • 
+
    • Internationalization support for API responses, currently with 27 languages.
      • 
+
    • Improvements to the browsable API.
      • 
+
    • The admin interface.
      • 
+
    • Support for Django's PostgreSQL HStoreField, ArrayField and JSONField.
      • 
+
    • Ongoing triage and community support, closing over 1600 tickets.
      • 
+
    
+
    This incredible level of return on investment is only possible through collaboratively funded models, which is why we believe that supporting our paid plans is in everyone's best interest.
    
+
    
+
    Individual plan
    
+
    This subscription is recommended for freelancers and other individuals with an interest in seeing REST framework continue to improve.
    
+
    If you are using REST framework as an full-time employee, consider recommending that your company takes out a corporate plan.
    
+
    
+                
    
+                    
    
+                        
    
+                            $
+                            15
+                            /month
+                        
    
+                        
    Individual
    
+                        
    
+                            
    
+                                Support ongoing development
+                            
    
+                            
    
+                                Credited on the site
+                            
    
+                        
    
+                        
+                    
    
+                
    
+            
    
+
+
    
+
+
    Billing is monthly and you can cancel at any time.
    
+
    
+
    Corporate plans
    
+
    These subscriptions are recommended for companies and organizations using REST framework either publicly or privately.
    
+
    In exchange for funding you'll also receive advertising space on our site, allowing you to promote your company or product to many tens of thousands of developers worldwide.
    
+
    Our professional and premium plans also include priority support. At any time your engineers can escalate an issue or discussion group thread, and we'll ensure it gets a guaranteed response within the next working day.
    
+
    
+                
    
+                    
    
+                        
    
+                            $
+                            50
+                            /month
+                        
    
+                        
    Basic
    
+                        
    
+                            
    
+                                Support ongoing development
+                            
    
+                            
    
+                                Funding page ad placement
+                            
    
+                        
    
+                        
+                    
    
+                
    
+                
    
+                    
    
+                        
    
+                            $
+                            250
+                            /month
+                        
    
+                        
    Professional
    
+                        
    
+                            
    
+                                Add a half day per month development time to the project
+                            
    
+                            
    
+                                Homepage ad placement
+                            
    
+                            
    
+                                Priority support for your engineers
+                            
    
+                        
    
+                        
+                    
    
+                
    
+                
    
+                    
    
+                        
    
+                            $
+                            500
+                            /month
+                        
    
+                        
    Premium
    
+                        
    
+                            
    
+                                Add one full day per month development time to the project
+                            
    
+                            
    
+                                Full site ad placement
+                            
    
+                            
    
+                                Priority support for your engineers
+                            
    
+                        
    
+                        
+                    
    
+                
    
+            
    
+
+
    
+
+
    Billing is monthly and you can cancel at any time.
    
+
    Once you've signed up we'll contact you via email and arrange your ad placements on the site.
    
+
    For further enquires please contact tom@tomchristie.com.
    
+
    
+
    Roadmap
    
+
    The roadmap below is a broad indication of just some of the ongoing and future work we believe is important to REST framework.
    
+
      
+
    • Support for alternative backends such as SQLAlchemy.
      • 
+
    • HTTP Caching API & support for conditional database lookups.
      • 
+
    • Performance improvements.
      • 
+
    • Improved project documentation, including versioned & internationalized docs.
      • 
+
    • Hypermedia support and client libraries.
      • 
+
    • API metric tools.
      • 
+
    • Debug & logging tools.
      • 
+
    • In depth documentation on advanced usage and best practices.
      • 
+
    • Third party GraphQL support.
      • 
+
    • Documentation & support for integration with realtime systems.
      • 
+
    • Improved third party package visibility.
      • 
+
    • Increasing our "bus factor" through documented organizational process & safeguards.
      • 
+
    • Continuing triage & community support.
      • 
+
    
+
    By taking out a paid plan you'll be directly contributing towards making these features happen.
    
+            
+
+          
     
+        
     
+      
     
+    
     
+    
    
+  
     
+
+  
    
+    
    Documentation built with MkDocs.
+    
    
+  
    
+
+  
+  
+  
+  
+  
+  
+  
+  
+
+  
+
+
+
\ No newline at end of file
diff --git a/topics/release-notes/index.html b/topics/release-notes/index.html
index 5546f5b7a..c20c62d8d 100644
--- a/topics/release-notes/index.html
+++ b/topics/release-notes/index.html
@@ -406,8 +406,19 @@
 
    
 
    
 
    3.2.x series
    
+
    3.2.3
    
+
    Date: 24th August 2015.
    
+
      
+
    • Added html_cutoff and html_cutoff_text for limiting select dropdowns. (#3313)
      • 
+
    • Added regex style to SearchFilter. (#3316)
      • 
+
    • Resolve issues with setting blank HTML fields. (#3318) (#3321)
      • 
+
    • Correctly display existing 'select multiple' values in browsable API forms. (#3290)
      • 
+
    • Resolve duplicated validation message for IPAddressField. ([#3249[gh3249]) (#3250)
      • 
+
    • Fix to ensure admin renderer continues to work when pagination is disabled. (#3275)
      • 
+
    • Resolve error with LimitOffsetPagination when count=0, offset=0. (#3303)
      • 
+
    
 
    3.2.2
    
-
    Date: 13th August 2015.
    
+
    Date: 13th August 2015.
    
 
      
 
    • Add display_value() method for use when displaying relational field select inputs. (#3254)
      • 
 
    • Fix issue with BooleanField checkboxes incorrectly displaying as checked. (#3258)
      • 
@@ -616,6 +627,8 @@
 
 
 
+
+