<li><ahref="#wrapping-api-views">Wrapping API views</a></li>
<li><ahref="#pulling-it-all-together">Pulling it all together</a></li>
<li><ahref="#adding-optional-format-suffixes-to-our-urls">Adding optional format suffixes to our URLs</a></li>
<li><ahref="#hows-it-looking">How's it looking?</a></li>
<li><ahref="#whats-next">What's next?</a></li>
</ul>
</div>
</div>
<divclass="span9">
<h1id="tutorial-2-request-and-response-objects">Tutorial 2: Request and Response objects</h1>
<p>From this point we're going to really start covering the core of REST framework.
Let's introduce a couple of essential building blocks.</p>
<h2id="request-objects">Request objects</h2>
<p>REST framework intoduces a <code>Request</code> object that extends the regular <code>HttpRequest</code>, and provides more flexible request parsing. The core functionality of the <code>Request</code> object is the <code>request.DATA</code> attribute, which is similar to <code>request.POST</code>, but more useful for working with Web APIs.</p>
<pre><code>request.POST # Only handles form data. Only works for 'POST' method.
request.DATA # Handles arbitrary data. Works any HTTP request with content.
</code></pre>
<h2id="response-objects">Response objects</h2>
<p>REST framework also introduces a <code>Response</code> object, which is a type of <code>TemplateResponse</code> that takes unrendered content and uses content negotiation to determine the correct content type to return to the client.</p>
<pre><code>return Response(data) # Renders to content type as requested by the client.
</code></pre>
<h2id="status-codes">Status codes</h2>
<p>Using numeric HTTP status codes in your views doesn't always make for obvious reading, and it's easy to not notice if you get an error code wrong. REST framework provides more explicit identifiers for each status code, such as <code>HTTP_400_BAD_REQUEST</code> in the <code>status</code> module. It's a good idea to use these throughout rather than using numeric identifiers.</p>
<h2id="wrapping-api-views">Wrapping API views</h2>
<p>REST framework provides two wrappers you can use to write API views.</p>
<ol>
<li>The <code>@api_view</code> decorator for working with function based views.</li>
<li>The <code>APIView</code> class for working with class based views.</li>
</ol>
<p>These wrappers provide a few bits of functionality such as making sure you recieve <code>Request</code> instances in your view, and adding context to <code>Response</code> objects so that content negotiation can be performed.</p>
<p>The wrappers also provide behaviour such as returning <code>405 Method Not Allowed</code> responses when appropriate, and handling any <code>ParseError</code> exception that occurs when accessing <code>request.DATA</code> with malformed input.</p>
<h2id="pulling-it-all-together">Pulling it all together</h2>
<p>Okay, let's go ahead and start using these new components to write a few views. </p>
<p>We don't need our <code>JSONResponse</code> class anymore, so go ahead and delete that. Once that's done we can start refactoring our views slightly.</p>
<pre><code>from blog.models import Comment
from blog.serializers import CommentSerializer
from djangorestframework import status
from djangorestframework.decorators import api_view
<p>Our instance view is an improvement over the previous example. It's a little more concise, and the code now feels very similar to if we were working with the Forms API. We're also using named status codes, which makes the response meanings more obvious.</p>
<p>Notice that we're no longer explicitly tying our requests or responses to a given content type. <code>request.DATA</code> can handle incoming <code>json</code> requests, but it can also handle <code>yaml</code> 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.</p>
<h2id="adding-optional-format-suffixes-to-our-urls">Adding optional format suffixes to our URLs</h2>
<p>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 <ahref="http://example.com/api/items/4.json">http://example.com/api/items/4.json</a>.</p>
<p>We don't necessarily need to add these extra url patterns in, but it gives us a simple, clean way of refering to a specific format.</p>
<h2id="hows-it-looking">How's it looking?</h2>
<p>Go ahead and test the API from the command line, as we did in <ahref="1-serialization.html">tutorial part 1</a>. Everything is working pretty similarly, although we've got some nicer error handling if we send invalid requests.</p>
<p><strong>TODO: Describe using accept headers, content-type headers, and format suffixed URLs</strong></p>
<p>Now go and open the API in a web browser, by visiting <ahref="http://127.0.0.1:8000/">http://127.0.0.1:8000/</a>.</p>
<p><strong>TODO: Describe browseable API awesomeness</strong></p>
<h2id="whats-next">What's next?</h2>
<p>In <ahref="3-class-based-views.html">tutorial part 3</a>, we'll start using class based views, and see how generic views reduce the amount of code we need to write.</p>