From 38486b2d1571a82ab402278a5ff9ef937d8e23d0 Mon Sep 17 00:00:00 2001
From: Tom Christie <tom@tomchristie.com>
Date: Mon, 18 Jul 2016 10:23:30 -0500
Subject: [PATCH] Deployed e476c22 with MkDocs version: 0.15.3

---
 api-guide/schemas/index.html                  |  16 +--
 api-guide/settings/index.html                 |   2 +-
 mkdocs/search_index.json                      |  20 ++--
 sitemap.xml                                   | 112 +++++++++---------
 .../7-schemas-and-client-libraries/index.html |   6 +-
 5 files changed, 79 insertions(+), 77 deletions(-)

diff --git a/api-guide/schemas/index.html b/api-guide/schemas/index.html
index 6e47178c6..05eefaa36 100644
--- a/api-guide/schemas/index.html
+++ b/api-guide/schemas/index.html
@@ -572,14 +572,14 @@ permission, throttling or authentication policies to the schema endpoint.</p>
 return the schema.</p>
 <p><strong>views.py:</strong></p>
 <pre><code>from rest_framework.decorators import api_view, renderer_classes
-from rest_framework import renderers, schemas
+from rest_framework import renderers, response, schemas
 
-generator = schemas.SchemaGenerator(title='Bookings API')
 
 @api_view()
 @renderer_classes([renderers.CoreJSONRenderer])
 def schema_view(request):
