<p>The <strong>base class</strong> for all exceptions raised inside REST framework.</p>
<p>The <strong>base class</strong> for all exceptions raised inside REST framework.</p>
<p>To provide a custom exception, subclass <code>APIException</code> and set the <code>.status_code</code> and <code>.detail</code> properties on the class.</p>
<p>To provide a custom exception, subclass <code>APIException</code> and set the <code>.status_code</code> and <code>.detail</code> properties on the class.</p>
<p>For example, if your API relies on a third party service that may sometimes be unreachable, you might want to implement an exception for the "503 Service Unavailable" HTTP response code. You could do this like so:</p>
<li>Fix compatiblity with newer versions of <code>django-oauth-plus</code>.</li>
<li>Fix compatiblity with newer versions of <code>django-oauth-plus</code>.</li>
<li>Bugfix: Refine behavior that calls model manager <code>all()</code> across nested serializer relationships, preventing erronous behavior with some non-ORM objects, and preventing unneccessary queryset re-evaluations.</li>
<li>Bugfix: Refine behavior that calls model manager <code>all()</code> across nested serializer relationships, preventing erronous behavior with some non-ORM objects, and preventing unneccessary queryset re-evaluations.</li>
<li>Bugfix: Allow defaults on BooleanFields to be properly honored when values are not supplied.</li>
<li>Bugfix: Allow defaults on BooleanFields to be properly honored when values are not supplied.</li>
<li>Bugfix: Prevent double-escaping of non-latin1 URL query params when appending <code>format=json</code> params.</li>
<p>Note that because we want to be able to POST to this view from clients that won't have a CSRF token we need to mark the view as <code>csrf_exempt</code>. This isn't something that you'd normally want to do, and REST framework views actually use more sensible behavior than this, but it'll do for our purposes right now. </p>
<p>Note that because we want to be able to POST to this view from clients that won't have a CSRF token we need to mark the view as <code>csrf_exempt</code>. This isn't something that you'd normally want to do, and REST framework views actually use more sensible behavior than this, but it'll do for our purposes right now. </p>
<p>We'll also need a view which corresponds to an individual snippet, and can be used to retrieve, update or delete the snippet.</p>
<p>We'll also need a view which corresponds to an individual snippet, and can be used to retrieve, update or delete the snippet.</p>
<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>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>Here is the view for an individual snippet, in the <code>views.py</code> module.</p>
<p>Here is the view for an individual snippet, in the <code>views.py</code> module.</p>
# so we'll always allow GET, HEAD or OPTIONS requests.
# so we'll always allow GET, HEAD or OPTIONS requests.
if request.method in permissions.SAFE_METHODS:
if request.method in permissions.SAFE_METHODS:
return True
return True
# Write permissions are only allowed to the owner of the snippet
# Write permissions are only allowed to the owner of the snippet.
return obj.owner == request.user
return obj.owner == request.user
</code></pre>
</code></pre>
<p>Now we can add that custom permission to our snippet instance endpoint, by editing the <code>permission_classes</code> property on the <code>SnippetDetail</code> class:</p>
<p>Now we can add that custom permission to our snippet instance endpoint, by editing the <code>permission_classes</code> property on the <code>SnippetDetail</code> class:</p>
