Merge pull request #293 from tomchristie/request-documentation

Improve documentation for Requests

docs/api-guide/requests.md

@@ -6,63 +6,112 @@
 >
 > — Malcom Tredinnick, [Django developers group][cite]
 
-REST framework's `Request` class extends the standard `HttpRequest`, adding support for parsing multiple content types, allowing browser-based `PUT`, `DELETE` and other methods, and adding flexible per-request authentication.
+REST framework's `Request` class extends the standard `HttpRequest`, adding support for REST framework's flexible request parsing and request authentication.
 
-## .method
-
-`request.method` returns the uppercased string representation of the request's HTTP method.
-
-Browser-based `PUT`, `DELETE` and other requests are supported, and can be made by using a hidden form field named `_method` in a regular `POST` form.
-
-
-
-## .content_type
-
-`request.content`, returns a string object representing the mimetype of the HTTP request's body, if one exists.
+---
 
+# Request parsing
 
+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
 
-`request.DATA` returns the parsed content of the request body.  This is similar to the standard `HttpRequest.POST` attribute except that:
+`request.DATA` returns the parsed content of the request body.  This is similar to the standard `request.POST` attribute except that:
 
-1. It supports parsing the content of HTTP methods other than `POST`, meaning that you can access the content of `PUT` and `PATCH` requests.
-2. It supports parsing multiple content types, rather than just form data.  For example you can handle incoming json data in the same way that you handle incoming form data.
+* 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
 
 `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 that is used for `request.DATA`.
 
-This allows you to support file uploads from multiple content-types.  For example you can write a parser that supports `POST`ing the raw content of a file, instead of using form-encoded file uploads.
+For more details see the [parsers documentation].
 
-## .user
+## .QUERY_PARAMS
 
-`request.user` returns a `django.contrib.auth.models.User` instance. 
+`request.QUERY_PARAMS` is a more correcly named synonym for `request.GET`.
 
-## .auth
-
-`request.auth` returns any additional authentication context that may not be contained in `request.user`.  The exact behavior of `request.auth` depends on what authentication has been set in `request.authentication`.  For many types of authentication this will simply be `None`, but it may also be an object representing a permission scope, an expiry time, or any other information that might be contained in a token-based authentication scheme.
+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.
 
 ## .parsers
 
-`request.parsers` should be set to a list of `Parser` instances that can be used to parse the content of the request body.
+The `APIView` class or `@api_view` decorator will ensure that this property is automatically to a list of `Parser` instances, based on the `parser_classes` set on the view or based on the `DEFAULT_PARSERS` setting.
 
-`request.parsers` may no longer be altered once `request.DATA`, `request.FILES` or `request.POST` have been accessed.
+You won't typically need to access this property.
 
-If you're using the `rest_framework.views.View` class... **[TODO]**
+---
+
+**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.
+
+---
+
+# Authentication
+
+REST framework provides flexbile, per-request authentication, that gives you the abilty to:
+
+* Use different authentication policies for different parts of your API.
+* Support the use of multiple authentication policies.
+* Provide both user and token information associated with the incoming request.
+
+## .user
+
+`request.user` typically returns an instance of `django.contrib.auth.models.User`, although the behavior depends on the authentication policy being used.
+
+If the request is unauthenticated the default value of `request.user` is an instance of `django.contrib.auth.models.AnonymousUser`.
+
+For more details see the [authentication documentation].
+
+## .auth
+
+`request.auth` returns any additional authentication context.  The exact behavior of `request.auth` depends on the authentication policy being used, but it may typically be an instance of the token that the request was authenticated against.
+
+If the request is unauthenticated, or if no additional context is present, the default value of `request.auth` is `None`.
+
+For more details see the [authentication documentation].
+
+## .authenticators
+
+The `APIView` class or `@api_view` decorator will ensure that this property is automatically to a list of `Authentication` instances, based on the `authentication_classes` set on the view or based on the `DEFAULT_AUTHENTICATORS` setting.
+
+You won't typically need to access this property.
+
+---
+
+# Browser enhancments
+
+REST framework supports a few browser enhancments such as broser-based `PUT` and `DELETE` forms.
+
+## .method
+
+`request.method` returns the **uppercased** string representation of the request's HTTP method.
+
+Browser-based `PUT` and `DELETE` forms are transparently supported.
+
+For more information see the [browser enhancements documentation].    
+
+## .content_type
+
+`request.content_type`, returns a string object representing the media type of the HTTP request's body, or an empty string if no media type was provided.
+
+You won't typically need to directly access the request's content type, as you'll normally rely on REST framework's default request parsing behavior.
+
+If you do need to access the content type of the request you should use the `.content_type` property in preference to using `request.META.get('HTTP_CONTENT_TYPE')`, as it provides transparent support for browser-based non-form content.
+
+For more information see the [browser enhancements documentation].    
 
 ## .stream
 
 `request.stream` returns a stream representing the content of the request body.
 
-You will not typically need to access `request.stream`, unless you're writing a `Parser` class.
+You won't typically need to directly access the request's content, as you'll normally rely on REST framework's default request parsing behavior.
 
-## .authentication
+If you do need to access the raw content directly, you should use the `.stream` property in preference to using `request.content`, as it provides transparent support for browser-based non-form content.
 
-`request.authentication` should be set to a list of `Authentication` instances that can be used to authenticate the request.
-
-`request.authentication` may no longer be altered once `request.user` or `request.auth` have been accessed.
-
-If you're using the `rest_framework.views.View` class... **[TODO]**
+For more information see the [browser enhancements documentation].    
 
 [cite]: https://groups.google.com/d/topic/django-developers/dxI4qVzrBY4/discussion
+[parsers documentation]: parsers.md
+[authentication documentation]: authentication.md
+[browser enhancements documentation]: ../topics/browser-enhancements.md

docs/index.md

@@ -99,7 +99,7 @@ The API guide is your complete reference manual to all the functionality provide
 General guides to using REST framework.
 
 * [CSRF][csrf]
-* [Browser hacks][browserhacks]
+* [Browser enhancements][browser-enhancements]
 * [Working with the Browsable API][browsableapi]
 * [REST, Hypermedia & HATEOAS][rest-hypermedia-hateoas]
 * [Contributing to REST framework][contributing]
@@ -185,7 +185,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 [settings]: api-guide/settings.md
 
 [csrf]: topics/csrf.md
-[browserhacks]: topics/browserhacks.md
+[browser-enhancements]: topics/browser-enhancements.md
 [browsableapi]: topics/browsable-api.md
 [rest-hypermedia-hateoas]: topics/rest-hypermedia-hateoas.md
 [contributing]: topics/contributing.md

docs/template.html

@@ -73,7 +73,7 @@
                 <a href="#" class="dropdown-toggle" data-toggle="dropdown">Topics <b class="caret"></b></a>
                 <ul class="dropdown-menu">
                   <li><a href="{{ base_url }}/topics/csrf{{ suffix }}">Working with AJAX and CSRF</a></li>
-                  <li><a href="{{ base_url }}/topics/browserhacks{{ suffix }}">Browser hacks</a></li>
+                  <li><a href="{{ base_url }}/topics/browser-enhancements{{ suffix }}">Browser enhancements</a></li>
                   <li><a href="{{ base_url }}/topics/browsable-api{{ suffix }}">Working with the Browsable API</a></li>
                   <li><a href="{{ base_url }}/topics/rest-hypermedia-hateoas{{ suffix }}">REST, Hypermedia & HATEOAS</a></li>
                   <li><a href="{{ base_url }}/topics/contributing{{ suffix }}">Contributing to REST framework</a></li>

docs/topics/browser-enhancements.md

@@ -1,4 +1,4 @@
-# Browser hacks
+# Browser enhancements
 
 > "There are two noncontroversial uses for overloaded POST.  The first is to *simulate* HTTP's uniform interface for clients like web browsers that don't support PUT or DELETE"
 >
@@ -27,7 +27,7 @@ For example, given the following form:
 		<input name="_content" value="{'count': 1}">
 	</form>
 
-`request.content_type` would return `"application/json"`, and `request.content` would return `"{'count': 1}"`
+`request.content_type` would return `"application/json"`, and `request.stream` would return `"{'count': 1}"`
 
 ## URL based accept headers
 

rest_framework/request.py

@@ -96,7 +96,7 @@ class Request(object):
         """
         Returns the content type header.
 
-        This should be used instead of ``request.META.get('HTTP_CONTENT_TYPE')``,
+        This should be used instead of `request.META.get('HTTP_CONTENT_TYPE')`,
         as it allows the content type to be overridden by using a hidden form
         field on a form POST request.
         """