From ed93e13a1c6f792e14176bdaa5e96d0fa2c63a2f Mon Sep 17 00:00:00 2001 From: Tom Christie Date: Mon, 1 Dec 2014 12:20:07 +0000 Subject: Update documentation --- tutorial/2-requests-and-responses/index.html | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 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 e6dc3004..3ef5c326 100644 --- a/tutorial/2-requests-and-responses/index.html +++ b/tutorial/2-requests-and-responses/index.html @@ -164,6 +164,10 @@ Serializer relations +
  • + Validators +
    • +
  • Authentication
    • @@ -263,6 +267,10 @@ 2.4 Announcement +
  • + 3.0 Announcement +
    • +
  • Kickstarter Announcement
    • @@ -390,9 +398,9 @@

    From this point we're going to really start covering the core of REST framework. Let's introduce a couple of essential building blocks.

    Request objects

    -

    REST framework introduces a Request object that extends the regular HttpRequest, and provides more flexible request parsing. The core functionality of the Request object is the request.DATA attribute, which is similar to request.POST, but more useful for working with Web APIs.

    +

    REST framework introduces a Request object that extends the regular HttpRequest, and provides more flexible request parsing. The core functionality of the Request object is the request.data attribute, which is similar to request.POST, but more useful for working with Web APIs.

    request.POST  # Only handles form data.  Only works for 'POST' method.
-request.DATA  # Handles arbitrary data.  Works for 'POST', 'PUT' and 'PATCH' methods.
+request.data  # Handles arbitrary data.  Works for 'POST', 'PUT' and 'PATCH' methods.

    Response objects

    REST framework also introduces a Response object, which is a type of TemplateResponse that takes unrendered content and uses content negotiation to determine the correct content type to return to the client.

    @@ -407,7 +415,7 @@ request.DATA # Handles arbitrary data. Works for 'POST', 'PUT' and 'PATCH' met
  • The APIView class for working with class based views.

    • These wrappers provide a few bits of functionality such as making sure you receive Request instances in your view, and adding context to Response objects so that content negotiation can be performed.

    -

    The wrappers also provide behaviour such as returning 405 Method Not Allowed responses when appropriate, and handling any ParseError exception that occurs when accessing request.DATA with malformed input.

    +

    The wrappers also provide behaviour such as returning 405 Method Not Allowed responses when appropriate, and handling any ParseError exception that occurs when accessing request.data with malformed input.

    Pulling it all together

    Okay, let's go ahead and start using these new components to write a few views.

    We don't need our JSONResponse class in views.py anymore, so go ahead and delete that. Once that's done we can start refactoring our views slightly.

    @@ -429,7 +437,7 @@ def snippet_list(request): return Response(serializer.data) elif request.method == 'POST': - serializer = SnippetSerializer(data=request.DATA) + serializer = SnippetSerializer(data=request.data) if serializer.is_valid(): serializer.save() return Response(serializer.data, status=status.HTTP_201_CREATED) @@ -452,7 +460,7 @@ def snippet_detail(request, pk): return Response(serializer.data) elif request.method == 'PUT': - serializer = SnippetSerializer(snippet, data=request.DATA) + serializer = SnippetSerializer(snippet, data=request.data) if serializer.is_valid(): serializer.save() return Response(serializer.data) @@ -463,7 +471,7 @@ def snippet_detail(request, pk): return Response(status=status.HTTP_204_NO_CONTENT)

    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 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.

    Adding optional format suffixes to our URLs

    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.

    @@ -532,7 +540,7 @@ curl -X POST http://127.0.0.1:8000/snippets/ -d '{"code": "print 456"}' -H "Cont -- cgit v1.2.3