-    return generator.get_schema()
+    generator = schemas.SchemaGenerator(title='Bookings API')
+    return response.Response(generator.get_schema())
 </code></pre>
 <p><strong>urls.py:</strong></p>
 <pre><code>urlpatterns = [
@@ -597,7 +597,8 @@ you need to pass the <code>request</code> argument to the <code>get_schema()</co
 <pre><code>@api_view()
 @renderer_classes([renderers.CoreJSONRenderer])
 def schema_view(request):
-    return generator.get_schema(request=request)
+    generator = schemas.SchemaGenerator(title='Bookings API')
+    return response.Response(generator.get_schema(request=request))
 </code></pre>
 <h2 id="explicit-schema-definition"><a class="toclink" href="#explicit-schema-definition">Explicit schema definition</a></h2>
 <p>An alternative to the auto-generated approach is to specify the API schema
@@ -606,7 +607,7 @@ little more work, but ensures that you have full control over the schema
 representation.</p>
 <pre><code>import coreapi
 from rest_framework.decorators import api_view, renderer_classes
-from rest_framework import renderers
+from rest_framework import renderers, response
 
 schema = coreapi.Document(
     title='Bookings API',
@@ -618,7 +619,7 @@ schema = coreapi.Document(
 @api_view()
 @renderer_classes([renderers.CoreJSONRenderer])
 def schema_view(request):
-    return schema
+    return response.Response(schema)
 </code></pre>
 <h2 id="static-schema-file"><a class="toclink" href="#static-schema-file">Static schema file</a></h2>
 <p>A final option is to write your API schema as a static file, using one
@@ -668,7 +669,8 @@ generate a schema.</p>
 <pre><code>@api_view
 @renderer_classes([renderers.CoreJSONRenderer])
 def schema_view(request):
-    return generator.get_schema()
+    generator = schemas.SchemaGenerator(title='Bookings API')
+    return Response(generator.get_schema())
 </code></pre>
 <p>Arguments:</p>
 <ul>
diff --git a/api-guide/settings/index.html b/api-guide/settings/index.html
index 9b1252f5b..8f77d41fd 100644
--- a/api-guide/settings/index.html
+++ b/api-guide/settings/index.html
@@ -548,7 +548,7 @@ If set to <code>None</code> then generic filtering is disabled.</p>
 <h4 id="allowed_versions"><a class="toclink" href="#allowed_versions">ALLOWED_VERSIONS</a></h4>
 <p>If set, this value will restrict the set of versions that may be returned by the versioning scheme, and will raise an error if the provided version if not in this set.</p>
 <p>Default: <code>None</code></p>
-<h4 id="version_parameter"><a class="toclink" href="#version_parameter">VERSION_PARAMETER</a></h4>
+<h4 id="version_param"><a class="toclink" href="#version_param">VERSION_PARAM</a></h4>
 <p>The string that should used for any versioning parameters, such as in the media type or URL query parameters.</p>
 <p>Default: <code>'version'</code></p>
 <hr />
diff --git a/mkdocs/search_index.json b/mkdocs/search_index.json
index bf21bfc03..65c27563f 100644
--- a/mkdocs/search_index.json
+++ b/mkdocs/search_index.json
@@ -372,7 +372,7 @@
         }, 
         {
             "location": "/tutorial/7-schemas-and-client-libraries/", 
-            "text": "Tutorial 7: Schemas \n client libraries\n\n\nA schema is a machine-readable document that describes the available API\nendpoints, their URLS, and what operations they support.\n\n\nSchemas can be a useful tool for auto-generated documentation, and can also\nbe used to drive dynamic client libraries that can interact with the API.\n\n\nCore API\n\n\nIn order to provide schema support REST framework uses \nCore API\n.\n\n\nCore API is a document specification for describing APIs. It is used to provide\nan internal representation format of the available endpoints and possible\ninteractions that an API exposes. It can either be used server-side, or\nclient-side.\n\n\nWhen used server-side, Core API allows an API to support rendering to a wide\nrange of schema or hypermedia formats.\n\n\nWhen used client-side, Core API allows for dynamically driven client libraries\nthat can interact with any API that exposes a supported schema or hypermedia\nformat.\n\n\nAdding a schema\n\n\nREST framework supports either explicitly defined schema views, or\nautomatically generated schemas. Since we're using viewsets and routers,\nwe can simply use the automatic schema generation.\n\n\nYou'll need to install the \ncoreapi\n python package in order to include an\nAPI schema.\n\n\n$ pip install coreapi\n\n\n\nWe can now include a schema for our API, by adding a \nschema_title\n argument to\nthe router instantiation.\n\n\nrouter = DefaultRouter(schema_title='Pastebin API')\n\n\n\nIf you visit the API root endpoint in a browser you should now see \ncorejson\n\nrepresentation become available as an option.\n\n\n\n\nWe can also request the schema from the command line, by specifying the desired\ncontent type in the \nAccept\n header.\n\n\n$ http http://127.0.0.1:8000/ Accept:application/vnd.coreapi+json\nHTTP/1.0 200 OK\nAllow: GET, HEAD, OPTIONS\nContent-Type: application/vnd.coreapi+json\n\n{\n    \"_meta\": {\n        \"title\": \"Pastebin API\"\n    },\n    \"_type\": \"document\",\n    ...\n\n\n\nThe default output style is to use the \nCore JSON\n encoding.\n\n\nOther schema formats, such as \nOpen API\n (formerly Swagger) are\nalso supported.\n\n\nUsing a command line client\n\n\nNow that our API is exposing a schema endpoint, we can use a dynamic client\nlibrary to interact with the API. To demonstrate this, let's use the\nCore API command line client.\n\n\nThe command line client is available as the \ncoreapi-cli\n package:\n\n\n$ pip install coreapi-cli\n\n\n\nNow check that it is available on the command line...\n\n\n$ coreapi\nUsage: coreapi [OPTIONS] COMMAND [ARGS]...\n\n  Command line client for interacting with CoreAPI services.\n\n  Visit http://www.coreapi.org for more information.\n\nOptions:\n  --version  Display the package version number.\n  --help     Show this message and exit.\n\nCommands:\n...\n\n\n\nFirst we'll load the API schema using the command line client.\n\n\n$ coreapi get http://127.0.0.1:8000/\n\nPastebin API \"http://127.0.0.1:8000/\"\n\n    snippets: {\n        highlight(pk)\n        list()\n        retrieve(pk)\n    }\n    users: {\n        list()\n        retrieve(pk)\n    }\n\n\n\nWe haven't authenticated yet, so right now we're only able to see the read only\nendpoints, in line with how we've set up the permissions on the API.\n\n\nLet's try listing the existing snippets, using the command line client:\n\n\n$ coreapi action snippets list\n[\n    {\n        \"url\": \"http://127.0.0.1:8000/snippets/1/\",\n        \"pk\": 1,\n        \"highlight\": \"http://127.0.0.1:8000/snippets/1/highlight/\",\n        \"owner\": \"lucy\",\n        \"title\": \"Example\",\n        \"code\": \"print('hello, world!')\",\n        \"linenos\": true,\n        \"language\": \"python\",\n        \"style\": \"friendly\"\n    },\n    ...\n\n\n\nSome of the API endpoints require named parameters. For example, to get back\nthe highlight HTML for a particular snippet we need to provide an id.\n\n\n$ coreapi action snippets highlight --param pk 1\n\n!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01//EN\" \"http://www.w3.org/TR/html4/strict.dtd\"\n\n\n\nhtml\n\n\nhead\n\n  \ntitle\nExample\n/title\n\n  ...\n\n\n\nAuthenticating our client\n\n\nIf we want to be able to create, edit and delete snippets, we'll need to\nauthenticate as a valid user. In this case we'll just use basic auth.\n\n\nMake sure to replace the \nusername\n and \npassword\n below with your\nactual username and password.\n\n\n$ coreapi credentials add 127.0.0.1 \nusername\n:\npassword\n --auth basic\nAdded credentials\n127.0.0.1 \"Basic \n...\n\"\n\n\n\nNow if we fetch the schema again, we should be able to see the full\nset of available interactions.\n\n\n$ coreapi reload\nPastebin API \"http://127.0.0.1:8000/\"\n\n    snippets: {\n        create(code, [title], [linenos], [language], [style])\n        destroy(pk)\n        highlight(pk)\n        list()\n        partial_update(pk, [title], [code], [linenos], [language], [style])\n        retrieve(pk)\n        update(pk, code, [title], [linenos], [language], [style])\n    }\n    users: {\n        list()\n        retrieve(pk)\n    }\n\n\n\nWe're now able to interact with these endpoints. For example, to create a new\nsnippet:\n\n\n$ coreapi action snippets create --param title \"Example\" --param code \"print('hello, world')\"\n{\n    \"url\": \"http://127.0.0.1:8000/snippets/7/\",\n    \"pk\": 7,\n    \"highlight\": \"http://127.0.0.1:8000/snippets/7/highlight/\",\n    \"owner\": \"lucy\",\n    \"title\": \"Example\",\n    \"code\": \"print('hello, world')\",\n    \"linenos\": false,\n    \"language\": \"python\",\n    \"style\": \"friendly\"\n}\n\n\n\nAnd to delete a snippet:\n\n\n$ coreapi action snippets destroy --param pk 7\n\n\n\nAs well as the command line client, developers can also interact with your\nAPI using client libraries. The Python client library is the first of these\nto be available, and a Javascript client library is planned to be released\nsoon.\n\n\nFor more details on customizing schema generation and using Core API\nclient libraries you'll need to refer to the full documentation.\n\n\nReviewing our work\n\n\nWith an incredibly small amount of code, we've now got a complete pastebin Web API, which is fully web browsable, includes a schema-driven client library, and comes complete with authentication, per-object permissions, and multiple renderer formats.\n\n\nWe've walked through each step of the design process, and seen how if we need to customize anything we can gradually work our way down to simply using regular Django views.\n\n\nYou can review the final \ntutorial code\n on GitHub, or try out a live example in \nthe sandbox\n.\n\n\nOnwards and upwards\n\n\nWe've reached the end of our tutorial.  If you want to get more involved in the REST framework project, here are a few places you can start:\n\n\n\n\nContribute on \nGitHub\n by reviewing and submitting issues, and making pull requests.\n\n\nJoin the \nREST framework discussion group\n, and help build the community.\n\n\nFollow \nthe author\n on Twitter and say hi.\n\n\n\n\nNow go build awesome things.", 
+            "text": "Tutorial 7: Schemas \n client libraries\n\n\nA schema is a machine-readable document that describes the available API\nendpoints, their URLS, and what operations they support.\n\n\nSchemas can be a useful tool for auto-generated documentation, and can also\nbe used to drive dynamic client libraries that can interact with the API.\n\n\nCore API\n\n\nIn order to provide schema support REST framework uses \nCore API\n.\n\n\nCore API is a document specification for describing APIs. It is used to provide\nan internal representation format of the available endpoints and possible\ninteractions that an API exposes. It can either be used server-side, or\nclient-side.\n\n\nWhen used server-side, Core API allows an API to support rendering to a wide\nrange of schema or hypermedia formats.\n\n\nWhen used client-side, Core API allows for dynamically driven client libraries\nthat can interact with any API that exposes a supported schema or hypermedia\nformat.\n\n\nAdding a schema\n\n\nREST framework supports either explicitly defined schema views, or\nautomatically generated schemas. Since we're using viewsets and routers,\nwe can simply use the automatic schema generation.\n\n\nYou'll need to install the \ncoreapi\n python package in order to include an\nAPI schema.\n\n\n$ pip install coreapi\n\n\n\nWe can now include a schema for our API, by adding a \nschema_title\n argument to\nthe router instantiation.\n\n\nrouter = DefaultRouter(schema_title='Pastebin API')\n\n\n\nIf you visit the API root endpoint in a browser you should now see \ncorejson\n\nrepresentation become available as an option.\n\n\n\n\nWe can also request the schema from the command line, by specifying the desired\ncontent type in the \nAccept\n header.\n\n\n$ http http://127.0.0.1:8000/ Accept:application/vnd.coreapi+json\nHTTP/1.0 200 OK\nAllow: GET, HEAD, OPTIONS\nContent-Type: application/vnd.coreapi+json\n\n{\n    \"_meta\": {\n        \"title\": \"Pastebin API\"\n    },\n    \"_type\": \"document\",\n    ...\n\n\n\nThe default output style is to use the \nCore JSON\n encoding.\n\n\nOther schema formats, such as \nOpen API\n (formerly Swagger) are\nalso supported.\n\n\nUsing a command line client\n\n\nNow that our API is exposing a schema endpoint, we can use a dynamic client\nlibrary to interact with the API. To demonstrate this, let's use the\nCore API command line client.\n\n\nThe command line client is available as the \ncoreapi-cli\n package:\n\n\n$ pip install coreapi-cli\n\n\n\nNow check that it is available on the command line...\n\n\n$ coreapi\nUsage: coreapi [OPTIONS] COMMAND [ARGS]...\n\n  Command line client for interacting with CoreAPI services.\n\n  Visit http://www.coreapi.org for more information.\n\nOptions:\n  --version  Display the package version number.\n  --help     Show this message and exit.\n\nCommands:\n...\n\n\n\nFirst we'll load the API schema using the command line client.\n\n\n$ coreapi get http://127.0.0.1:8000/\n\nPastebin API \"http://127.0.0.1:8000/\"\n\n    snippets: {\n        highlight(pk)\n        list()\n        retrieve(pk)\n    }\n    users: {\n        list()\n        retrieve(pk)\n    }\n\n\n\nWe haven't authenticated yet, so right now we're only able to see the read only\nendpoints, in line with how we've set up the permissions on the API.\n\n\nLet's try listing the existing snippets, using the command line client:\n\n\n$ coreapi action snippets list\n[\n    {\n        \"url\": \"http://127.0.0.1:8000/snippets/1/\",\n        \"pk\": 1,\n        \"highlight\": \"http://127.0.0.1:8000/snippets/1/highlight/\",\n        \"owner\": \"lucy\",\n        \"title\": \"Example\",\n        \"code\": \"print('hello, world!')\",\n        \"linenos\": true,\n        \"language\": \"python\",\n        \"style\": \"friendly\"\n    },\n    ...\n\n\n\nSome of the API endpoints require named parameters. For example, to get back\nthe highlight HTML for a particular snippet we need to provide an id.\n\n\n$ coreapi action snippets highlight --param pk=1\n\n!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01//EN\" \"http://www.w3.org/TR/html4/strict.dtd\"\n\n\n\nhtml\n\n\nhead\n\n  \ntitle\nExample\n/title\n\n  ...\n\n\n\nAuthenticating our client\n\n\nIf we want to be able to create, edit and delete snippets, we'll need to\nauthenticate as a valid user. In this case we'll just use basic auth.\n\n\nMake sure to replace the \nusername\n and \npassword\n below with your\nactual username and password.\n\n\n$ coreapi credentials add 127.0.0.1 \nusername\n:\npassword\n --auth basic\nAdded credentials\n127.0.0.1 \"Basic \n...\n\"\n\n\n\nNow if we fetch the schema again, we should be able to see the full\nset of available interactions.\n\n\n$ coreapi reload\nPastebin API \"http://127.0.0.1:8000/\"\n\n    snippets: {\n        create(code, [title], [linenos], [language], [style])\n        destroy(pk)\n        highlight(pk)\n        list()\n        partial_update(pk, [title], [code], [linenos], [language], [style])\n        retrieve(pk)\n        update(pk, code, [title], [linenos], [language], [style])\n    }\n    users: {\n        list()\n        retrieve(pk)\n    }\n\n\n\nWe're now able to interact with these endpoints. For example, to create a new\nsnippet:\n\n\n$ coreapi action snippets create --param title=\"Example\" --param code=\"print('hello, world')\"\n{\n    \"url\": \"http://127.0.0.1:8000/snippets/7/\",\n    \"pk\": 7,\n    \"highlight\": \"http://127.0.0.1:8000/snippets/7/highlight/\",\n    \"owner\": \"lucy\",\n    \"title\": \"Example\",\n    \"code\": \"print('hello, world')\",\n    \"linenos\": false,\n    \"language\": \"python\",\n    \"style\": \"friendly\"\n}\n\n\n\nAnd to delete a snippet:\n\n\n$ coreapi action snippets destroy --param pk=7\n\n\n\nAs well as the command line client, developers can also interact with your\nAPI using client libraries. The Python client library is the first of these\nto be available, and a Javascript client library is planned to be released\nsoon.\n\n\nFor more details on customizing schema generation and using Core API\nclient libraries you'll need to refer to the full documentation.\n\n\nReviewing our work\n\n\nWith an incredibly small amount of code, we've now got a complete pastebin Web API, which is fully web browsable, includes a schema-driven client library, and comes complete with authentication, per-object permissions, and multiple renderer formats.\n\n\nWe've walked through each step of the design process, and seen how if we need to customize anything we can gradually work our way down to simply using regular Django views.\n\n\nYou can review the final \ntutorial code\n on GitHub, or try out a live example in \nthe sandbox\n.\n\n\nOnwards and upwards\n\n\nWe've reached the end of our tutorial.  If you want to get more involved in the REST framework project, here are a few places you can start:\n\n\n\n\nContribute on \nGitHub\n by reviewing and submitting issues, and making pull requests.\n\n\nJoin the \nREST framework discussion group\n, and help build the community.\n\n\nFollow \nthe author\n on Twitter and say hi.\n\n\n\n\nNow go build awesome things.", 
             "title": "7 - Schemas and client libraries"
         }, 
         {
@@ -392,12 +392,12 @@
         }, 
         {
             "location": "/tutorial/7-schemas-and-client-libraries/#using-a-command-line-client", 
-            "text": "Now that our API is exposing a schema endpoint, we can use a dynamic client\nlibrary to interact with the API. To demonstrate this, let's use the\nCore API command line client.  The command line client is available as the  coreapi-cli  package:  $ pip install coreapi-cli  Now check that it is available on the command line...  $ coreapi\nUsage: coreapi [OPTIONS] COMMAND [ARGS]...\n\n  Command line client for interacting with CoreAPI services.\n\n  Visit http://www.coreapi.org for more information.\n\nOptions:\n  --version  Display the package version number.\n  --help     Show this message and exit.\n\nCommands:\n...  First we'll load the API schema using the command line client.  $ coreapi get http://127.0.0.1:8000/ Pastebin API \"http://127.0.0.1:8000/\" \n    snippets: {\n        highlight(pk)\n        list()\n        retrieve(pk)\n    }\n    users: {\n        list()\n        retrieve(pk)\n    }  We haven't authenticated yet, so right now we're only able to see the read only\nendpoints, in line with how we've set up the permissions on the API.  Let's try listing the existing snippets, using the command line client:  $ coreapi action snippets list\n[\n    {\n        \"url\": \"http://127.0.0.1:8000/snippets/1/\",\n        \"pk\": 1,\n        \"highlight\": \"http://127.0.0.1:8000/snippets/1/highlight/\",\n        \"owner\": \"lucy\",\n        \"title\": \"Example\",\n        \"code\": \"print('hello, world!')\",\n        \"linenos\": true,\n        \"language\": \"python\",\n        \"style\": \"friendly\"\n    },\n    ...  Some of the API endpoints require named parameters. For example, to get back\nthe highlight HTML for a particular snippet we need to provide an id.  $ coreapi action snippets highlight --param pk 1 !DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01//EN\" \"http://www.w3.org/TR/html4/strict.dtd\"  html  head \n   title Example /title \n  ...", 
+            "text": "Now that our API is exposing a schema endpoint, we can use a dynamic client\nlibrary to interact with the API. To demonstrate this, let's use the\nCore API command line client.  The command line client is available as the  coreapi-cli  package:  $ pip install coreapi-cli  Now check that it is available on the command line...  $ coreapi\nUsage: coreapi [OPTIONS] COMMAND [ARGS]...\n\n  Command line client for interacting with CoreAPI services.\n\n  Visit http://www.coreapi.org for more information.\n\nOptions:\n  --version  Display the package version number.\n  --help     Show this message and exit.\n\nCommands:\n...  First we'll load the API schema using the command line client.  $ coreapi get http://127.0.0.1:8000/ Pastebin API \"http://127.0.0.1:8000/\" \n    snippets: {\n        highlight(pk)\n        list()\n        retrieve(pk)\n    }\n    users: {\n        list()\n        retrieve(pk)\n    }  We haven't authenticated yet, so right now we're only able to see the read only\nendpoints, in line with how we've set up the permissions on the API.  Let's try listing the existing snippets, using the command line client:  $ coreapi action snippets list\n[\n    {\n        \"url\": \"http://127.0.0.1:8000/snippets/1/\",\n        \"pk\": 1,\n        \"highlight\": \"http://127.0.0.1:8000/snippets/1/highlight/\",\n        \"owner\": \"lucy\",\n        \"title\": \"Example\",\n        \"code\": \"print('hello, world!')\",\n        \"linenos\": true,\n        \"language\": \"python\",\n        \"style\": \"friendly\"\n    },\n    ...  Some of the API endpoints require named parameters. For example, to get back\nthe highlight HTML for a particular snippet we need to provide an id.  $ coreapi action snippets highlight --param pk=1 !DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01//EN\" \"http://www.w3.org/TR/html4/strict.dtd\"  html  head \n   title Example /title \n  ...", 
             "title": "Using a command line client"
         }, 
         {
             "location": "/tutorial/7-schemas-and-client-libraries/#authenticating-our-client", 
-            "text": "If we want to be able to create, edit and delete snippets, we'll need to\nauthenticate as a valid user. In this case we'll just use basic auth.  Make sure to replace the  username  and  password  below with your\nactual username and password.  $ coreapi credentials add 127.0.0.1  username : password  --auth basic\nAdded credentials\n127.0.0.1 \"Basic  ... \"  Now if we fetch the schema again, we should be able to see the full\nset of available interactions.  $ coreapi reload\nPastebin API \"http://127.0.0.1:8000/\" \n    snippets: {\n        create(code, [title], [linenos], [language], [style])\n        destroy(pk)\n        highlight(pk)\n        list()\n        partial_update(pk, [title], [code], [linenos], [language], [style])\n        retrieve(pk)\n        update(pk, code, [title], [linenos], [language], [style])\n    }\n    users: {\n        list()\n        retrieve(pk)\n    }  We're now able to interact with these endpoints. For example, to create a new\nsnippet:  $ coreapi action snippets create --param title \"Example\" --param code \"print('hello, world')\"\n{\n    \"url\": \"http://127.0.0.1:8000/snippets/7/\",\n    \"pk\": 7,\n    \"highlight\": \"http://127.0.0.1:8000/snippets/7/highlight/\",\n    \"owner\": \"lucy\",\n    \"title\": \"Example\",\n    \"code\": \"print('hello, world')\",\n    \"linenos\": false,\n    \"language\": \"python\",\n    \"style\": \"friendly\"\n}  And to delete a snippet:  $ coreapi action snippets destroy --param pk 7  As well as the command line client, developers can also interact with your\nAPI using client libraries. The Python client library is the first of these\nto be available, and a Javascript client library is planned to be released\nsoon.  For more details on customizing schema generation and using Core API\nclient libraries you'll need to refer to the full documentation.", 
+            "text": "If we want to be able to create, edit and delete snippets, we'll need to\nauthenticate as a valid user. In this case we'll just use basic auth.  Make sure to replace the  username  and  password  below with your\nactual username and password.  $ coreapi credentials add 127.0.0.1  username : password  --auth basic\nAdded credentials\n127.0.0.1 \"Basic  ... \"  Now if we fetch the schema again, we should be able to see the full\nset of available interactions.  $ coreapi reload\nPastebin API \"http://127.0.0.1:8000/\" \n    snippets: {\n        create(code, [title], [linenos], [language], [style])\n        destroy(pk)\n        highlight(pk)\n        list()\n        partial_update(pk, [title], [code], [linenos], [language], [style])\n        retrieve(pk)\n        update(pk, code, [title], [linenos], [language], [style])\n    }\n    users: {\n        list()\n        retrieve(pk)\n    }  We're now able to interact with these endpoints. For example, to create a new\nsnippet:  $ coreapi action snippets create --param title=\"Example\" --param code=\"print('hello, world')\"\n{\n    \"url\": \"http://127.0.0.1:8000/snippets/7/\",\n    \"pk\": 7,\n    \"highlight\": \"http://127.0.0.1:8000/snippets/7/highlight/\",\n    \"owner\": \"lucy\",\n    \"title\": \"Example\",\n    \"code\": \"print('hello, world')\",\n    \"linenos\": false,\n    \"language\": \"python\",\n    \"style\": \"friendly\"\n}  And to delete a snippet:  $ coreapi action snippets destroy --param pk=7  As well as the command line client, developers can also interact with your\nAPI using client libraries. The Python client library is the first of these\nto be available, and a Javascript client library is planned to be released\nsoon.  For more details on customizing schema generation and using Core API\nclient libraries you'll need to refer to the full documentation.", 
             "title": "Authenticating our client"
         }, 
         {
@@ -2982,7 +2982,7 @@
         }, 
         {
             "location": "/api-guide/schemas/", 
-            "text": "Schemas\n\n\n\n\nA machine-readable [schema] describes what resources are available via the API, what their URLs are, how they are represented and what operations they support.\n\n\n Heroku, \nJSON Schema for the Heroku Platform API\n\n\n\n\nAPI schemas are a useful tool that allow for a range of use cases, including\ngenerating reference documentation, or driving dynamic client libraries that\ncan interact with your API.\n\n\nRepresenting schemas internally\n\n\nREST framework uses \nCore API\n in order to model schema information in\na format-independent representation. This information can then be rendered\ninto various different schema formats, or used to generate API documentation.\n\n\nWhen using Core API, a schema is represented as a \nDocument\n which is the\ntop-level container object for information about the API. Available API\ninteractions are represented using \nLink\n objects. Each link includes a URL,\nHTTP method, and may include a list of \nField\n instances, which describe any\nparameters that may be accepted by the API endpoint. The \nLink\n and \nField\n\ninstances may also include descriptions, that allow an API schema to be\nrendered into user documentation.\n\n\nHere's an example of an API description that includes a single \nsearch\n\nendpoint:\n\n\ncoreapi.Document(\n    title='Flight Search API',\n    url='https://api.example.org/',\n    content={\n        'search': coreapi.Link(\n            url='/search/',\n            action='get',\n            fields=[\n                coreapi.Field(\n                    name='from',\n                    required=True,\n                    location='query',\n                    description='City name or airport code.'\n                ),\n                coreapi.Field(\n                    name='to',\n                    required=True,\n                    location='query',\n                    description='City name or airport code.'\n                ),\n                coreapi.Field(\n                    name='date',\n                    required=True,\n                    location='query',\n                    description='Flight date in \"YYYY-MM-DD\" format.'\n                )\n            ],\n            description='Return flight availability and prices.'\n        )\n    }\n)\n\n\n\nSchema output formats\n\n\nIn order to be presented in an HTTP response, the internal representation\nhas to be rendered into the actual bytes that are used in the response.\n\n\nCore JSON\n is designed as a canonical format for use with Core API.\nREST framework includes a renderer class for handling this media type, which\nis available as \nrenderers.CoreJSONRenderer\n.\n\n\nOther schema formats such as \nOpen API\n (\"Swagger\"),\n\nJSON HyperSchema\n, or \nAPI Blueprint\n can\nalso be supported by implementing a custom renderer class.\n\n\nSchemas vs Hypermedia\n\n\nIt's worth pointing out here that Core API can also be used to model hypermedia\nresponses, which present an alternative interaction style to API schemas.\n\n\nWith an API schema, the entire available interface is presented up-front\nas a single endpoint. Responses to individual API endpoints are then typically\npresented as plain data, without any further interactions contained in each\nresponse.\n\n\nWith Hypermedia, the client is instead presented with a document containing\nboth data and available interactions. Each interaction results in a new\ndocument, detailing both the current state and the available interactions.\n\n\nFurther information and support on building Hypermedia APIs with REST framework\nis planned for a future version.\n\n\n\n\nAdding a schema\n\n\nYou'll need to install the \ncoreapi\n package in order to add schema support\nfor REST framework.\n\n\npip install coreapi\n\n\n\nREST framework includes functionality for auto-generating a schema,\nor allows you to specify one explicitly. There are a few different ways to\nadd a schema to your API, depending on exactly what you need.\n\n\nUsing DefaultRouter\n\n\nIf you're using \nDefaultRouter\n then you can include an auto-generated schema,\nsimply by adding a \nschema_title\n argument to the router.\n\n\nrouter = DefaultRouter(schema_title='Server Monitoring API')\n\n\n\nThe schema will be included at the root URL, \n/\n, and presented to clients\nthat include the Core JSON media type in their \nAccept\n header.\n\n\n$ http http://127.0.0.1:8000/ Accept:application/vnd.coreapi+json\nHTTP/1.0 200 OK\nAllow: GET, HEAD, OPTIONS\nContent-Type: application/vnd.coreapi+json\n\n{\n    \"_meta\": {\n        \"title\": \"Server Monitoring API\"\n    },\n    \"_type\": \"document\",\n    ...\n}\n\n\n\nThis is a great zero-configuration option for when you want to get up and\nrunning really quickly.\n\n\nThe only other available option to \nDefaultRouter\n is \nschema_renderers\n, which\nmay be used to pass the set of renderer classes that can be used to render\nschema output.\n\n\nfrom rest_framework.renderers import CoreJSONRenderer\nfrom my_custom_package import APIBlueprintRenderer\n\nrouter = DefaultRouter(schema_title='Server Monitoring API', schema_renderers=[\n    CoreJSONRenderer, APIBlueprintRenderer\n])\n\n\n\nIf you want more flexibility over the schema output then you'll need to consider\nusing \nSchemaGenerator\n instead.\n\n\nUsing SchemaGenerator\n\n\nThe most common way to add a schema to your API is to use the \nSchemaGenerator\n\nclass to auto-generate the \nDocument\n instance, and to return that from a view.\n\n\nThis option gives you the flexibility of setting up the schema endpoint\nwith whatever behavior you want. For example, you can apply different\npermission, throttling or authentication policies to the schema endpoint.\n\n\nHere's an example of using \nSchemaGenerator\n together with a view to\nreturn the schema.\n\n\nviews.py:\n\n\nfrom rest_framework.decorators import api_view, renderer_classes\nfrom rest_framework import renderers, schemas\n\ngenerator = schemas.SchemaGenerator(title='Bookings API')\n\n@api_view()\n@renderer_classes([renderers.CoreJSONRenderer])\ndef schema_view(request):\n    return generator.get_schema()\n\n\n\nurls.py:\n\n\nurlpatterns = [\n    url('/', schema_view),\n    ...\n]\n\n\n\nYou can also serve different schemas to different users, depending on the\npermissions they have available. This approach can be used to ensure that\nunauthenticated requests are presented with a different schema to\nauthenticated requests, or to ensure that different parts of the API are\nmade visible to different users depending on their role.\n\n\nIn order to present a schema with endpoints filtered by user permissions,\nyou need to pass the \nrequest\n argument to the \nget_schema()\n method, like so:\n\n\n@api_view()\n@renderer_classes([renderers.CoreJSONRenderer])\ndef schema_view(request):\n    return generator.get_schema(request=request)\n\n\n\nExplicit schema definition\n\n\nAn alternative to the auto-generated approach is to specify the API schema\nexplicitly, by declaring a \nDocument\n object in your codebase. Doing so is a\nlittle more work, but ensures that you have full control over the schema\nrepresentation.\n\n\nimport coreapi\nfrom rest_framework.decorators import api_view, renderer_classes\nfrom rest_framework import renderers\n\nschema = coreapi.Document(\n    title='Bookings API',\n    content={\n        ...\n    }\n)\n\n@api_view()\n@renderer_classes([renderers.CoreJSONRenderer])\ndef schema_view(request):\n    return schema\n\n\n\nStatic schema file\n\n\nA final option is to write your API schema as a static file, using one\nof the available formats, such as Core JSON or Open API.\n\n\nYou could then either:\n\n\n\n\nWrite a schema definition as a static file, and \nserve the static file directly\n.\n\n\nWrite a schema definition that is loaded using \nCore API\n, and then\n  rendered to one of many available formats, depending on the client request.\n\n\n\n\n\n\nAlternate schema formats\n\n\nIn order to support an alternate schema format, you need to implement a custom renderer\nclass that handles converting a \nDocument\n instance into a bytestring representation.\n\n\nIf there is a Core API codec package that supports encoding into the format you\nwant to use then implementing the renderer class can be done by using the codec.\n\n\nExample\n\n\nFor example, the \nopenapi_codec\n package provides support for encoding or decoding\nto the Open API (\"Swagger\") format:\n\n\nfrom rest_framework import renderers\nfrom openapi_codec import OpenAPICodec\n\nclass SwaggerRenderer(renderers.BaseRenderer):\n    media_type = 'application/openapi+json;version=2.0'\n    format = 'swagger'\n\n    def render(self, data, media_type=None, renderer_context=None):\n        codec = OpenAPICodec()\n        return OpenAPICodec.dump(data)\n\n\n\n\n\nAPI Reference\n\n\nSchemaGenerator\n\n\nA class that deals with introspecting your API views, which can be used to\ngenerate a schema.\n\n\nTypically you'll instantiate \nSchemaGenerator\n with a single argument, like so:\n\n\ngenerator = SchemaGenerator(title='Stock Prices API')\n\n\n\nArguments:\n\n\n\n\ntitle\n - The name of the API. \nrequired\n\n\npatterns\n - A list of URLs to inspect when generating the schema. Defaults to the project's URL conf.\n\n\nurlconf\n - A URL conf module name to use when generating the schema. Defaults to \nsettings.ROOT_URLCONF\n.\n\n\n\n\nget_schema()\n\n\nReturns a \ncoreapi.Document\n instance that represents the API schema.\n\n\n@api_view\n@renderer_classes([renderers.CoreJSONRenderer])\ndef schema_view(request):\n    return generator.get_schema()\n\n\n\nArguments:\n\n\n\n\nrequest\n - The incoming request. Optionally used if you want to apply per-user permissions to the schema-generation.\n\n\n\n\n\n\nCore API\n\n\nThis documentation gives a brief overview of the components within the \ncoreapi\n\npackage that are used to represent an API schema.\n\n\nNote that these classes are imported from the \ncoreapi\n package, rather than\nfrom the \nrest_framework\n package.\n\n\nDocument\n\n\nRepresents a container for the API schema.\n\n\ntitle\n\n\nA name for the API.\n\n\nurl\n\n\nA canonical URL for the API.\n\n\ncontent\n\n\nA dictionary, containing the \nLink\n objects that the schema contains.\n\n\nIn order to provide more structure to the schema, the \ncontent\n dictionary\nmay be nested, typically to a second level. For example:\n\n\ncontent={\n    \"bookings\": {\n        \"list\": Link(...),\n        \"create\": Link(...),\n        ...\n    },\n    \"venues\": {\n        \"list\": Link(...),\n        ...\n    },\n    ...\n}\n\n\n\nLink\n\n\nRepresents an individual API endpoint.\n\n\nurl\n\n\nThe URL of the endpoint. May be a URI template, such as \n/users/{username}/\n.\n\n\naction\n\n\nThe HTTP method associated with the endpoint. Note that URLs that support\nmore than one HTTP method, should correspond to a single \nLink\n for each.\n\n\nfields\n\n\nA list of \nField\n instances, describing the available parameters on the input.\n\n\ndescription\n\n\nA short description of the meaning and intended usage of the endpoint.\n\n\nField\n\n\nRepresents a single input parameter on a given API endpoint.\n\n\nname\n\n\nA descriptive name for the input.\n\n\nrequired\n\n\nA boolean, indicated if the client is required to included a value, or if\nthe parameter can be omitted.\n\n\nlocation\n\n\nDetermines how the information is encoded into the request. Should be one of\nthe following strings:\n\n\n\"path\"\n\n\nIncluded in a templated URI. For example a \nurl\n value of \n/products/{product_code}/\n could be used together with a \n\"path\"\n field, to handle API inputs in a URL path such as \n/products/slim-fit-jeans/\n.\n\n\nThese fields will normally correspond with \nnamed arguments in the project URL conf\n.\n\n\n\"query\"\n\n\nIncluded as a URL query parameter. For example \n?search=sale\n. Typically for \nGET\n requests.\n\n\nThese fields will normally correspond with pagination and filtering controls on a view.\n\n\n\"form\"\n\n\nIncluded in the request body, as a single item of a JSON object or HTML form. For example \n{\"colour\": \"blue\", ...}\n. Typically for \nPOST\n, \nPUT\n and \nPATCH\n requests. Multiple \n\"form\"\n fields may be included on a single link.\n\n\nThese fields will normally correspond with serializer fields on a view.\n\n\n\"body\"\n\n\nIncluded as the complete request body. Typically for \nPOST\n, \nPUT\n and \nPATCH\n requests. No more than one \n\"body\"\n field may exist on a link. May not be used together with \n\"form\"\n fields.\n\n\nThese fields will normally correspond with views that use \nListSerializer\n to validate the request input, or with file upload views.\n\n\nencoding\n\n\n\"application/json\"\n\n\nJSON encoded request content. Corresponds to views using \nJSONParser\n.\nValid only if either one or more \nlocation=\"form\"\n fields, or a single\n\nlocation=\"body\"\n field is included on the \nLink\n.\n\n\n\"multipart/form-data\"\n\n\nMultipart encoded request content. Corresponds to views using \nMultiPartParser\n.\nValid only if one or more \nlocation=\"form\"\n fields is included on the \nLink\n.\n\n\n\"application/x-www-form-urlencoded\"\n\n\nURL encoded request content. Corresponds to views using \nFormParser\n. Valid\nonly if one or more \nlocation=\"form\"\n fields is included on the \nLink\n.\n\n\n\"application/octet-stream\"\n\n\nBinary upload request content. Corresponds to views using \nFileUploadParser\n.\nValid only if a \nlocation=\"body\"\n field is included on the \nLink\n.\n\n\ndescription\n\n\nA short description of the meaning and intended usage of the input field.", 
+            "text": "Schemas\n\n\n\n\nA machine-readable [schema] describes what resources are available via the API, what their URLs are, how they are represented and what operations they support.\n\n\n Heroku, \nJSON Schema for the Heroku Platform API\n\n\n\n\nAPI schemas are a useful tool that allow for a range of use cases, including\ngenerating reference documentation, or driving dynamic client libraries that\ncan interact with your API.\n\n\nRepresenting schemas internally\n\n\nREST framework uses \nCore API\n in order to model schema information in\na format-independent representation. This information can then be rendered\ninto various different schema formats, or used to generate API documentation.\n\n\nWhen using Core API, a schema is represented as a \nDocument\n which is the\ntop-level container object for information about the API. Available API\ninteractions are represented using \nLink\n objects. Each link includes a URL,\nHTTP method, and may include a list of \nField\n instances, which describe any\nparameters that may be accepted by the API endpoint. The \nLink\n and \nField\n\ninstances may also include descriptions, that allow an API schema to be\nrendered into user documentation.\n\n\nHere's an example of an API description that includes a single \nsearch\n\nendpoint:\n\n\ncoreapi.Document(\n    title='Flight Search API',\n    url='https://api.example.org/',\n    content={\n        'search': coreapi.Link(\n            url='/search/',\n            action='get',\n            fields=[\n                coreapi.Field(\n                    name='from',\n                    required=True,\n                    location='query',\n                    description='City name or airport code.'\n                ),\n                coreapi.Field(\n                    name='to',\n                    required=True,\n                    location='query',\n                    description='City name or airport code.'\n                ),\n                coreapi.Field(\n                    name='date',\n                    required=True,\n                    location='query',\n                    description='Flight date in \"YYYY-MM-DD\" format.'\n                )\n            ],\n            description='Return flight availability and prices.'\n        )\n    }\n)\n\n\n\nSchema output formats\n\n\nIn order to be presented in an HTTP response, the internal representation\nhas to be rendered into the actual bytes that are used in the response.\n\n\nCore JSON\n is designed as a canonical format for use with Core API.\nREST framework includes a renderer class for handling this media type, which\nis available as \nrenderers.CoreJSONRenderer\n.\n\n\nOther schema formats such as \nOpen API\n (\"Swagger\"),\n\nJSON HyperSchema\n, or \nAPI Blueprint\n can\nalso be supported by implementing a custom renderer class.\n\n\nSchemas vs Hypermedia\n\n\nIt's worth pointing out here that Core API can also be used to model hypermedia\nresponses, which present an alternative interaction style to API schemas.\n\n\nWith an API schema, the entire available interface is presented up-front\nas a single endpoint. Responses to individual API endpoints are then typically\npresented as plain data, without any further interactions contained in each\nresponse.\n\n\nWith Hypermedia, the client is instead presented with a document containing\nboth data and available interactions. Each interaction results in a new\ndocument, detailing both the current state and the available interactions.\n\n\nFurther information and support on building Hypermedia APIs with REST framework\nis planned for a future version.\n\n\n\n\nAdding a schema\n\n\nYou'll need to install the \ncoreapi\n package in order to add schema support\nfor REST framework.\n\n\npip install coreapi\n\n\n\nREST framework includes functionality for auto-generating a schema,\nor allows you to specify one explicitly. There are a few different ways to\nadd a schema to your API, depending on exactly what you need.\n\n\nUsing DefaultRouter\n\n\nIf you're using \nDefaultRouter\n then you can include an auto-generated schema,\nsimply by adding a \nschema_title\n argument to the router.\n\n\nrouter = DefaultRouter(schema_title='Server Monitoring API')\n\n\n\nThe schema will be included at the root URL, \n/\n, and presented to clients\nthat include the Core JSON media type in their \nAccept\n header.\n\n\n$ http http://127.0.0.1:8000/ Accept:application/vnd.coreapi+json\nHTTP/1.0 200 OK\nAllow: GET, HEAD, OPTIONS\nContent-Type: application/vnd.coreapi+json\n\n{\n    \"_meta\": {\n        \"title\": \"Server Monitoring API\"\n    },\n    \"_type\": \"document\",\n    ...\n}\n\n\n\nThis is a great zero-configuration option for when you want to get up and\nrunning really quickly.\n\n\nThe only other available option to \nDefaultRouter\n is \nschema_renderers\n, which\nmay be used to pass the set of renderer classes that can be used to render\nschema output.\n\n\nfrom rest_framework.renderers import CoreJSONRenderer\nfrom my_custom_package import APIBlueprintRenderer\n\nrouter = DefaultRouter(schema_title='Server Monitoring API', schema_renderers=[\n    CoreJSONRenderer, APIBlueprintRenderer\n])\n\n\n\nIf you want more flexibility over the schema output then you'll need to consider\nusing \nSchemaGenerator\n instead.\n\n\nUsing SchemaGenerator\n\n\nThe most common way to add a schema to your API is to use the \nSchemaGenerator\n\nclass to auto-generate the \nDocument\n instance, and to return that from a view.\n\n\nThis option gives you the flexibility of setting up the schema endpoint\nwith whatever behavior you want. For example, you can apply different\npermission, throttling or authentication policies to the schema endpoint.\n\n\nHere's an example of using \nSchemaGenerator\n together with a view to\nreturn the schema.\n\n\nviews.py:\n\n\nfrom rest_framework.decorators import api_view, renderer_classes\nfrom rest_framework import renderers, response, schemas\n\n\n@api_view()\n@renderer_classes([renderers.CoreJSONRenderer])\ndef schema_view(request):\n    generator = schemas.SchemaGenerator(title='Bookings API')\n    return response.Response(generator.get_schema())\n\n\n\nurls.py:\n\n\nurlpatterns = [\n    url('/', schema_view),\n    ...\n]\n\n\n\nYou can also serve different schemas to different users, depending on the\npermissions they have available. This approach can be used to ensure that\nunauthenticated requests are presented with a different schema to\nauthenticated requests, or to ensure that different parts of the API are\nmade visible to different users depending on their role.\n\n\nIn order to present a schema with endpoints filtered by user permissions,\nyou need to pass the \nrequest\n argument to the \nget_schema()\n method, like so:\n\n\n@api_view()\n@renderer_classes([renderers.CoreJSONRenderer])\ndef schema_view(request):\n    generator = schemas.SchemaGenerator(title='Bookings API')\n    return response.Response(generator.get_schema(request=request))\n\n\n\nExplicit schema definition\n\n\nAn alternative to the auto-generated approach is to specify the API schema\nexplicitly, by declaring a \nDocument\n object in your codebase. Doing so is a\nlittle more work, but ensures that you have full control over the schema\nrepresentation.\n\n\nimport coreapi\nfrom rest_framework.decorators import api_view, renderer_classes\nfrom rest_framework import renderers, response\n\nschema = coreapi.Document(\n    title='Bookings API',\n    content={\n        ...\n    }\n)\n\n@api_view()\n@renderer_classes([renderers.CoreJSONRenderer])\ndef schema_view(request):\n    return response.Response(schema)\n\n\n\nStatic schema file\n\n\nA final option is to write your API schema as a static file, using one\nof the available formats, such as Core JSON or Open API.\n\n\nYou could then either:\n\n\n\n\nWrite a schema definition as a static file, and \nserve the static file directly\n.\n\n\nWrite a schema definition that is loaded using \nCore API\n, and then\n  rendered to one of many available formats, depending on the client request.\n\n\n\n\n\n\nAlternate schema formats\n\n\nIn order to support an alternate schema format, you need to implement a custom renderer\nclass that handles converting a \nDocument\n instance into a bytestring representation.\n\n\nIf there is a Core API codec package that supports encoding into the format you\nwant to use then implementing the renderer class can be done by using the codec.\n\n\nExample\n\n\nFor example, the \nopenapi_codec\n package provides support for encoding or decoding\nto the Open API (\"Swagger\") format:\n\n\nfrom rest_framework import renderers\nfrom openapi_codec import OpenAPICodec\n\nclass SwaggerRenderer(renderers.BaseRenderer):\n    media_type = 'application/openapi+json;version=2.0'\n    format = 'swagger'\n\n    def render(self, data, media_type=None, renderer_context=None):\n        codec = OpenAPICodec()\n        return OpenAPICodec.dump(data)\n\n\n\n\n\nAPI Reference\n\n\nSchemaGenerator\n\n\nA class that deals with introspecting your API views, which can be used to\ngenerate a schema.\n\n\nTypically you'll instantiate \nSchemaGenerator\n with a single argument, like so:\n\n\ngenerator = SchemaGenerator(title='Stock Prices API')\n\n\n\nArguments:\n\n\n\n\ntitle\n - The name of the API. \nrequired\n\n\npatterns\n - A list of URLs to inspect when generating the schema. Defaults to the project's URL conf.\n\n\nurlconf\n - A URL conf module name to use when generating the schema. Defaults to \nsettings.ROOT_URLCONF\n.\n\n\n\n\nget_schema()\n\n\nReturns a \ncoreapi.Document\n instance that represents the API schema.\n\n\n@api_view\n@renderer_classes([renderers.CoreJSONRenderer])\ndef schema_view(request):\n    generator = schemas.SchemaGenerator(title='Bookings API')\n    return Response(generator.get_schema())\n\n\n\nArguments:\n\n\n\n\nrequest\n - The incoming request. Optionally used if you want to apply per-user permissions to the schema-generation.\n\n\n\n\n\n\nCore API\n\n\nThis documentation gives a brief overview of the components within the \ncoreapi\n\npackage that are used to represent an API schema.\n\n\nNote that these classes are imported from the \ncoreapi\n package, rather than\nfrom the \nrest_framework\n package.\n\n\nDocument\n\n\nRepresents a container for the API schema.\n\n\ntitle\n\n\nA name for the API.\n\n\nurl\n\n\nA canonical URL for the API.\n\n\ncontent\n\n\nA dictionary, containing the \nLink\n objects that the schema contains.\n\n\nIn order to provide more structure to the schema, the \ncontent\n dictionary\nmay be nested, typically to a second level. For example:\n\n\ncontent={\n    \"bookings\": {\n        \"list\": Link(...),\n        \"create\": Link(...),\n        ...\n    },\n    \"venues\": {\n        \"list\": Link(...),\n        ...\n    },\n    ...\n}\n\n\n\nLink\n\n\nRepresents an individual API endpoint.\n\n\nurl\n\n\nThe URL of the endpoint. May be a URI template, such as \n/users/{username}/\n.\n\n\naction\n\n\nThe HTTP method associated with the endpoint. Note that URLs that support\nmore than one HTTP method, should correspond to a single \nLink\n for each.\n\n\nfields\n\n\nA list of \nField\n instances, describing the available parameters on the input.\n\n\ndescription\n\n\nA short description of the meaning and intended usage of the endpoint.\n\n\nField\n\n\nRepresents a single input parameter on a given API endpoint.\n\n\nname\n\n\nA descriptive name for the input.\n\n\nrequired\n\n\nA boolean, indicated if the client is required to included a value, or if\nthe parameter can be omitted.\n\n\nlocation\n\n\nDetermines how the information is encoded into the request. Should be one of\nthe following strings:\n\n\n\"path\"\n\n\nIncluded in a templated URI. For example a \nurl\n value of \n/products/{product_code}/\n could be used together with a \n\"path\"\n field, to handle API inputs in a URL path such as \n/products/slim-fit-jeans/\n.\n\n\nThese fields will normally correspond with \nnamed arguments in the project URL conf\n.\n\n\n\"query\"\n\n\nIncluded as a URL query parameter. For example \n?search=sale\n. Typically for \nGET\n requests.\n\n\nThese fields will normally correspond with pagination and filtering controls on a view.\n\n\n\"form\"\n\n\nIncluded in the request body, as a single item of a JSON object or HTML form. For example \n{\"colour\": \"blue\", ...}\n. Typically for \nPOST\n, \nPUT\n and \nPATCH\n requests. Multiple \n\"form\"\n fields may be included on a single link.\n\n\nThese fields will normally correspond with serializer fields on a view.\n\n\n\"body\"\n\n\nIncluded as the complete request body. Typically for \nPOST\n, \nPUT\n and \nPATCH\n requests. No more than one \n\"body\"\n field may exist on a link. May not be used together with \n\"form\"\n fields.\n\n\nThese fields will normally correspond with views that use \nListSerializer\n to validate the request input, or with file upload views.\n\n\nencoding\n\n\n\"application/json\"\n\n\nJSON encoded request content. Corresponds to views using \nJSONParser\n.\nValid only if either one or more \nlocation=\"form\"\n fields, or a single\n\nlocation=\"body\"\n field is included on the \nLink\n.\n\n\n\"multipart/form-data\"\n\n\nMultipart encoded request content. Corresponds to views using \nMultiPartParser\n.\nValid only if one or more \nlocation=\"form\"\n fields is included on the \nLink\n.\n\n\n\"application/x-www-form-urlencoded\"\n\n\nURL encoded request content. Corresponds to views using \nFormParser\n. Valid\nonly if one or more \nlocation=\"form\"\n fields is included on the \nLink\n.\n\n\n\"application/octet-stream\"\n\n\nBinary upload request content. Corresponds to views using \nFileUploadParser\n.\nValid only if a \nlocation=\"body\"\n field is included on the \nLink\n.\n\n\ndescription\n\n\nA short description of the meaning and intended usage of the input field.", 
             "title": "Schemas"
         }, 
         {
@@ -3017,12 +3017,12 @@
         }, 
         {
             "location": "/api-guide/schemas/#using-schemagenerator", 
-            "text": "The most common way to add a schema to your API is to use the  SchemaGenerator \nclass to auto-generate the  Document  instance, and to return that from a view.  This option gives you the flexibility of setting up the schema endpoint\nwith whatever behavior you want. For example, you can apply different\npermission, throttling or authentication policies to the schema endpoint.  Here's an example of using  SchemaGenerator  together with a view to\nreturn the schema.  views.py:  from rest_framework.decorators import api_view, renderer_classes\nfrom rest_framework import renderers, schemas\n\ngenerator = schemas.SchemaGenerator(title='Bookings API')\n\n@api_view()\n@renderer_classes([renderers.CoreJSONRenderer])\ndef schema_view(request):\n    return generator.get_schema()  urls.py:  urlpatterns = [\n    url('/', schema_view),\n    ...\n]  You can also serve different schemas to different users, depending on the\npermissions they have available. This approach can be used to ensure that\nunauthenticated requests are presented with a different schema to\nauthenticated requests, or to ensure that different parts of the API are\nmade visible to different users depending on their role.  In order to present a schema with endpoints filtered by user permissions,\nyou need to pass the  request  argument to the  get_schema()  method, like so:  @api_view()\n@renderer_classes([renderers.CoreJSONRenderer])\ndef schema_view(request):\n    return generator.get_schema(request=request)", 
+            "text": "The most common way to add a schema to your API is to use the  SchemaGenerator \nclass to auto-generate the  Document  instance, and to return that from a view.  This option gives you the flexibility of setting up the schema endpoint\nwith whatever behavior you want. For example, you can apply different\npermission, throttling or authentication policies to the schema endpoint.  Here's an example of using  SchemaGenerator  together with a view to\nreturn the schema.  views.py:  from rest_framework.decorators import api_view, renderer_classes\nfrom rest_framework import renderers, response, schemas\n\n\n@api_view()\n@renderer_classes([renderers.CoreJSONRenderer])\ndef schema_view(request):\n    generator = schemas.SchemaGenerator(title='Bookings API')\n    return response.Response(generator.get_schema())  urls.py:  urlpatterns = [\n    url('/', schema_view),\n    ...\n]  You can also serve different schemas to different users, depending on the\npermissions they have available. This approach can be used to ensure that\nunauthenticated requests are presented with a different schema to\nauthenticated requests, or to ensure that different parts of the API are\nmade visible to different users depending on their role.  In order to present a schema with endpoints filtered by user permissions,\nyou need to pass the  request  argument to the  get_schema()  method, like so:  @api_view()\n@renderer_classes([renderers.CoreJSONRenderer])\ndef schema_view(request):\n    generator = schemas.SchemaGenerator(title='Bookings API')\n    return response.Response(generator.get_schema(request=request))", 
             "title": "Using SchemaGenerator"
         }, 
         {
             "location": "/api-guide/schemas/#explicit-schema-definition", 
-            "text": "An alternative to the auto-generated approach is to specify the API schema\nexplicitly, by declaring a  Document  object in your codebase. Doing so is a\nlittle more work, but ensures that you have full control over the schema\nrepresentation.  import coreapi\nfrom rest_framework.decorators import api_view, renderer_classes\nfrom rest_framework import renderers\n\nschema = coreapi.Document(\n    title='Bookings API',\n    content={\n        ...\n    }\n)\n\n@api_view()\n@renderer_classes([renderers.CoreJSONRenderer])\ndef schema_view(request):\n    return schema", 
+            "text": "An alternative to the auto-generated approach is to specify the API schema\nexplicitly, by declaring a  Document  object in your codebase. Doing so is a\nlittle more work, but ensures that you have full control over the schema\nrepresentation.  import coreapi\nfrom rest_framework.decorators import api_view, renderer_classes\nfrom rest_framework import renderers, response\n\nschema = coreapi.Document(\n    title='Bookings API',\n    content={\n        ...\n    }\n)\n\n@api_view()\n@renderer_classes([renderers.CoreJSONRenderer])\ndef schema_view(request):\n    return response.Response(schema)", 
             "title": "Explicit schema definition"
         }, 
         {
@@ -3052,7 +3052,7 @@
         }, 
         {
             "location": "/api-guide/schemas/#get_schema", 
-            "text": "Returns a  coreapi.Document  instance that represents the API schema.  @api_view\n@renderer_classes([renderers.CoreJSONRenderer])\ndef schema_view(request):\n    return generator.get_schema()  Arguments:   request  - The incoming request. Optionally used if you want to apply per-user permissions to the schema-generation.", 
+            "text": "Returns a  coreapi.Document  instance that represents the API schema.  @api_view\n@renderer_classes([renderers.CoreJSONRenderer])\ndef schema_view(request):\n    generator = schemas.SchemaGenerator(title='Bookings API')\n    return Response(generator.get_schema())  Arguments:   request  - The incoming request. Optionally used if you want to apply per-user permissions to the schema-generation.", 
             "title": "get_schema()"
         }, 
         {
@@ -3427,7 +3427,7 @@
         }, 
         {
             "location": "/api-guide/settings/", 
-            "text": "Settings\n\n\n\n\nNamespaces are one honking great idea - let's do more of those!\n\n\n \nThe Zen of Python\n\n\n\n\nConfiguration for REST framework is all namespaced inside a single Django setting, named \nREST_FRAMEWORK\n.\n\n\nFor example your project's \nsettings.py\n file might include something like this:\n\n\nREST_FRAMEWORK = {\n    'DEFAULT_RENDERER_CLASSES': (\n        'rest_framework.renderers.JSONRenderer',\n    ),\n    'DEFAULT_PARSER_CLASSES': (\n        'rest_framework.parsers.JSONParser',\n    )\n}\n\n\n\nAccessing settings\n\n\nIf you need to access the values of REST framework's API settings in your project,\nyou should use the \napi_settings\n object.  For example.\n\n\nfrom rest_framework.settings import api_settings\n\nprint api_settings.DEFAULT_AUTHENTICATION_CLASSES\n\n\n\nThe \napi_settings\n object will check for any user-defined settings, and otherwise fall back to the default values.  Any setting that uses string import paths to refer to a class will automatically import and return the referenced class, instead of the string literal.\n\n\n\n\nAPI Reference\n\n\nAPI policy settings\n\n\nThe following settings control the basic API policies, and are applied to every \nAPIView\n class-based view, or \n@api_view\n function based view.\n\n\nDEFAULT_RENDERER_CLASSES\n\n\nA list or tuple of renderer classes, that determines the default set of renderers that may be used when returning a \nResponse\n object.\n\n\nDefault:\n\n\n(\n    'rest_framework.renderers.JSONRenderer',\n    'rest_framework.renderers.BrowsableAPIRenderer',\n)\n\n\n\nDEFAULT_PARSER_CLASSES\n\n\nA list or tuple of parser classes, that determines the default set of parsers used when accessing the \nrequest.data\n property.\n\n\nDefault:\n\n\n(\n    'rest_framework.parsers.JSONParser',\n    'rest_framework.parsers.FormParser',\n    'rest_framework.parsers.MultiPartParser'\n)\n\n\n\nDEFAULT_AUTHENTICATION_CLASSES\n\n\nA list or tuple of authentication classes, that determines the default set of authenticators used when accessing the \nrequest.user\n or \nrequest.auth\n properties.\n\n\nDefault:\n\n\n(\n    'rest_framework.authentication.SessionAuthentication',\n    'rest_framework.authentication.BasicAuthentication'\n)\n\n\n\nDEFAULT_PERMISSION_CLASSES\n\n\nA list or tuple of permission classes, that determines the default set of permissions checked at the start of a view. Permission must be granted by every class in the list.\n\n\nDefault:\n\n\n(\n    'rest_framework.permissions.AllowAny',\n)\n\n\n\nDEFAULT_THROTTLE_CLASSES\n\n\nA list or tuple of throttle classes, that determines the default set of throttles checked at the start of a view.\n\n\nDefault: \n()\n\n\nDEFAULT_CONTENT_NEGOTIATION_CLASS\n\n\nA content negotiation class, that determines how a renderer is selected for the response, given an incoming request.\n\n\nDefault: \n'rest_framework.negotiation.DefaultContentNegotiation'\n\n\n\n\nGeneric view settings\n\n\nThe following settings control the behavior of the generic class-based views.\n\n\nDEFAULT_PAGINATION_SERIALIZER_CLASS\n\n\n\n\nThis setting has been removed.\n\n\nThe pagination API does not use serializers to determine the output format, and\nyou'll need to instead override the `get_paginated_response method on a\npagination class in order to specify how the output format is controlled.\n\n\n\n\nDEFAULT_FILTER_BACKENDS\n\n\nA list of filter backend classes that should be used for generic filtering.\nIf set to \nNone\n then generic filtering is disabled.\n\n\nPAGINATE_BY\n\n\n\n\nThis setting has been removed.\n\n\nSee the pagination documentation for further guidance on \nsetting the pagination style\n.\n\n\n\n\nPAGE_SIZE\n\n\nThe default page size to use for pagination.  If set to \nNone\n, pagination is disabled by default.\n\n\nDefault: \nNone\n\n\nPAGINATE_BY_PARAM\n\n\n\n\nThis setting has been removed.\n\n\nSee the pagination documentation for further guidance on \nsetting the pagination style\n.\n\n\n\n\nMAX_PAGINATE_BY\n\n\n\n\nThis setting is pending deprecation.\n\n\nSee the pagination documentation for further guidance on \nsetting the pagination style\n.\n\n\n\n\nSEARCH_PARAM\n\n\nThe name of a query parameter, which can be used to specify the search term used by \nSearchFilter\n.\n\n\nDefault: \nsearch\n\n\nORDERING_PARAM\n\n\nThe name of a query parameter, which can be used to specify the ordering of results returned by \nOrderingFilter\n.\n\n\nDefault: \nordering\n\n\n\n\nVersioning settings\n\n\nDEFAULT_VERSION\n\n\nThe value that should be used for \nrequest.version\n when no versioning information is present.\n\n\nDefault: \nNone\n\n\nALLOWED_VERSIONS\n\n\nIf set, this value will restrict the set of versions that may be returned by the versioning scheme, and will raise an error if the provided version if not in this set.\n\n\nDefault: \nNone\n\n\nVERSION_PARAMETER\n\n\nThe string that should used for any versioning parameters, such as in the media type or URL query parameters.\n\n\nDefault: \n'version'\n\n\n\n\nAuthentication settings\n\n\nThe following settings control the behavior of unauthenticated requests.\n\n\nUNAUTHENTICATED_USER\n\n\nThe class that should be used to initialize \nrequest.user\n for unauthenticated requests.\n\n\nDefault: \ndjango.contrib.auth.models.AnonymousUser\n\n\nUNAUTHENTICATED_TOKEN\n\n\nThe class that should be used to initialize \nrequest.auth\n for unauthenticated requests.\n\n\nDefault: \nNone\n\n\n\n\nTest settings\n\n\nThe following settings control the behavior of APIRequestFactory and APIClient\n\n\nTEST_REQUEST_DEFAULT_FORMAT\n\n\nThe default format that should be used when making test requests.\n\n\nThis should match up with the format of one of the renderer classes in the \nTEST_REQUEST_RENDERER_CLASSES\n setting.\n\n\nDefault: \n'multipart'\n\n\nTEST_REQUEST_RENDERER_CLASSES\n\n\nThe renderer classes that are supported when building test requests.\n\n\nThe format of any of these renderer classes may be used when constructing a test request, for example: \nclient.post('/users', {'username': 'jamie'}, format='json')\n\n\nDefault:\n\n\n(\n    'rest_framework.renderers.MultiPartRenderer',\n    'rest_framework.renderers.JSONRenderer'\n)\n\n\n\n\n\nContent type controls\n\n\nURL_FORMAT_OVERRIDE\n\n\nThe name of a URL parameter that may be used to override the default content negotiation \nAccept\n header behavior, by using a \nformat=\u2026\n query parameter in the request URL.\n\n\nFor example: \nhttp://example.com/organizations/?format=csv\n\n\nIf the value of this setting is \nNone\n then URL format overrides will be disabled.\n\n\nDefault: \n'format'\n\n\nFORMAT_SUFFIX_KWARG\n\n\nThe name of a parameter in the URL conf that may be used to provide a format suffix. This setting is applied when using \nformat_suffix_patterns\n to include suffixed URL patterns.\n\n\nFor example: \nhttp://example.com/organizations.csv/\n\n\nDefault: \n'format'\n\n\n\n\nDate and time formatting\n\n\nThe following settings are used to control how date and time representations may be parsed and rendered.\n\n\nDATETIME_FORMAT\n\n\nA format string that should be used by default for rendering the output of \nDateTimeField\n serializer fields.  If \nNone\n, then \nDateTimeField\n serializer fields will return Python \ndatetime\n objects, and the datetime encoding will be determined by the renderer.\n\n\nMay be any of \nNone\n, \n'iso-8601'\n or a Python \nstrftime format\n string.\n\n\nDefault: \n'iso-8601'\n\n\nDATETIME_INPUT_FORMATS\n\n\nA list of format strings that should be used by default for parsing inputs to \nDateTimeField\n serializer fields.\n\n\nMay be a list including the string \n'iso-8601'\n or Python \nstrftime format\n strings.\n\n\nDefault: \n['iso-8601']\n\n\nDATE_FORMAT\n\n\nA format string that should be used by default for rendering the output of \nDateField\n serializer fields.  If \nNone\n, then \nDateField\n serializer fields will return Python \ndate\n objects, and the date encoding will be determined by the renderer.\n\n\nMay be any of \nNone\n, \n'iso-8601'\n or a Python \nstrftime format\n string.\n\n\nDefault: \n'iso-8601'\n\n\nDATE_INPUT_FORMATS\n\n\nA list of format strings that should be used by default for parsing inputs to \nDateField\n serializer fields.\n\n\nMay be a list including the string \n'iso-8601'\n or Python \nstrftime format\n strings.\n\n\nDefault: \n['iso-8601']\n\n\nTIME_FORMAT\n\n\nA format string that should be used by default for rendering the output of \nTimeField\n serializer fields.  If \nNone\n, then \nTimeField\n serializer fields will return Python \ntime\n objects, and the time encoding will be determined by the renderer.\n\n\nMay be any of \nNone\n, \n'iso-8601'\n or a Python \nstrftime format\n string.\n\n\nDefault: \n'iso-8601'\n\n\nTIME_INPUT_FORMATS\n\n\nA list of format strings that should be used by default for parsing inputs to \nTimeField\n serializer fields.\n\n\nMay be a list including the string \n'iso-8601'\n or Python \nstrftime format\n strings.\n\n\nDefault: \n['iso-8601']\n\n\n\n\nEncodings\n\n\nUNICODE_JSON\n\n\nWhen set to \nTrue\n, JSON responses will allow unicode characters in responses. For example:\n\n\n{\"unicode black star\":\"\u2605\"}\n\n\n\nWhen set to \nFalse\n, JSON responses will escape non-ascii characters, like so:\n\n\n{\"unicode black star\":\"\\u2605\"}\n\n\n\nBoth styles conform to \nRFC 4627\n, and are syntactically valid JSON. The unicode style is preferred as being more user-friendly when inspecting API responses.\n\n\nDefault: \nTrue\n\n\nCOMPACT_JSON\n\n\nWhen set to \nTrue\n, JSON responses will return compact representations, with no spacing after \n':'\n and \n','\n characters. For example:\n\n\n{\"is_admin\":false,\"email\":\"jane@example\"}\n\n\n\nWhen set to \nFalse\n, JSON responses will return slightly more verbose representations, like so:\n\n\n{\"is_admin\": false, \"email\": \"jane@example\"}\n\n\n\nThe default style is to return minified responses, in line with \nHeroku's API design guidelines\n.\n\n\nDefault: \nTrue\n\n\nCOERCE_DECIMAL_TO_STRING\n\n\nWhen returning decimal objects in API representations that do not support a native decimal type, it is normally best to return the value as a string. This avoids the loss of precision that occurs with binary floating point implementations.\n\n\nWhen set to \nTrue\n, the serializer \nDecimalField\n class will return strings instead of \nDecimal\n objects. When set to \nFalse\n, serializers will return \nDecimal\n objects, which the default JSON encoder will return as floats.\n\n\nDefault: \nTrue\n\n\n\n\nView names and descriptions\n\n\nThe following settings are used to generate the view names and descriptions, as used in responses to \nOPTIONS\n requests, and as used in the browsable API.\n\n\nVIEW_NAME_FUNCTION\n\n\nA string representing the function that should be used when generating view names.\n\n\nThis should be a function with the following signature:\n\n\nview_name(cls, suffix=None)\n\n\n\n\n\ncls\n: The view class.  Typically the name function would inspect the name of the class when generating a descriptive name, by accessing \ncls.__name__\n.\n\n\nsuffix\n: The optional suffix used when differentiating individual views in a viewset.\n\n\n\n\nDefault: \n'rest_framework.views.get_view_name'\n\n\nVIEW_DESCRIPTION_FUNCTION\n\n\nA string representing the function that should be used when generating view descriptions.\n\n\nThis setting can be changed to support markup styles other than the default markdown.  For example, you can use it to support \nrst\n markup in your view docstrings being output in the browsable API.\n\n\nThis should be a function with the following signature:\n\n\nview_description(cls, html=False)\n\n\n\n\n\ncls\n: The view class.  Typically the description function would inspect the docstring of the class when generating a description, by accessing \ncls.__doc__\n\n\nhtml\n: A boolean indicating if HTML output is required.  \nTrue\n when used in the browsable API, and \nFalse\n when used in generating \nOPTIONS\n responses.\n\n\n\n\nDefault: \n'rest_framework.views.get_view_description'\n\n\n\n\nMiscellaneous settings\n\n\nEXCEPTION_HANDLER\n\n\nA string representing the function that should be used when returning a response for any given exception.  If the function returns \nNone\n, a 500 error will be raised.\n\n\nThis setting can be changed to support error responses other than the default \n{\"detail\": \"Failure...\"}\n responses.  For example, you can use it to provide API responses like \n{\"errors\": [{\"message\": \"Failure...\", \"code\": \"\"} ...]}\n.\n\n\nThis should be a function with the following signature:\n\n\nexception_handler(exc, context)\n\n\n\n\n\nexc\n: The exception.\n\n\n\n\nDefault: \n'rest_framework.views.exception_handler'\n\n\nNON_FIELD_ERRORS_KEY\n\n\nA string representing the key that should be used for serializer errors that do not refer to a specific field, but are instead general errors.\n\n\nDefault: \n'non_field_errors'\n\n\nURL_FIELD_NAME\n\n\nA string representing the key that should be used for the URL fields generated by \nHyperlinkedModelSerializer\n.\n\n\nDefault: \n'url'\n\n\nNUM_PROXIES\n\n\nAn integer of 0 or more, that may be used to specify the number of application proxies that the API runs behind.  This allows throttling to more accurately identify client IP addresses.  If set to \nNone\n then less strict IP matching will be used by the throttle classes.\n\n\nDefault: \nNone", 
+            "text": "Settings\n\n\n\n\nNamespaces are one honking great idea - let's do more of those!\n\n\n \nThe Zen of Python\n\n\n\n\nConfiguration for REST framework is all namespaced inside a single Django setting, named \nREST_FRAMEWORK\n.\n\n\nFor example your project's \nsettings.py\n file might include something like this:\n\n\nREST_FRAMEWORK = {\n    'DEFAULT_RENDERER_CLASSES': (\n        'rest_framework.renderers.JSONRenderer',\n    ),\n    'DEFAULT_PARSER_CLASSES': (\n        'rest_framework.parsers.JSONParser',\n    )\n}\n\n\n\nAccessing settings\n\n\nIf you need to access the values of REST framework's API settings in your project,\nyou should use the \napi_settings\n object.  For example.\n\n\nfrom rest_framework.settings import api_settings\n\nprint api_settings.DEFAULT_AUTHENTICATION_CLASSES\n\n\n\nThe \napi_settings\n object will check for any user-defined settings, and otherwise fall back to the default values.  Any setting that uses string import paths to refer to a class will automatically import and return the referenced class, instead of the string literal.\n\n\n\n\nAPI Reference\n\n\nAPI policy settings\n\n\nThe following settings control the basic API policies, and are applied to every \nAPIView\n class-based view, or \n@api_view\n function based view.\n\n\nDEFAULT_RENDERER_CLASSES\n\n\nA list or tuple of renderer classes, that determines the default set of renderers that may be used when returning a \nResponse\n object.\n\n\nDefault:\n\n\n(\n    'rest_framework.renderers.JSONRenderer',\n    'rest_framework.renderers.BrowsableAPIRenderer',\n)\n\n\n\nDEFAULT_PARSER_CLASSES\n\n\nA list or tuple of parser classes, that determines the default set of parsers used when accessing the \nrequest.data\n property.\n\n\nDefault:\n\n\n(\n    'rest_framework.parsers.JSONParser',\n    'rest_framework.parsers.FormParser',\n    'rest_framework.parsers.MultiPartParser'\n)\n\n\n\nDEFAULT_AUTHENTICATION_CLASSES\n\n\nA list or tuple of authentication classes, that determines the default set of authenticators used when accessing the \nrequest.user\n or \nrequest.auth\n properties.\n\n\nDefault:\n\n\n(\n    'rest_framework.authentication.SessionAuthentication',\n    'rest_framework.authentication.BasicAuthentication'\n)\n\n\n\nDEFAULT_PERMISSION_CLASSES\n\n\nA list or tuple of permission classes, that determines the default set of permissions checked at the start of a view. Permission must be granted by every class in the list.\n\n\nDefault:\n\n\n(\n    'rest_framework.permissions.AllowAny',\n)\n\n\n\nDEFAULT_THROTTLE_CLASSES\n\n\nA list or tuple of throttle classes, that determines the default set of throttles checked at the start of a view.\n\n\nDefault: \n()\n\n\nDEFAULT_CONTENT_NEGOTIATION_CLASS\n\n\nA content negotiation class, that determines how a renderer is selected for the response, given an incoming request.\n\n\nDefault: \n'rest_framework.negotiation.DefaultContentNegotiation'\n\n\n\n\nGeneric view settings\n\n\nThe following settings control the behavior of the generic class-based views.\n\n\nDEFAULT_PAGINATION_SERIALIZER_CLASS\n\n\n\n\nThis setting has been removed.\n\n\nThe pagination API does not use serializers to determine the output format, and\nyou'll need to instead override the `get_paginated_response method on a\npagination class in order to specify how the output format is controlled.\n\n\n\n\nDEFAULT_FILTER_BACKENDS\n\n\nA list of filter backend classes that should be used for generic filtering.\nIf set to \nNone\n then generic filtering is disabled.\n\n\nPAGINATE_BY\n\n\n\n\nThis setting has been removed.\n\n\nSee the pagination documentation for further guidance on \nsetting the pagination style\n.\n\n\n\n\nPAGE_SIZE\n\n\nThe default page size to use for pagination.  If set to \nNone\n, pagination is disabled by default.\n\n\nDefault: \nNone\n\n\nPAGINATE_BY_PARAM\n\n\n\n\nThis setting has been removed.\n\n\nSee the pagination documentation for further guidance on \nsetting the pagination style\n.\n\n\n\n\nMAX_PAGINATE_BY\n\n\n\n\nThis setting is pending deprecation.\n\n\nSee the pagination documentation for further guidance on \nsetting the pagination style\n.\n\n\n\n\nSEARCH_PARAM\n\n\nThe name of a query parameter, which can be used to specify the search term used by \nSearchFilter\n.\n\n\nDefault: \nsearch\n\n\nORDERING_PARAM\n\n\nThe name of a query parameter, which can be used to specify the ordering of results returned by \nOrderingFilter\n.\n\n\nDefault: \nordering\n\n\n\n\nVersioning settings\n\n\nDEFAULT_VERSION\n\n\nThe value that should be used for \nrequest.version\n when no versioning information is present.\n\n\nDefault: \nNone\n\n\nALLOWED_VERSIONS\n\n\nIf set, this value will restrict the set of versions that may be returned by the versioning scheme, and will raise an error if the provided version if not in this set.\n\n\nDefault: \nNone\n\n\nVERSION_PARAM\n\n\nThe string that should used for any versioning parameters, such as in the media type or URL query parameters.\n\n\nDefault: \n'version'\n\n\n\n\nAuthentication settings\n\n\nThe following settings control the behavior of unauthenticated requests.\n\n\nUNAUTHENTICATED_USER\n\n\nThe class that should be used to initialize \nrequest.user\n for unauthenticated requests.\n\n\nDefault: \ndjango.contrib.auth.models.AnonymousUser\n\n\nUNAUTHENTICATED_TOKEN\n\n\nThe class that should be used to initialize \nrequest.auth\n for unauthenticated requests.\n\n\nDefault: \nNone\n\n\n\n\nTest settings\n\n\nThe following settings control the behavior of APIRequestFactory and APIClient\n\n\nTEST_REQUEST_DEFAULT_FORMAT\n\n\nThe default format that should be used when making test requests.\n\n\nThis should match up with the format of one of the renderer classes in the \nTEST_REQUEST_RENDERER_CLASSES\n setting.\n\n\nDefault: \n'multipart'\n\n\nTEST_REQUEST_RENDERER_CLASSES\n\n\nThe renderer classes that are supported when building test requests.\n\n\nThe format of any of these renderer classes may be used when constructing a test request, for example: \nclient.post('/users', {'username': 'jamie'}, format='json')\n\n\nDefault:\n\n\n(\n    'rest_framework.renderers.MultiPartRenderer',\n    'rest_framework.renderers.JSONRenderer'\n)\n\n\n\n\n\nContent type controls\n\n\nURL_FORMAT_OVERRIDE\n\n\nThe name of a URL parameter that may be used to override the default content negotiation \nAccept\n header behavior, by using a \nformat=\u2026\n query parameter in the request URL.\n\n\nFor example: \nhttp://example.com/organizations/?format=csv\n\n\nIf the value of this setting is \nNone\n then URL format overrides will be disabled.\n\n\nDefault: \n'format'\n\n\nFORMAT_SUFFIX_KWARG\n\n\nThe name of a parameter in the URL conf that may be used to provide a format suffix. This setting is applied when using \nformat_suffix_patterns\n to include suffixed URL patterns.\n\n\nFor example: \nhttp://example.com/organizations.csv/\n\n\nDefault: \n'format'\n\n\n\n\nDate and time formatting\n\n\nThe following settings are used to control how date and time representations may be parsed and rendered.\n\n\nDATETIME_FORMAT\n\n\nA format string that should be used by default for rendering the output of \nDateTimeField\n serializer fields.  If \nNone\n, then \nDateTimeField\n serializer fields will return Python \ndatetime\n objects, and the datetime encoding will be determined by the renderer.\n\n\nMay be any of \nNone\n, \n'iso-8601'\n or a Python \nstrftime format\n string.\n\n\nDefault: \n'iso-8601'\n\n\nDATETIME_INPUT_FORMATS\n\n\nA list of format strings that should be used by default for parsing inputs to \nDateTimeField\n serializer fields.\n\n\nMay be a list including the string \n'iso-8601'\n or Python \nstrftime format\n strings.\n\n\nDefault: \n['iso-8601']\n\n\nDATE_FORMAT\n\n\nA format string that should be used by default for rendering the output of \nDateField\n serializer fields.  If \nNone\n, then \nDateField\n serializer fields will return Python \ndate\n objects, and the date encoding will be determined by the renderer.\n\n\nMay be any of \nNone\n, \n'iso-8601'\n or a Python \nstrftime format\n string.\n\n\nDefault: \n'iso-8601'\n\n\nDATE_INPUT_FORMATS\n\n\nA list of format strings that should be used by default for parsing inputs to \nDateField\n serializer fields.\n\n\nMay be a list including the string \n'iso-8601'\n or Python \nstrftime format\n strings.\n\n\nDefault: \n['iso-8601']\n\n\nTIME_FORMAT\n\n\nA format string that should be used by default for rendering the output of \nTimeField\n serializer fields.  If \nNone\n, then \nTimeField\n serializer fields will return Python \ntime\n objects, and the time encoding will be determined by the renderer.\n\n\nMay be any of \nNone\n, \n'iso-8601'\n or a Python \nstrftime format\n string.\n\n\nDefault: \n'iso-8601'\n\n\nTIME_INPUT_FORMATS\n\n\nA list of format strings that should be used by default for parsing inputs to \nTimeField\n serializer fields.\n\n\nMay be a list including the string \n'iso-8601'\n or Python \nstrftime format\n strings.\n\n\nDefault: \n['iso-8601']\n\n\n\n\nEncodings\n\n\nUNICODE_JSON\n\n\nWhen set to \nTrue\n, JSON responses will allow unicode characters in responses. For example:\n\n\n{\"unicode black star\":\"\u2605\"}\n\n\n\nWhen set to \nFalse\n, JSON responses will escape non-ascii characters, like so:\n\n\n{\"unicode black star\":\"\\u2605\"}\n\n\n\nBoth styles conform to \nRFC 4627\n, and are syntactically valid JSON. The unicode style is preferred as being more user-friendly when inspecting API responses.\n\n\nDefault: \nTrue\n\n\nCOMPACT_JSON\n\n\nWhen set to \nTrue\n, JSON responses will return compact representations, with no spacing after \n':'\n and \n','\n characters. For example:\n\n\n{\"is_admin\":false,\"email\":\"jane@example\"}\n\n\n\nWhen set to \nFalse\n, JSON responses will return slightly more verbose representations, like so:\n\n\n{\"is_admin\": false, \"email\": \"jane@example\"}\n\n\n\nThe default style is to return minified responses, in line with \nHeroku's API design guidelines\n.\n\n\nDefault: \nTrue\n\n\nCOERCE_DECIMAL_TO_STRING\n\n\nWhen returning decimal objects in API representations that do not support a native decimal type, it is normally best to return the value as a string. This avoids the loss of precision that occurs with binary floating point implementations.\n\n\nWhen set to \nTrue\n, the serializer \nDecimalField\n class will return strings instead of \nDecimal\n objects. When set to \nFalse\n, serializers will return \nDecimal\n objects, which the default JSON encoder will return as floats.\n\n\nDefault: \nTrue\n\n\n\n\nView names and descriptions\n\n\nThe following settings are used to generate the view names and descriptions, as used in responses to \nOPTIONS\n requests, and as used in the browsable API.\n\n\nVIEW_NAME_FUNCTION\n\n\nA string representing the function that should be used when generating view names.\n\n\nThis should be a function with the following signature:\n\n\nview_name(cls, suffix=None)\n\n\n\n\n\ncls\n: The view class.  Typically the name function would inspect the name of the class when generating a descriptive name, by accessing \ncls.__name__\n.\n\n\nsuffix\n: The optional suffix used when differentiating individual views in a viewset.\n\n\n\n\nDefault: \n'rest_framework.views.get_view_name'\n\n\nVIEW_DESCRIPTION_FUNCTION\n\n\nA string representing the function that should be used when generating view descriptions.\n\n\nThis setting can be changed to support markup styles other than the default markdown.  For example, you can use it to support \nrst\n markup in your view docstrings being output in the browsable API.\n\n\nThis should be a function with the following signature:\n\n\nview_description(cls, html=False)\n\n\n\n\n\ncls\n: The view class.  Typically the description function would inspect the docstring of the class when generating a description, by accessing \ncls.__doc__\n\n\nhtml\n: A boolean indicating if HTML output is required.  \nTrue\n when used in the browsable API, and \nFalse\n when used in generating \nOPTIONS\n responses.\n\n\n\n\nDefault: \n'rest_framework.views.get_view_description'\n\n\n\n\nMiscellaneous settings\n\n\nEXCEPTION_HANDLER\n\n\nA string representing the function that should be used when returning a response for any given exception.  If the function returns \nNone\n, a 500 error will be raised.\n\n\nThis setting can be changed to support error responses other than the default \n{\"detail\": \"Failure...\"}\n responses.  For example, you can use it to provide API responses like \n{\"errors\": [{\"message\": \"Failure...\", \"code\": \"\"} ...]}\n.\n\n\nThis should be a function with the following signature:\n\n\nexception_handler(exc, context)\n\n\n\n\n\nexc\n: The exception.\n\n\n\n\nDefault: \n'rest_framework.views.exception_handler'\n\n\nNON_FIELD_ERRORS_KEY\n\n\nA string representing the key that should be used for serializer errors that do not refer to a specific field, but are instead general errors.\n\n\nDefault: \n'non_field_errors'\n\n\nURL_FIELD_NAME\n\n\nA string representing the key that should be used for the URL fields generated by \nHyperlinkedModelSerializer\n.\n\n\nDefault: \n'url'\n\n\nNUM_PROXIES\n\n\nAn integer of 0 or more, that may be used to specify the number of application proxies that the API runs behind.  This allows throttling to more accurately identify client IP addresses.  If set to \nNone\n then less strict IP matching will be used by the throttle classes.\n\n\nDefault: \nNone", 
             "title": "Settings"
         }, 
         {
@@ -3541,9 +3541,9 @@
             "title": "ALLOWED_VERSIONS"
         }, 
         {
-            "location": "/api-guide/settings/#version_parameter", 
+            "location": "/api-guide/settings/#version_param", 
             "text": "The string that should used for any versioning parameters, such as in the media type or URL query parameters.  Default:  'version'", 
-            "title": "VERSION_PARAMETER"
+            "title": "VERSION_PARAM"
         }, 
         {
             "location": "/api-guide/settings/#authentication-settings", 
diff --git a/sitemap.xml b/sitemap.xml
index 661fa2786..3ed041fe1 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -4,7 +4,7 @@
     
     <url>
      <loc>http://www.django-rest-framework.org//</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -13,49 +13,49 @@
         
     <url>
      <loc>http://www.django-rest-framework.org//tutorial/quickstart/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//tutorial/1-serialization/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//tutorial/2-requests-and-responses/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//tutorial/3-class-based-views/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//tutorial/4-authentication-and-permissions/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//tutorial/5-relationships-and-hyperlinked-apis/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//tutorial/6-viewsets-and-routers/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//tutorial/7-schemas-and-client-libraries/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -65,163 +65,163 @@
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/requests/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/responses/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/views/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/generic-views/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/viewsets/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/routers/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/parsers/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/renderers/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/serializers/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/fields/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/relations/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/validators/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/authentication/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/permissions/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/throttling/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/filtering/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/pagination/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/versioning/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/content-negotiation/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/metadata/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/schemas/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/format-suffixes/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/reverse/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/exceptions/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/status-codes/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/testing/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//api-guide/settings/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -231,121 +231,121 @@
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/documenting-your-api/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/api-clients/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/internationalization/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/ajax-csrf-cors/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/html-and-forms/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/browser-enhancements/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/browsable-api/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/rest-hypermedia-hateoas/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/third-party-resources/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/contributing/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/project-management/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/3.0-announcement/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/3.1-announcement/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/3.2-announcement/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/3.3-announcement/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/3.4-announcement/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/kickstarter-announcement/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/mozilla-grant/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/funding/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>http://www.django-rest-framework.org//topics/release-notes/</loc>
-     <lastmod>2016-07-14</lastmod>
+     <lastmod>2016-07-18</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
diff --git a/tutorial/7-schemas-and-client-libraries/index.html b/tutorial/7-schemas-and-client-libraries/index.html
index cfce6c374..25029d717 100644
--- a/tutorial/7-schemas-and-client-libraries/index.html
+++ b/tutorial/7-schemas-and-client-libraries/index.html
@@ -508,7 +508,7 @@ endpoints, in line with how we've set up the permissions on the API.</p>
 </code></pre>
 <p>Some of the API endpoints require named parameters. For example, to get back
 the highlight HTML for a particular snippet we need to provide an id.</p>
-<pre><code>$ coreapi action snippets highlight --param pk 1
+<pre><code>$ coreapi action snippets highlight --param pk=1
 &lt;!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"&gt;
 
 &lt;html&gt;
@@ -545,7 +545,7 @@ Pastebin API "http://127.0.0.1:8000/"&gt;
 </code></pre>
 <p>We're now able to interact with these endpoints. For example, to create a new
 snippet:</p>
-<pre><code>$ coreapi action snippets create --param title "Example" --param code "print('hello, world')"
+<pre><code>$ coreapi action snippets create --param title="Example" --param code="print('hello, world')"
 {
     "url": "http://127.0.0.1:8000/snippets/7/",
     "pk": 7,
@@ -559,7 +559,7 @@ snippet:</p>
 }
 </code></pre>
 <p>And to delete a snippet:</p>
-<pre><code>$ coreapi action snippets destroy --param pk 7
+<pre><code>$ coreapi action snippets destroy --param pk=7
 </code></pre>
 <p>As well as the command line client, developers can also interact with your
 API using client libraries. The Python client library is the first of these