diff options
| author | Tom Christie | 2014-11-28 09:57:02 +0000 | 
|---|---|---|
| committer | Tom Christie | 2014-11-28 09:57:02 +0000 | 
| commit | d4b8e356b952137760bf33750b17895526d6151e (patch) | |
| tree | cb4428b2967582dd8ca50cb1bcd1f7bb95b1fe5f /docs/tutorial | |
| parent | d2d7e1dfde2a62ee8f6d904368dbd6581de278c9 (diff) | |
| parent | 34ca8cd2a5c030d9acc89720876ba9583c1dc988 (diff) | |
| download | django-rest-framework-d4b8e356b952137760bf33750b17895526d6151e.tar.bz2 | |
Merge branch '3.0-docs'
Diffstat (limited to 'docs/tutorial')
| -rw-r--r-- | docs/tutorial/2-requests-and-responses.md | 12 | ||||
| -rw-r--r-- | docs/tutorial/3-class-based-views.md | 4 | 
2 files changed, 8 insertions, 8 deletions
| diff --git a/docs/tutorial/2-requests-and-responses.md b/docs/tutorial/2-requests-and-responses.md index 136b0135..f377c712 100644 --- a/docs/tutorial/2-requests-and-responses.md +++ b/docs/tutorial/2-requests-and-responses.md @@ -5,10 +5,10 @@ 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 @@ -29,7 +29,7 @@ REST framework provides two wrappers you can use to write API 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 @@ -55,7 +55,7 @@ We don't need our `JSONResponse` class in `views.py` anymore, so go ahead and de              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) @@ -80,7 +80,7 @@ Here is the view for an individual snippet, in the `views.py` module.              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) @@ -92,7 +92,7 @@ Here is the view for an individual snippet, in the `views.py` module.  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 diff --git a/docs/tutorial/3-class-based-views.md b/docs/tutorial/3-class-based-views.md index 382f078a..0a9ea3f1 100644 --- a/docs/tutorial/3-class-based-views.md +++ b/docs/tutorial/3-class-based-views.md @@ -24,7 +24,7 @@ We'll start by rewriting the root view as a class based view.  All this involves              return Response(serializer.data)          def post(self, request, format=None): -            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) @@ -49,7 +49,7 @@ So far, so good.  It looks pretty similar to the previous case, but we've got be          def put(self, request, pk, format=None):              snippet = self.get_object(pk) -            serializer = SnippetSerializer(snippet, data=request.DATA) +            serializer = SnippetSerializer(snippet, data=request.data)              if serializer.is_valid():                  serializer.save()                  return Response(serializer.data) | 
