From e628d9eb9b7deac2ecffe23eace5c72709887f8f Mon Sep 17 00:00:00 2001 From: Tom Christie Date: Fri, 6 Mar 2015 12:05:16 +0000 Subject: Update documentation --- tutorial/2-requests-and-responses/index.html | 30 ++++++++++------------------ 1 file changed, 11 insertions(+), 19 deletions(-) (limited to 'tutorial/2-requests-and-responses/index.html') diff --git a/tutorial/2-requests-and-responses/index.html b/tutorial/2-requests-and-responses/index.html index cbc9c596..df43617a 100644 --- a/tutorial/2-requests-and-responses/index.html +++ b/tutorial/2-requests-and-responses/index.html @@ -188,6 +188,10 @@ Pagination +
This should all feel very familiar - it is not a lot different from working with regular Django views.
-Notice that we're no longer explicitly tying our requests or responses to a given content type.  request.data can handle incoming json requests, but it can also handle yaml and other formats.  Similarly we're returning response objects with data, but allowing REST framework to render the response into the correct content type for us.
Notice that we're no longer explicitly tying our requests or responses to a given content type.  request.data can handle incoming json requests, but it can also handle other formats.  Similarly we're returning response objects with data, but allowing REST framework to render the response into the correct content type for us.
To take advantage of the fact that our responses are no longer hardwired to a single content type let's add support for format suffixes to our API endpoints. Using format suffixes gives us URLs that explicitly refer to a given format, and means our API will be able to handle URLs such as http://example.com/api/items/4/.json.
Start by adding a format keyword argument to both of the views, like so.