diff --git a/mkdocs/search_index.json b/mkdocs/search_index.json
index 71faf07bb..d3055e001 100644
--- a/mkdocs/search_index.json
+++ b/mkdocs/search_index.json
@@ -5037,7 +5037,7 @@
},
{
"location": "/topics/3.5-announcement/",
- "text": ".promo li a {\n float: left;\n width: 130px;\n height: 20px;\n text-align: center;\n margin: 10px 30px;\n padding: 150px 0 0 0;\n background-position: 0 50%;\n background-size: 130px auto;\n background-repeat: no-repeat;\n font-size: 120%;\n color: black;\n}\n.promo li {\n list-style: none;\n}\n\n\n\n\nDjango REST framework 3.5\n\n\nThe 3.5 release is the second in a planned series that is addressing schema\ngeneration, hypermedia support, API client libraries, and finally realtime support.\n\n\n\n\nFunding\n\n\nThe 3.5 release would not have been possible without our \ncollaborative funding model\n.\nIf you use REST framework commercially and would like to see this work continue,\nwe strongly encourage you to invest in its continued development by\n\nsigning up for a paid\nplan\n.\n\n\n\n \nRover.com\n\n \nSentry\n\n \nStream\n\n \nMachinalis\n\n\n\n\n\n\n\n\nMany thanks to all our \nsponsors\n, and in particular to our premium backers, \nRover\n, \nSentry\n, \nStream\n, and \nMachinalis\n.\n\n\n\n\nImproved schema generation\n\n\nDocstrings on views are now pulled through into schema definitions, allowing\nyou to \nuse the schema definition to document your\nAPI\n.\n\n\nThere is now also a shortcut function, \nget_schema_view()\n, which makes it easier to\n\nadding schema views\n to your API.\n\n\nFor example, to include a swagger schema to your API, you would do the following:\n\n\n\n\n\n\nRun \npip install django-rest-swagger\n.\n\n\n\n\n\n\nAdd \n'rest_framework_swagger'\n to your \nINSTALLED_APPS\n setting.\n\n\n\n\n\n\nInclude the schema view in your URL conf:\n\n\n\n\n\n\nfrom rest_framework.schemas import get_schema_view\nfrom rest_framework_swagger.renderers import OpenAPIRenderer, SwaggerUIRenderer\n\nschema_view = get_schema_view(\n title='Example API',\n renderer_classes=[OpenAPIRenderer, SwaggerUIRenderer]\n)\n\nurlpatterns = [\n url(r'^swagger/$', schema_view),\n ...\n]\n\n\n\n\nThere have been a large number of fixes to the schema generation. These should\nresolve issues for anyone using the latest version of the \ndjango-rest-swagger\n\npackage.\n\n\nSome of these changes do affect the resulting schema structure,\nso if you're already using schema generation you should make sure to review\n\nthe deprecation notes\n, particularly if you're currently using\na dynamic client library to interact with your API.\n\n\nFinally, we're also now exposing the schema generation as a\n\npublicly documented API\n, allowing you to more easily\noverride the behaviour.\n\n\nRequests test client\n\n\nYou can now test your project using the \nrequests\n library.\n\n\nThis exposes exactly the same interface as if you were using a standard\nrequests session instance.\n\n\nclient = RequestsClient()\nresponse = client.get('http://testserver/users/')\nassert response.status_code == 200\n\n\n\nRather than sending any HTTP requests to the network, this interface will\ncoerce all outgoing requests into WSGI, and call into your application directly.\n\n\nCore API client\n\n\nYou can also now test your project by interacting with it using the \ncoreapi\n\nclient library.\n\n\n# Fetch the API schema\nclient = CoreAPIClient()\nschema = client.get('http://testserver/schema/')\n\n# Create a new organisation\nparams = {'name': 'MegaCorp', 'status': 'active'}\nclient.action(schema, ['organisations', 'create'], params)\n\n# Ensure that the organisation exists in the listing\ndata = client.action(schema, ['organisations', 'list'])\nassert(len(data) == 1)\nassert(data == [{'name': 'MegaCorp', 'status': 'active'}])\n\n\n\nAgain, this will call directly into the application using the WSGI interface,\nrather than making actual network calls.\n\n\nThis is a good option if you are planning for clients to mainly interact with\nyour API using the \ncoreapi\n client library, or some other auto-generated client.\n\n\nLive tests\n\n\nOne interesting aspect of both the \nrequests\n client and the \ncoreapi\n client\nis that they allow you to write tests in such a way that they can also be made\nto run against a live service.\n\n\nBy switching the WSGI based client instances to actual instances of \nrequests.Session\n\nor \ncoreapi.Client\n you can have the test cases make actual network calls.\n\n\nBeing able to write test cases that can exercise your staging or production\nenvironment is a powerful tool. However in order to do this, you'll need to pay\nclose attention to how you handle setup and teardown to ensure a strict isolation\nof test data from other live or staging data.\n\n\nRAML support\n\n\nWe now have preliminary support for \nRAML documentation generation\n.\n\n\n\n\nFurther work on the encoding and documentation generation is planned, in order to\nmake features such as the 'Try it now' support available at a later date.\n\n\nThis work also now means that you can use the Core API client libraries to interact\nwith APIs that expose a RAML specification. The \nRAML codec\n gives some examples of\ninteracting with the Spotify API in this way.\n\n\nValidation codes\n\n\nExceptions raised by REST framework now include short code identifiers.\nWhen used together with our customizable error handling, this now allows you to\nmodify the style of API error messages.\n\n\nAs an example, this allows for the following style of error responses:\n\n\n{\n \"message\": \"You do not have permission to perform this action.\",\n \"code\": \"permission_denied\"\n}\n\n\n\nThis is particularly useful with validation errors, which use appropriate\ncodes to identify differing kinds of failure...\n\n\n{\n \"name\": {\"message\": \"This field is required.\", \"code\": \"required\"},\n \"age\": {\"message\": \"A valid integer is required.\", \"code\": \"invalid\"}\n}\n\n\n\nClient upload \n download support\n\n\nThe Python \ncoreapi\n client library and the Core API command line tool both\nnow fully support file \nuploads\n and \ndownloads\n.\n\n\n\n\nDeprecations\n\n\nGenerating schemas from Router\n\n\nThe router arguments for generating a schema view, such as \nschema_title\n,\nare now pending deprecation.\n\n\nInstead of using \nDefaultRouter(schema_title='Example API')\n, you should use\nthe \nget_schema_view()\n function, and include the view in your URL conf.\n\n\nMake sure to include the view before your router urls. For example:\n\n\nfrom rest_framework.schemas import get_schema_view\nfrom my_project.routers import router\n\nschema_view = get_schema_view(title='Example API')\n\nurlpatterns = [\n url('^$', schema_view),\n url(r'^', include(router.urls)),\n]\n\n\n\nSchema path representations\n\n\nThe \n'pk'\n identifier in schema paths is now mapped onto the actually model field\nname by default. This will typically be \n'id'\n.\n\n\nThis gives a better external representation for schemas, with less implementation\ndetail being exposed. It also reflects the behaviour of using a ModelSerializer\nclass with \nfields = '__all__'\n.\n\n\nYou can revert to the previous behaviour by setting \n'SCHEMA_COERCE_PATH_PK': False\n\nin the REST framework settings.\n\n\nSchema action name representations\n\n\nThe internal \nretrieve()\n and \ndestroy()\n method names are now coerced to an\nexternal representation of \nread\n and \ndelete\n.\n\n\nYou can revert to the previous behaviour by setting \n'SCHEMA_COERCE_METHOD_NAMES': {}\n\nin the REST framework settings.\n\n\nDjangoFilterBackend\n\n\nThe functionality of the built-in \nDjangoFilterBackend\n is now completely\nincluded by the \ndjango-filter\n package.\n\n\nYou should change your imports and REST framework filter settings as follows:\n\n\n\n\nrest_framework.filters.DjangoFilterBackend\n becomes \ndjango_filters.rest_framework.DjangoFilterBackend\n.\n\n\nrest_framework.filters.FilterSet\n becomes \ndjango_filters.rest_framework.FilterSet\n.\n\n\n\n\nThe existing imports will continue to work but are now pending deprecation.\n\n\nCoreJSON media type\n\n\nThe media type for \nCoreJSON\n is now \napplication/json+coreapi\n, rather than\nthe previous \napplication/vnd.json+coreapi\n. This brings it more into line with\nother custom media types, such as those used by Swagger and RAML.\n\n\nThe clients currently accept either media type. The old style-media type will\nbe deprecated at a later date.\n\n\nModelSerializer 'fields' and 'exclude'\n\n\nModelSerializer and HyperlinkedModelSerializer must include either a fields\noption, or an exclude option. The fields = '\nall\n' shortcut may be used to\nexplicitly include all fields.\n\n\nFailing to set either \nfields\n or \nexclude\n raised a pending deprecation warning\nin version 3.3 and raised a deprecation warning in 3.4. Its usage is now mandatory.",
+ "text": ".promo li a {\n float: left;\n width: 130px;\n height: 20px;\n text-align: center;\n margin: 10px 30px;\n padding: 150px 0 0 0;\n background-position: 0 50%;\n background-size: 130px auto;\n background-repeat: no-repeat;\n font-size: 120%;\n color: black;\n}\n.promo li {\n list-style: none;\n}\n\n\n\n\nDjango REST framework 3.5\n\n\nThe 3.5 release is the second in a planned series that is addressing schema\ngeneration, hypermedia support, API client libraries, and finally realtime support.\n\n\n\n\nFunding\n\n\nThe 3.5 release would not have been possible without our \ncollaborative funding model\n.\nIf you use REST framework commercially and would like to see this work continue,\nwe strongly encourage you to invest in its continued development by\n\nsigning up for a paid\nplan\n.\n\n\n\n \nRover.com\n\n \nSentry\n\n \nStream\n\n \nMachinalis\n\n\n\n\n\n\n\n\nMany thanks to all our \nsponsors\n, and in particular to our premium backers, \nRover\n, \nSentry\n, \nStream\n, and \nMachinalis\n.\n\n\n\n\nImproved schema generation\n\n\nDocstrings on views are now pulled through into schema definitions, allowing\nyou to \nuse the schema definition to document your\nAPI\n.\n\n\nThere is now also a shortcut function, \nget_schema_view()\n, which makes it easier to\n\nadding schema views\n to your API.\n\n\nFor example, to include a swagger schema to your API, you would do the following:\n\n\n\n\n\n\nRun \npip install django-rest-swagger\n.\n\n\n\n\n\n\nAdd \n'rest_framework_swagger'\n to your \nINSTALLED_APPS\n setting.\n\n\n\n\n\n\nInclude the schema view in your URL conf:\n\n\n\n\n\n\nfrom rest_framework.schemas import get_schema_view\nfrom rest_framework_swagger.renderers import OpenAPIRenderer, SwaggerUIRenderer\n\nschema_view = get_schema_view(\n title='Example API',\n renderer_classes=[OpenAPIRenderer, SwaggerUIRenderer]\n)\n\nurlpatterns = [\n url(r'^swagger/$', schema_view),\n ...\n]\n\n\n\n\nThere have been a large number of fixes to the schema generation. These should\nresolve issues for anyone using the latest version of the \ndjango-rest-swagger\n\npackage.\n\n\nSome of these changes do affect the resulting schema structure,\nso if you're already using schema generation you should make sure to review\n\nthe deprecation notes\n, particularly if you're currently using\na dynamic client library to interact with your API.\n\n\nFinally, we're also now exposing the schema generation as a\n\npublicly documented API\n, allowing you to more easily\noverride the behaviour.\n\n\nRequests test client\n\n\nYou can now test your project using the \nrequests\n library.\n\n\nThis exposes exactly the same interface as if you were using a standard\nrequests session instance.\n\n\nclient = RequestsClient()\nresponse = client.get('http://testserver/users/')\nassert response.status_code == 200\n\n\n\nRather than sending any HTTP requests to the network, this interface will\ncoerce all outgoing requests into WSGI, and call into your application directly.\n\n\nCore API client\n\n\nYou can also now test your project by interacting with it using the \ncoreapi\n\nclient library.\n\n\n# Fetch the API schema\nclient = CoreAPIClient()\nschema = client.get('http://testserver/schema/')\n\n# Create a new organisation\nparams = {'name': 'MegaCorp', 'status': 'active'}\nclient.action(schema, ['organisations', 'create'], params)\n\n# Ensure that the organisation exists in the listing\ndata = client.action(schema, ['organisations', 'list'])\nassert(len(data) == 1)\nassert(data == [{'name': 'MegaCorp', 'status': 'active'}])\n\n\n\nAgain, this will call directly into the application using the WSGI interface,\nrather than making actual network calls.\n\n\nThis is a good option if you are planning for clients to mainly interact with\nyour API using the \ncoreapi\n client library, or some other auto-generated client.\n\n\nLive tests\n\n\nOne interesting aspect of both the \nrequests\n client and the \ncoreapi\n client\nis that they allow you to write tests in such a way that they can also be made\nto run against a live service.\n\n\nBy switching the WSGI based client instances to actual instances of \nrequests.Session\n\nor \ncoreapi.Client\n you can have the test cases make actual network calls.\n\n\nBeing able to write test cases that can exercise your staging or production\nenvironment is a powerful tool. However in order to do this, you'll need to pay\nclose attention to how you handle setup and teardown to ensure a strict isolation\nof test data from other live or staging data.\n\n\nRAML support\n\n\nWe now have preliminary support for \nRAML documentation generation\n.\n\n\n\n\nFurther work on the encoding and documentation generation is planned, in order to\nmake features such as the 'Try it now' support available at a later date.\n\n\nThis work also now means that you can use the Core API client libraries to interact\nwith APIs that expose a RAML specification. The \nRAML codec\n gives some examples of\ninteracting with the Spotify API in this way.\n\n\nValidation codes\n\n\nExceptions raised by REST framework now include short code identifiers.\nWhen used together with our customizable error handling, this now allows you to\nmodify the style of API error messages.\n\n\nAs an example, this allows for the following style of error responses:\n\n\n{\n \"message\": \"You do not have permission to perform this action.\",\n \"code\": \"permission_denied\"\n}\n\n\n\nThis is particularly useful with validation errors, which use appropriate\ncodes to identify differing kinds of failure...\n\n\n{\n \"name\": {\"message\": \"This field is required.\", \"code\": \"required\"},\n \"age\": {\"message\": \"A valid integer is required.\", \"code\": \"invalid\"}\n}\n\n\n\nClient upload \n download support\n\n\nThe Python \ncoreapi\n client library and the Core API command line tool both\nnow fully support file \nuploads\n and \ndownloads\n.\n\n\n\n\nDeprecations\n\n\nGenerating schemas from Router\n\n\nThe router arguments for generating a schema view, such as \nschema_title\n,\nare now pending deprecation.\n\n\nInstead of using \nDefaultRouter(schema_title='Example API')\n, you should use\nthe \nget_schema_view()\n function, and include the view in your URL conf.\n\n\nMake sure to include the view before your router urls. For example:\n\n\nfrom rest_framework.schemas import get_schema_view\nfrom my_project.routers import router\n\nschema_view = get_schema_view(title='Example API')\n\nurlpatterns = [\n url('^$', schema_view),\n url(r'^', include(router.urls)),\n]\n\n\n\nSchema path representations\n\n\nThe \n'pk'\n identifier in schema paths is now mapped onto the actually model field\nname by default. This will typically be \n'id'\n.\n\n\nThis gives a better external representation for schemas, with less implementation\ndetail being exposed. It also reflects the behaviour of using a ModelSerializer\nclass with \nfields = '__all__'\n.\n\n\nYou can revert to the previous behaviour by setting \n'SCHEMA_COERCE_PATH_PK': False\n\nin the REST framework settings.\n\n\nSchema action name representations\n\n\nThe internal \nretrieve()\n and \ndestroy()\n method names are now coerced to an\nexternal representation of \nread\n and \ndelete\n.\n\n\nYou can revert to the previous behaviour by setting \n'SCHEMA_COERCE_METHOD_NAMES': {}\n\nin the REST framework settings.\n\n\nDjangoFilterBackend\n\n\nThe functionality of the built-in \nDjangoFilterBackend\n is now completely\nincluded by the \ndjango-filter\n package.\n\n\nYou should change your imports and REST framework filter settings as follows:\n\n\n\n\nrest_framework.filters.DjangoFilterBackend\n becomes \ndjango_filters.rest_framework.DjangoFilterBackend\n.\n\n\nrest_framework.filters.FilterSet\n becomes \ndjango_filters.rest_framework.FilterSet\n.\n\n\n\n\nThe existing imports will continue to work but are now pending deprecation.\n\n\nCoreJSON media type\n\n\nThe media type for \nCoreJSON\n is now \napplication/json+coreapi\n, rather than\nthe previous \napplication/vnd.json+coreapi\n. This brings it more into line with\nother custom media types, such as those used by Swagger and RAML.\n\n\nThe clients currently accept either media type. The old style-media type will\nbe deprecated at a later date.\n\n\nModelSerializer 'fields' and 'exclude'\n\n\nModelSerializer and HyperlinkedModelSerializer must include either a fields\noption, or an exclude option. The \nfields = '__all__'\n shortcut may be used to\nexplicitly include all fields.\n\n\nFailing to set either \nfields\n or \nexclude\n raised a pending deprecation warning\nin version 3.3 and raised a deprecation warning in 3.4. Its usage is now mandatory.",
"title": "3.5 Announcement"
},
{
@@ -5117,7 +5117,7 @@
},
{
"location": "/topics/3.5-announcement/#modelserializer-fields-and-exclude",
- "text": "ModelSerializer and HyperlinkedModelSerializer must include either a fields\noption, or an exclude option. The fields = ' all ' shortcut may be used to\nexplicitly include all fields. Failing to set either fields or exclude raised a pending deprecation warning\nin version 3.3 and raised a deprecation warning in 3.4. Its usage is now mandatory.",
+ "text": "ModelSerializer and HyperlinkedModelSerializer must include either a fields\noption, or an exclude option. The fields = '__all__' shortcut may be used to\nexplicitly include all fields. Failing to set either fields or exclude raised a pending deprecation warning\nin version 3.3 and raised a deprecation warning in 3.4. Its usage is now mandatory.",
"title": "ModelSerializer 'fields' and 'exclude'"
},
{
diff --git a/topics/3.5-announcement/index.html b/topics/3.5-announcement/index.html
index e125c154d..99af36450 100644
--- a/topics/3.5-announcement/index.html
+++ b/topics/3.5-announcement/index.html
@@ -617,7 +617,7 @@ other custom media types, such as those used by Swagger and RAML.
be deprecated at a later date.
ModelSerializer and HyperlinkedModelSerializer must include either a fields
-option, or an exclude option. The fields = 'all' shortcut may be used to
+option, or an exclude option. The fields = '__all__' shortcut may be used to
explicitly include all fields.
Failing to set either fields or exclude raised a pending deprecation warning
in version 3.3 and raised a deprecation warning in 3.4. Its usage is now mandatory.