request.DATA, request.FILES -> request.data

docs/api-guide/exceptions.md

@@ -100,7 +100,7 @@ For example, if your API relies on a third party service that may sometimes be u
 
 **Signature:** `ParseError(detail=None)`
 
-Raised if the request contains malformed data when accessing `request.DATA` or `request.FILES`.
+Raised if the request contains malformed data when accessing `request.data`.
 
 By default this exception results in a response with the HTTP status code "400 Bad Request".
 
@@ -140,7 +140,7 @@ By default this exception results in a response with the HTTP status code "405 M
 
 **Signature:** `UnsupportedMediaType(media_type, detail=None)`
 
-Raised if there are no parsers that can handle the content type of the request data when accessing `request.DATA` or `request.FILES`.
+Raised if there are no parsers that can handle the content type of the request data when accessing `request.data`.
 
 By default this exception results in a response with the HTTP status code "415 Unsupported Media Type".
 

docs/api-guide/parsers.md

@@ -12,7 +12,7 @@ REST framework includes a number of built in Parser classes, that allow you to a
 
 ## How the parser is determined
 
-The set of valid parsers for a view is always defined as a list of classes.  When either `request.DATA` or `request.FILES` is accessed, REST framework will examine the `Content-Type` header on the incoming request, and determine which parser to use to parse the request content.
+The set of valid parsers for a view is always defined as a list of classes.  When  `request.data` is accessed, REST framework will examine the `Content-Type` header on the incoming request, and determine which parser to use to parse the request content.
 
 ---
 
@@ -48,7 +48,7 @@ using the `APIView` class based views.
         parser_classes = (YAMLParser,)
 
         def post(self, request, format=None):
-            return Response({'received data': request.DATA})
+            return Response({'received data': request.data})
 
 Or, if you're using the `@api_view` decorator with function based views.
 
@@ -58,7 +58,7 @@ Or, if you're using the `@api_view` decorator with function based views.
         """
         A view that can accept POST requests with YAML content.
         """
-        return Response({'received data': request.DATA})
+        return Response({'received data': request.data})
 
 ---
 
@@ -92,7 +92,7 @@ Requires the `defusedxml` package to be installed.
 
 ## FormParser
 
-Parses HTML form content.  `request.DATA` will be populated with a `QueryDict` of data, `request.FILES` will be populated with an empty `QueryDict` of data.
+Parses HTML form content.  `request.data` will be populated with a `QueryDict` of data.
 
 You will typically want to use both `FormParser` and `MultiPartParser` together in order to fully support HTML form data.
 
@@ -100,7 +100,7 @@ You will typically want to use both `FormParser` and `MultiPartParser` together
 
 ## MultiPartParser
 
-Parses multipart HTML form content, which supports file uploads.  Both `request.DATA` and `request.FILES` will be populated with a `QueryDict`.
+Parses multipart HTML form content, which supports file uploads.  Both `request.data` will be populated with a `QueryDict`.
 
 You will typically want to use both `FormParser` and `MultiPartParser` together in order to fully support HTML form data.
 
@@ -108,7 +108,7 @@ You will typically want to use both `FormParser` and `MultiPartParser` together
 
 ## FileUploadParser
 
-Parses raw file upload content.  The `request.DATA` property will be an empty `QueryDict`, and `request.FILES` will be a dictionary with a single key `'file'` containing the uploaded file.
+Parses raw file upload content.  The `request.data` property will be a dictionary with a single key `'file'` containing the uploaded file.
 
 If the view used with `FileUploadParser` is called with a `filename` URL keyword argument, then that argument will be used as the filename.  If it is called without a `filename` URL keyword argument, then the client must set the filename in the `Content-Disposition` HTTP header.  For example `Content-Disposition: attachment; filename=upload.jpg`.
 
@@ -126,7 +126,7 @@ If the view used with `FileUploadParser` is called with a `filename` URL keyword
         parser_classes = (FileUploadParser,)
 
         def put(self, request, filename, format=None):
-            file_obj = request.FILES['file']
+            file_obj = request.data['file']
             # ...
             # do some staff with uploaded file
             # ...
@@ -139,7 +139,7 @@ If the view used with `FileUploadParser` is called with a `filename` URL keyword
 
 To implement a custom parser, you should override `BaseParser`, set the `.media_type` property, and implement the `.parse(self, stream, media_type, parser_context)` method.
 
