<p><em>Many thanks to all our <ahref="https://fund.django-rest-framework.org/topics/funding/#our-sponsors">awesome sponsors</a>, and in particular to our premium backers, <ahref="http://jobs.rover.com/">Rover</a>, <ahref="https://getsentry.com/welcome/">Sentry</a>, and <ahref="https://getstream.io/?utm_source=drf&utm_medium=banner&utm_campaign=drf">Stream</a>.</em></p>
<hr/>
<h2id="schemas-client-libraries"><aclass="toclink"href="#schemas-client-libraries">Schemas & client libraries</a></h2>
<p>REST framework 3.4 brings built-in support for generating API schemas.</p>
<p>We provide this support by using <ahref="http://www.coreapi.org/">Core API</a>, a Document Object Model
for describing APIs.</p>
<p>Because Core API represents the API schema in an format-independent
manner, we're able to render the Core API <code>Document</code> object into many different
schema formats, by allowing the renderer class to determine how the internal
representation maps onto the external schema format.</p>
<p>This approach should also open the door to a range of auto-generated API
documentation options in the future, by rendering the <code>Document</code> object into
HTML documentation pages.</p>
<p>Alongside the built-in schema support, we're also now providing the following:</p>
<ul>
<li>A <ahref="../api-clients#command-line-client">command line tool</a> for interacting with APIs.</li>
<li>A <ahref="../api-clients#python-client-library">Python client library</a> for interacting with APIs.</li>
</ul>
<p>These API clients are dynamically driven, and able to interact with any API
that exposes a supported schema format.</p>
<p>Dynamically driven clients allow you to interact with an API at an application
layer interface, rather than a network layer interface, while still providing
the benefits of RESTful Web API design.</p>
<p>We're expecting to expand the range of languages that we provide client libraries
for over the coming months.</p>
<p>Further work on maturing the API schema support is also planned, including
documentation on supporting file upload and download, and improved support for
documentation generation and parameter annotation.</p>
<hr/>
<p>Current support for schema formats is as follows:</p>
<p>(*) Note that Python 3.2 and 3.3 are not supported from Django 1.9 onwards.</p>
<hr/>
<h2id="deprecations-and-changes"><aclass="toclink"href="#deprecations-and-changes">Deprecations and changes</a></h2>
<p>The 3.4 release includes very limited deprecation or behavioral changes, and
should present a straightforward upgrade.</p>
<h3id="use-fields-or-exclude-on-serializer-classes"><aclass="toclink"href="#use-fields-or-exclude-on-serializer-classes">Use fields or exclude on serializer classes.</a></h3>
<p>The following change in 3.3.0 is now escalated from "pending deprecation" to
"deprecated". Its usage will continue to function but will raise warnings:</p>
<p><code>ModelSerializer</code> and <code>HyperlinkedModelSerializer</code> should include either a <code>fields</code>
option, or an <code>exclude</code> option. The <code>fields = '__all__'</code> shortcut may be used
to explicitly include all fields.</p>
<h3id="microsecond-precision-when-returning-time-or-datetime"><aclass="toclink"href="#microsecond-precision-when-returning-time-or-datetime">Microsecond precision when returning time or datetime.</a></h3>
<p>Using the default JSON renderer and directly returning a <code>datetime</code> or <code>time</code>
instance will now render with microsecond precision (6 digits), rather than
millisecond precision (3 digits). This makes the output format consistent with the
default string output of <code>serializers.DateTimeField</code> and <code>serializers.TimeField</code>.</p>
<p>This change <em>does not affect the default behavior when using serializers</em>,
which is to serialize <code>datetime</code> and <code>time</code> instances into strings with
microsecond precision.</p>
<p>The serializer behavior can be modified if needed, using the <code>DATETIME_FORMAT</code>
and <code>TIME_FORMAT</code> settings.</p>
<p>The renderer behavior can be modified by setting a custom <code>encoder_class</code>
attribute on a <code>JSONRenderer</code> subclass.</p>
<h3id="relational-choices-no-longer-displayed-in-options-requests"><aclass="toclink"href="#relational-choices-no-longer-displayed-in-options-requests">Relational choices no longer displayed in OPTIONS requests.</a></h3>
<p>Making an <code>OPTIONS</code> request to views that have a serializer choice field
will result in a list of the available choices being returned in the response.</p>
<p>In cases where there is a relational field, the previous behavior would be
to return a list of available instances to choose from for that relational field.</p>
<p>In order to minimise exposed information the behavior now is to <em>not</em> return
choices information for relational fields.</p>
<p>If you want to override this new behavior you'll need to <ahref="../../../api-guide/metadata/#custom-metadata-classes">implement a custom
metadata class</a>.</p>
<p>See <ahref="https://github.com/tomchristie/django-rest-framework/issues/3751">issue #3751</a> for more information on this behavioral change.</p>
<p>This release includes further work from a huge number of <ahref="https://github.com/tomchristie/django-rest-framework/milestone/35">pull requests and issues</a>.</p>
<p>Many thanks to all our contributors who've been involved in the release, either through raising issues, giving feedback, improving the documentation, or suggesting and implementing code changes.</p>
<p>The full set of itemized release notes <ahref="../release-notes#34">are available here</a>.</p>
</div><!--/span-->
</div><!--/row-->
</div><!--/.fluid-container-->
</div><!--/.body content-->
<divid="push"></div>
</div><!--/.wrapper -->
<footerclass="span12">
<p>Documentation built with <ahref="http://www.mkdocs.org/">MkDocs</a>.