-The method should return the data that will be used to populate the `request.DATA` property.
+The method should return the data that will be used to populate the `request.data` property.
 
 The arguments passed to `.parse()` are:
 
@@ -161,7 +161,7 @@ By default this will include the following keys: `view`, `request`, `args`, `kwa
 
 ## Example
 
-The following is an example plaintext parser that will populate the `request.DATA` property with a string representing the body of the request. 
+The following is an example plaintext parser that will populate the `request.data` property with a string representing the body of the request. 
 
     class PlainTextParser(BaseParser):
     """

docs/api-guide/requests.md

@@ -14,26 +14,29 @@ REST framework's `Request` class extends the standard `HttpRequest`, adding supp
 
 REST framework's Request objects provide flexible request parsing that allows you to treat requests with JSON data or other media types in the same way that you would normally deal with form data.
 
-## .DATA
+## .data
 
-`request.DATA` returns the parsed content of the request body.  This is similar to the standard `request.POST` attribute except that:
+`request.data` returns the parsed content of the request body.  This is similar to the standard `request.POST` and `request.FILES` attributes except that:
 
+* It includes all parsed content, including *file and non-file* inputs.
 * It supports parsing the content of HTTP methods other than `POST`, meaning that you can access the content of `PUT` and `PATCH` requests.
 * It supports REST framework's flexible request parsing, rather than just supporting form data.  For example you can handle incoming JSON data in the same way that you handle incoming form data.
 
 For more details see the [parsers documentation].
 
-## .FILES
+## .query_params
 
-`request.FILES` returns any uploaded files that may be present in the content of the request body.  This is the same as the standard `HttpRequest` behavior, except that the same flexible request parsing is used for `request.DATA`.
+`request.query_params` is a more correctly named synonym for `request.GET`.
 
-For more details see the [parsers documentation].
+For clarity inside your code, we recommend using `request.query_params` instead of the Django's standard `request.GET`. Doing so will help keep your codebase more correct and obvious - any HTTP method type may include query parameters, not just `GET` requests.
+
+## .DATA and .FILES
+
+The old-style version 2.x `request.data` and `request.FILES` attributes are still available, but are now pending deprecation in favor of the unified `request.data` attribute.
 
 ## .QUERY_PARAMS
 
-`request.QUERY_PARAMS` is a more correctly named synonym for `request.GET`.
-
-For clarity inside your code, we recommend using `request.QUERY_PARAMS` instead of the usual `request.GET`, as *any* HTTP method type may include query parameters.
+The old-style version 2.x `request.QUERY_PARAMS` attribute is still available, but is now pending deprecation in favor of the more pythonic `request.query_params`.
 
 ## .parsers
 
@@ -43,7 +46,7 @@ You won't typically need to access this property.
 
 ---
 
-**Note:** If a client sends malformed content, then accessing `request.DATA` or `request.FILES` may raise a `ParseError`.  By default REST framework's `APIView` class or `@api_view` decorator will catch the error and return a `400 Bad Request` response.
+**Note:** If a client sends malformed content, then accessing `request.data` may raise a `ParseError`.  By default REST framework's `APIView` class or `@api_view` decorator will catch the error and return a `400 Bad Request` response.
 
 If a client sends a request with a content-type that cannot be parsed then a `UnsupportedMediaType` exception will be raised, which by default will be caught and return a `415 Unsupported Media Type` response.
 

docs/api-guide/settings.md

@@ -51,7 +51,7 @@ Default:
 
 #### DEFAULT_PARSER_CLASSES
 
-A list or tuple of parser classes, that determines the default set of parsers used when accessing the `request.DATA` property.
+A list or tuple of parser classes, that determines the default set of parsers used when accessing the `request.data` property.
 
 Default:
 

docs/api-guide/viewsets.md

@@ -124,7 +124,7 @@ For example:
         @detail_route(methods=['post'])
         def set_password(self, request, pk=None):
             user = self.get_object()
-            serializer = PasswordSerializer(data=request.DATA)
+            serializer = PasswordSerializer(data=request.data)
             if serializer.is_valid():
                 user.set_password(serializer.data['password'])
                 user.save()

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
 

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)

rest_framework/request.py

@@ -310,7 +310,7 @@ class Request(object):
 
     def _load_data_and_files(self):
         """
-        Parses the request content into self.DATA and self.FILES.
+        Parses the request content into `self.data`.
         """
         if not _hasattr(self, '_content_type'):
             self._load_method_and_content_type()