mirror of
https://github.com/encode/django-rest-framework.git
synced 2025-02-03 13:14:30 +03:00
Add "Community" section to docs, minor cleanup (#5993)
* Add 'Community' tab to navigation, move articles * Drop DRF 2.x announcements and the docs note * Drop embedded tutorial/guide/topics links * Conver mixture of tabs/spaces => spaces * Fix topics/community links
This commit is contained in:
Ryan P Kilby
Carlton Gibson
parent
7095021db7
commit
99ca078ebb
|
|
@ -119,7 +119,7 @@ This would now be split out into two separate methods.
|
|||
instance.save()
|
||||
return instance
|
||||
|
||||
def create(self, validated_data):
|
||||
def create(self, validated_data):
|
||||
return Snippet.objects.create(**validated_data)
|
||||
|
||||
Note that these methods should return the newly created object instance.
|
||||
|
|
@ -329,7 +329,7 @@ The `write_only_fields` option on `ModelSerializer` has been moved to `PendingDe
|
|||
model = MyModel
|
||||
fields = ('id', 'email', 'notes', 'is_admin')
|
||||
extra_kwargs = {
|
||||
'is_admin': {'write_only': True}
|
||||
'is_admin': {'write_only': True}
|
||||
}
|
||||
|
||||
Alternatively, specify the field explicitly on the serializer class:
|
||||
|
|
@ -454,7 +454,7 @@ We can now use this class to serialize single `HighScore` instances:
|
|||
def high_score(request, pk):
|
||||
instance = HighScore.objects.get(pk=pk)
|
||||
serializer = HighScoreSerializer(instance)
|
||||
return Response(serializer.data)
|
||||
return Response(serializer.data)
|
||||
|
||||
Or use it to serialize multiple instances:
|
||||
|
||||
|
|
@ -462,7 +462,7 @@ Or use it to serialize multiple instances:
|
|||
def all_high_scores(request):
|
||||
queryset = HighScore.objects.order_by('-score')
|
||||
serializer = HighScoreSerializer(queryset, many=True)
|
||||
return Response(serializer.data)
|
||||
return Response(serializer.data)
|
||||
|
||||
##### Read-write `BaseSerializer` classes.
|
||||
|
||||
|
|
@ -493,8 +493,8 @@ Here's a complete example of our previous `HighScoreSerializer`, that's been upd
|
|||
'player_name': 'May not be more than 10 characters.'
|
||||
})
|
||||
|
||||
# Return the validated values. This will be available as
|
||||
# the `.validated_data` property.
|
||||
# Return the validated values. This will be available as
|
||||
# the `.validated_data` property.
|
||||
return {
|
||||
'score': int(score),
|
||||
'player_name': player_name
|
||||
|
|
@ -123,7 +123,7 @@ If you only wish to support a subset of the supported languages, use Django's st
|
|||
('en', _('English')),
|
||||
]
|
||||
|
||||
For more details, see the [internationalization documentation](internationalization.md).
|
||||
For more details, see the [internationalization documentation][internationalization].
|
||||
|
||||
Many thanks to [Craig Blaszczyk](https://github.com/jakul) for helping push this through.
|
||||
|
||||
|
|
@ -205,5 +205,5 @@ This will either be made as a single 3.2 release, or split across two separate r
|
|||
[custom-exception-handler]: ../api-guide/exceptions.md#custom-exception-handling
|
||||
[pagination]: ../api-guide/pagination.md
|
||||
[versioning]: ../api-guide/versioning.md
|
||||
[internationalization]: internationalization.md
|
||||
[internationalization]: ../topics/internationalization.md
|
||||
[customizing-field-mappings]: ../api-guide/serializers.md#customizing-field-mappings
|
||||
|
|
@ -83,7 +83,7 @@ When using `allow_null` with `ListField` or a nested `many=True` serializer the
|
|||
|
||||
For example, take the following field:
|
||||
|
||||
NestedSerializer(many=True, allow_null=True)
|
||||
NestedSerializer(many=True, allow_null=True)
|
||||
|
||||
Previously the validation behavior would be:
|
||||
|
||||
|
|
@ -110,4 +110,4 @@ This release is planned to include:
|
|||
* Improvements and public API for our templated HTML forms and fields.
|
||||
* Nested object and list support in HTML forms.
|
||||
|
||||
Thanks once again to all our sponsors and supporters.
|
||||
Thanks once again to all our sponsors and supporters.
|
||||
|
|
@ -37,8 +37,8 @@ This brings our supported versions into line with Django's [currently supported
|
|||
The AJAX based support for the browsable API means that there are a number of internal cleanups in the `request` class. For the vast majority of developers this should largely remain transparent:
|
||||
|
||||
* To support form based `PUT` and `DELETE`, or to support form content types such as JSON, you should now use the [AJAX forms][ajax-form] javascript library. This replaces the previous 'method and content type overloading' that required significant internal complexity to the request class.
|
||||
* The `accept` query parameter is no longer supported by the default content negotiation class. If you require it then you'll need to [use a custom content negotiation class](browser-enhancements.md#url-based-accept-headers).
|
||||
* The custom `HTTP_X_HTTP_METHOD_OVERRIDE` header is no longer supported by default. If you require it then you'll need to [use custom middleware](browser-enhancements.md#http-header-based-method-overriding).
|
||||
* The `accept` query parameter is no longer supported by the default content negotiation class. If you require it then you'll need to [use a custom content negotiation class][accept-headers].
|
||||
* The custom `HTTP_X_HTTP_METHOD_OVERRIDE` header is no longer supported by default. If you require it then you'll need to [use custom middleware][method-override].
|
||||
|
||||
The following pagination view attributes and settings have been moved into attributes on the pagination class since 3.1. Their usage was formerly deprecated, and has now been removed entirely, in line with the deprecation policy.
|
||||
|
||||
|
|
@ -52,7 +52,9 @@ The following pagination view attributes and settings have been moved into attri
|
|||
|
||||
The `ModelSerializer` and `HyperlinkedModelSerializer` classes should now include either a `fields` or `exclude` option, although the `fields = '__all__'` shortcut may be used. Failing to include either of these two options is currently pending deprecation, and will be removed entirely in the 3.5 release. This behavior brings `ModelSerializer` more closely in line with Django's `ModelForm` behavior.
|
||||
|
||||
[forms-api]: html-and-forms.md
|
||||
[forms-api]: ../topics/html-and-forms.md
|
||||
[ajax-form]: https://github.com/encode/ajax-form
|
||||
[jsonfield]: ../../api-guide/fields#jsonfield
|
||||
[django-supported-versions]: https://www.djangoproject.com/download/#supported-versions
|
||||
[jsonfield]: ../api-guide/fields#jsonfield
|
||||
[accept-headers]: ../topics/browser-enhancements.md#url-based-accept-headers
|
||||
[method-override]: ../topics/browser-enhancements.md#http-header-based-method-overriding
|
||||
[django-supported-versions]: https://www.djangoproject.com/download/#supported-versions
|
||||
|
|
@ -185,10 +185,10 @@ The full set of itemized release notes [are available here][release-notes].
|
|||
[swagger]: https://openapis.org/specification
|
||||
[hyperschema]: http://json-schema.org/latest/json-schema-hypermedia.html
|
||||
[api-blueprint]: https://apiblueprint.org/
|
||||
[tut-7]: ../../tutorial/7-schemas-and-client-libraries/
|
||||
[schema-generation]: ../../api-guide/schemas/
|
||||
[api-clients]: api-clients.md
|
||||
[tut-7]: ../tutorial/7-schemas-and-client-libraries/
|
||||
[schema-generation]: ../api-guide/schemas/
|
||||
[api-clients]: ../topics/api-clients.md
|
||||
[milestone]: https://github.com/encode/django-rest-framework/milestone/35
|
||||
[release-notes]: release-notes#34
|
||||
[metadata]: ../../api-guide/metadata/#custom-metadata-classes
|
||||
[metadata]: ../api-guide/metadata/#custom-metadata-classes
|
||||
[gh3751]: https://github.com/encode/django-rest-framework/issues/3751
|
||||
|
|
@ -194,6 +194,6 @@ on realtime support, for the 3.7 release.
|
|||
|
||||
[sponsors]: https://fund.django-rest-framework.org/topics/funding/#our-sponsors
|
||||
[funding]: funding.md
|
||||
[api-docs]: documenting-your-api.md
|
||||
[js-docs]: api-clients.md#javascript-client-library
|
||||
[py-docs]: api-clients.md#python-client-library
|
||||
[api-docs]: ../topics/documenting-your-api.md
|
||||
[js-docs]: ../topics/api-clients.md#javascript-client-library
|
||||
[py-docs]: ../topics/api-clients.md#python-client-library
|
||||
|
|
@ -174,23 +174,23 @@ This subscription is recommended for individuals with an interest in seeing REST
|
|||
If you are using REST framework as a full-time employee, consider recommending that your company takes out a [corporate plan](#corporate-plans).
|
||||
|
||||
<div class="pricing">
|
||||
<div class="span4">
|
||||
<div class="chart first">
|
||||
<div class="quantity">
|
||||
<span class="dollar">{{ symbol }}</span>
|
||||
<span class="price">{{ rates.personal1 }}</span>
|
||||
<span class="period">/month{% if vat %} +VAT{% endif %}</span>
|
||||
</div>
|
||||
<div class="plan-name">Individual</div>
|
||||
<div class="specs freelancer">
|
||||
<div class="spec">
|
||||
Support ongoing development
|
||||
</div>
|
||||
<div class="spec">
|
||||
Credited on the site
|
||||
</div>
|
||||
</div>
|
||||
<form class="signup" action="/signup/{{ currency }}-{{ rates.personal1 }}/" method="POST">
|
||||
<div class="span4">
|
||||
<div class="chart first">
|
||||
<div class="quantity">
|
||||
<span class="dollar">{{ symbol }}</span>
|
||||
<span class="price">{{ rates.personal1 }}</span>
|
||||
<span class="period">/month{% if vat %} +VAT{% endif %}</span>
|
||||
</div>
|
||||
<div class="plan-name">Individual</div>
|
||||
<div class="specs freelancer">
|
||||
<div class="spec">
|
||||
Support ongoing development
|
||||
</div>
|
||||
<div class="spec">
|
||||
Credited on the site
|
||||
</div>
|
||||
</div>
|
||||
<form class="signup" action="/signup/{{ currency }}-{{ rates.personal1 }}/" method="POST">
|
||||
<script
|
||||
src="https://checkout.stripe.com/checkout.js" class="stripe-button"
|
||||
data-key="{{ stripe_public }}"
|
||||
|
|
@ -204,9 +204,9 @@ If you are using REST framework as a full-time employee, consider recommending t
|
|||
data-panel-label='Sign up - {% verbatim %}{{amount}}{% endverbatim %}/mo'>
|
||||
</script>
|
||||
</form>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div style="clear: both; padding-top: 50px"></div>
|
||||
|
||||
*Billing is monthly and you can cancel at any time.*
|
||||
|
|
@ -222,23 +222,23 @@ In exchange for funding you'll also receive advertising space on our site, allow
|
|||
Our professional and premium plans also include **priority support**. At any time your engineers can escalate an issue or discussion group thread, and we'll ensure it gets a guaranteed response within the next working day.
|
||||
|
||||
<div class="pricing">
|
||||
<div class="span4">
|
||||
<div class="chart first">
|
||||
<div class="quantity">
|
||||
<span class="dollar">{{ symbol }}</span>
|
||||
<span class="price">{{ rates.corporate1 }}</span>
|
||||
<span class="period">/month{% if vat %} +VAT{% endif %}</span>
|
||||
</div>
|
||||
<div class="plan-name">Basic</div>
|
||||
<div class="specs startup">
|
||||
<div class="spec">
|
||||
Support ongoing development
|
||||
</div>
|
||||
<div class="spec">
|
||||
<span class="variable">Funding page</span> ad placement
|
||||
</div>
|
||||
</div>
|
||||
<form class="signup" action="/signup/{{ currency }}-{{ rates.corporate1 }}/" method="POST">
|
||||
<div class="span4">
|
||||
<div class="chart first">
|
||||
<div class="quantity">
|
||||
<span class="dollar">{{ symbol }}</span>
|
||||
<span class="price">{{ rates.corporate1 }}</span>
|
||||
<span class="period">/month{% if vat %} +VAT{% endif %}</span>
|
||||
</div>
|
||||
<div class="plan-name">Basic</div>
|
||||
<div class="specs startup">
|
||||
<div class="spec">
|
||||
Support ongoing development
|
||||
</div>
|
||||
<div class="spec">
|
||||
<span class="variable">Funding page</span> ad placement
|
||||
</div>
|
||||
</div>
|
||||
<form class="signup" action="/signup/{{ currency }}-{{ rates.corporate1 }}/" method="POST">
|
||||
<script
|
||||
src="https://checkout.stripe.com/checkout.js" class="stripe-button"
|
||||
data-key="{{ stripe_public }}"
|
||||
|
|
@ -252,28 +252,28 @@ Our professional and premium plans also include **priority support**. At any tim
|
|||
data-panel-label='Sign up - {% verbatim %}{{amount}}{% endverbatim %}/mo'>
|
||||
</script>
|
||||
</form>
|
||||
</div>
|
||||
</div>
|
||||
<div class="span4">
|
||||
<div class="chart">
|
||||
<div class="quantity">
|
||||
<span class="dollar">{{ symbol }}</span>
|
||||
<span class="price">{{ rates.corporate2 }}</span>
|
||||
<span class="period">/month{% if vat %} +VAT{% endif %}</span>
|
||||
</div>
|
||||
<div class="plan-name">Professional</div>
|
||||
<div class="specs">
|
||||
</div>
|
||||
</div>
|
||||
<div class="span4">
|
||||
<div class="chart">
|
||||
<div class="quantity">
|
||||
<span class="dollar">{{ symbol }}</span>
|
||||
<span class="price">{{ rates.corporate2 }}</span>
|
||||
<span class="period">/month{% if vat %} +VAT{% endif %}</span>
|
||||
</div>
|
||||
<div class="plan-name">Professional</div>
|
||||
<div class="specs">
|
||||
<div class="spec">
|
||||
Support ongoing development
|
||||
</div>
|
||||
<div class="spec">
|
||||
<span class="variable">Sidebar</span> ad placement
|
||||
</div>
|
||||
<div class="spec">
|
||||
<span class="variable">Priority support</span> for your engineers
|
||||
</div>
|
||||
</div>
|
||||
<form class="signup" action="/signup/{{ currency }}-{{ rates.corporate2 }}/" method="POST">
|
||||
<div class="spec">
|
||||
<span class="variable">Sidebar</span> ad placement
|
||||
</div>
|
||||
<div class="spec">
|
||||
<span class="variable">Priority support</span> for your engineers
|
||||
</div>
|
||||
</div>
|
||||
<form class="signup" action="/signup/{{ currency }}-{{ rates.corporate2 }}/" method="POST">
|
||||
<script
|
||||
src="https://checkout.stripe.com/checkout.js" class="stripe-button"
|
||||
data-key="{{ stripe_public }}"
|
||||
|
|
@ -287,31 +287,31 @@ Our professional and premium plans also include **priority support**. At any tim
|
|||
data-panel-label='Sign up - {% verbatim %}{{amount}}{% endverbatim %}/mo'>
|
||||
</script>
|
||||
</form>
|
||||
</div>
|
||||
</div>
|
||||
<div class="span4">
|
||||
<div class="chart last">
|
||||
<div class="quantity">
|
||||
<span class="dollar">{{ symbol }}</span>
|
||||
<span class="price">{{ rates.corporate3 }}</span>
|
||||
<span class="period">/month{% if vat %} +VAT{% endif %}</span>
|
||||
</div>
|
||||
<div class="plan-name">Premium</div>
|
||||
<div class="specs">
|
||||
</div>
|
||||
</div>
|
||||
<div class="span4">
|
||||
<div class="chart last">
|
||||
<div class="quantity">
|
||||
<span class="dollar">{{ symbol }}</span>
|
||||
<span class="price">{{ rates.corporate3 }}</span>
|
||||
<span class="period">/month{% if vat %} +VAT{% endif %}</span>
|
||||
</div>
|
||||
<div class="plan-name">Premium</div>
|
||||
<div class="specs">
|
||||
<div class="spec">
|
||||
Support ongoing development
|
||||
</div>
|
||||
<div class="spec">
|
||||
<span class="variable">Homepage</span> ad placement
|
||||
</div>
|
||||
<div class="spec">
|
||||
<span class="variable">Sidebar</span> ad placement
|
||||
</div>
|
||||
<div class="spec">
|
||||
<span class="variable">Priority support</span> for your engineers
|
||||
</div>
|
||||
</div>
|
||||
<form class="signup" action="/signup/{{ currency }}-{{ rates.corporate3 }}/" method="POST">
|
||||
<div class="spec">
|
||||
<span class="variable">Homepage</span> ad placement
|
||||
</div>
|
||||
<div class="spec">
|
||||
<span class="variable">Sidebar</span> ad placement
|
||||
</div>
|
||||
<div class="spec">
|
||||
<span class="variable">Priority support</span> for your engineers
|
||||
</div>
|
||||
</div>
|
||||
<form class="signup" action="/signup/{{ currency }}-{{ rates.corporate3 }}/" method="POST">
|
||||
<script
|
||||
src="https://checkout.stripe.com/checkout.js" class="stripe-button"
|
||||
data-key="{{ stripe_public }}"
|
||||
|
|
@ -325,9 +325,9 @@ Our professional and premium plans also include **priority support**. At any tim
|
|||
data-panel-label='Sign up - {% verbatim %}{{amount}}{% endverbatim %}/mo'>
|
||||
</script>
|
||||
</form>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div style="clear: both; padding-top: 50px"></div>
|
||||
|
||||
|
|
@ -346,22 +346,22 @@ In an effort to keep the project as transparent as possible, we are releasing [m
|
|||
<!-- Begin MailChimp Signup Form -->
|
||||
<link href="//cdn-images.mailchimp.com/embedcode/classic-10_7.css" rel="stylesheet" type="text/css">
|
||||
<style type="text/css">
|
||||
#mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; }
|
||||
/* Add your own MailChimp form style overrides in your site stylesheet or in this style block.
|
||||
We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */
|
||||
#mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; }
|
||||
/* Add your own MailChimp form style overrides in your site stylesheet or in this style block.
|
||||
We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */
|
||||
</style>
|
||||
<div id="mc_embed_signup">
|
||||
<form action="//encode.us13.list-manage.com/subscribe/post?u=b6b66bb5e4c7cb484a85c8dd7&id=e382ef68ef" method="post" id="mc-embedded-subscribe-form" name="mc-embedded-subscribe-form" class="validate" target="_blank" novalidate>
|
||||
<div id="mc_embed_signup_scroll">
|
||||
<h2>Stay up to date, with our monthly progress reports...</h2>
|
||||
<h2>Stay up to date, with our monthly progress reports...</h2>
|
||||
<div class="mc-field-group">
|
||||
<label for="mce-EMAIL">Email Address </label>
|
||||
<input type="email" value="" name="EMAIL" class="required email" id="mce-EMAIL">
|
||||
<label for="mce-EMAIL">Email Address </label>
|
||||
<input type="email" value="" name="EMAIL" class="required email" id="mce-EMAIL">
|
||||
</div>
|
||||
<div id="mce-responses" class="clear">
|
||||
<div class="response" id="mce-error-response" style="display:none"></div>
|
||||
<div class="response" id="mce-success-response" style="display:none"></div>
|
||||
</div> <!-- real people should not fill this in and expect good things - do not remove this or risk form bot signups-->
|
||||
<div id="mce-responses" class="clear">
|
||||
<div class="response" id="mce-error-response" style="display:none"></div>
|
||||
<div class="response" id="mce-success-response" style="display:none"></div>
|
||||
</div> <!-- real people should not fill this in and expect good things - do not remove this or risk form bot signups-->
|
||||
<div style="position: absolute; left: -5000px;" aria-hidden="true"><input type="text" name="b_b6b66bb5e4c7cb484a85c8dd7_e382ef68ef" tabindex="-1" value=""></div>
|
||||
<div class="clear"><input type="submit" value="Subscribe" name="subscribe" id="mc-embedded-subscribe" class="button"></div>
|
||||
</div>
|
||||
|
|
@ -42,22 +42,22 @@ funded via the [REST framework paid plans](funding.md).
|
|||
<!-- Begin MailChimp Signup Form -->
|
||||
<link href="//cdn-images.mailchimp.com/embedcode/classic-10_7.css" rel="stylesheet" type="text/css">
|
||||
<style type="text/css">
|
||||
#mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; }
|
||||
/* Add your own MailChimp form style overrides in your site stylesheet or in this style block.
|
||||
We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */
|
||||
#mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; }
|
||||
/* Add your own MailChimp form style overrides in your site stylesheet or in this style block.
|
||||
We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */
|
||||
</style>
|
||||
<div id="mc_embed_signup">
|
||||
<form action="//encode.us13.list-manage.com/subscribe/post?u=b6b66bb5e4c7cb484a85c8dd7&id=e382ef68ef" method="post" id="mc-embedded-subscribe-form" name="mc-embedded-subscribe-form" class="validate" target="_blank" novalidate>
|
||||
<div id="mc_embed_signup_scroll">
|
||||
<h2>Stay up to date, with our monthly progress reports...</h2>
|
||||
<h2>Stay up to date, with our monthly progress reports...</h2>
|
||||
<div class="mc-field-group">
|
||||
<label for="mce-EMAIL">Email Address </label>
|
||||
<input type="email" value="" name="EMAIL" class="required email" id="mce-EMAIL">
|
||||
<label for="mce-EMAIL">Email Address </label>
|
||||
<input type="email" value="" name="EMAIL" class="required email" id="mce-EMAIL">
|
||||
</div>
|
||||
<div id="mce-responses" class="clear">
|
||||
<div class="response" id="mce-error-response" style="display:none"></div>
|
||||
<div class="response" id="mce-success-response" style="display:none"></div>
|
||||
</div> <!-- real people should not fill this in and expect good things - do not remove this or risk form bot signups-->
|
||||
<div id="mce-responses" class="clear">
|
||||
<div class="response" id="mce-error-response" style="display:none"></div>
|
||||
<div class="response" id="mce-success-response" style="display:none"></div>
|
||||
</div> <!-- real people should not fill this in and expect good things - do not remove this or risk form bot signups-->
|
||||
<div style="position: absolute; left: -5000px;" aria-hidden="true"><input type="text" name="b_b6b66bb5e4c7cb484a85c8dd7_e382ef68ef" tabindex="-1" value=""></div>
|
||||
<div class="clear"><input type="submit" value="Subscribe" name="subscribe" id="mc-embedded-subscribe" class="button"></div>
|
||||
</div>
|
||||
148
docs/index.md
148
docs/index.md
|
|
@ -31,10 +31,6 @@
|
|||
|
||||
---
|
||||
|
||||
**Note**: This is the documentation for the **version 3** of REST framework. Documentation for [version 2](https://tomchristie.github.io/rest-framework-2-docs/) is also available.
|
||||
|
||||
---
|
||||
|
||||
<p>
|
||||
<h1 style="position: absolute;
|
||||
width: 1px;
|
||||
|
|
@ -151,11 +147,11 @@ Here's our project's root `urls.py` module:
|
|||
from django.contrib.auth.models import User
|
||||
from rest_framework import routers, serializers, viewsets
|
||||
|
||||
# Serializers define the API representation.
|
||||
class UserSerializer(serializers.HyperlinkedModelSerializer):
|
||||
class Meta:
|
||||
model = User
|
||||
fields = ('url', 'username', 'email', 'is_staff')
|
||||
# Serializers define the API representation.
|
||||
class UserSerializer(serializers.HyperlinkedModelSerializer):
|
||||
class Meta:
|
||||
model = User
|
||||
fields = ('url', 'username', 'email', 'is_staff')
|
||||
|
||||
# ViewSets define the view behavior.
|
||||
class UserViewSet(viewsets.ModelViewSet):
|
||||
|
|
@ -179,83 +175,6 @@ You can now open the API in your browser at [http://127.0.0.1:8000/](http://127.
|
|||
|
||||
Can't wait to get started? The [quickstart guide][quickstart] is the fastest way to get up and running, and building APIs with REST framework.
|
||||
|
||||
## Tutorial
|
||||
|
||||
The tutorial will walk you through the building blocks that make up REST framework. It'll take a little while to get through, but it'll give you a comprehensive understanding of how everything fits together, and is highly recommended reading.
|
||||
|
||||
* [1 - Serialization][tut-1]
|
||||
* [2 - Requests & Responses][tut-2]
|
||||
* [3 - Class-based views][tut-3]
|
||||
* [4 - Authentication & permissions][tut-4]
|
||||
* [5 - Relationships & hyperlinked APIs][tut-5]
|
||||
* [6 - Viewsets & routers][tut-6]
|
||||
* [7 - Schemas & client libraries][tut-7]
|
||||
|
||||
There is a live example API of the finished tutorial API for testing purposes, [available here][sandbox].
|
||||
|
||||
## API Guide
|
||||
|
||||
The API guide is your complete reference manual to all the functionality provided by REST framework.
|
||||
|
||||
* [Requests][request]
|
||||
* [Responses][response]
|
||||
* [Views][views]
|
||||
* [Generic views][generic-views]
|
||||
* [Viewsets][viewsets]
|
||||
* [Routers][routers]
|
||||
* [Parsers][parsers]
|
||||
* [Renderers][renderers]
|
||||
* [Serializers][serializers]
|
||||
* [Serializer fields][fields]
|
||||
* [Serializer relations][relations]
|
||||
* [Validators][validators]
|
||||
* [Authentication][authentication]
|
||||
* [Permissions][permissions]
|
||||
* [Throttling][throttling]
|
||||
* [Filtering][filtering]
|
||||
* [Pagination][pagination]
|
||||
* [Versioning][versioning]
|
||||
* [Content negotiation][contentnegotiation]
|
||||
* [Metadata][metadata]
|
||||
* [Schemas][schemas]
|
||||
* [Format suffixes][formatsuffixes]
|
||||
* [Returning URLs][reverse]
|
||||
* [Exceptions][exceptions]
|
||||
* [Status codes][status]
|
||||
* [Testing][testing]
|
||||
* [Settings][settings]
|
||||
|
||||
## Topics
|
||||
|
||||
General guides to using REST framework.
|
||||
|
||||
* [Documenting your API][documenting-your-api]
|
||||
* [API Clients][api-clients]
|
||||
* [Internationalization][internationalization]
|
||||
* [AJAX, CSRF & CORS][ajax-csrf-cors]
|
||||
* [HTML & Forms][html-and-forms]
|
||||
* [Browser enhancements][browser-enhancements]
|
||||
* [The Browsable API][browsableapi]
|
||||
* [REST, Hypermedia & HATEOAS][rest-hypermedia-hateoas]
|
||||
* [Third Party Packages][third-party-packages]
|
||||
* [Tutorials and Resources][tutorials-and-resources]
|
||||
* [Contributing to REST framework][contributing]
|
||||
* [Project management][project-management]
|
||||
* [3.0 Announcement][3.0-announcement]
|
||||
* [3.1 Announcement][3.1-announcement]
|
||||
* [3.2 Announcement][3.2-announcement]
|
||||
* [3.3 Announcement][3.3-announcement]
|
||||
* [3.4 Announcement][3.4-announcement]
|
||||
* [3.5 Announcement][3.5-announcement]
|
||||
* [3.6 Announcement][3.6-announcement]
|
||||
* [3.7 Announcement][3.7-announcement]
|
||||
* [3.8 Announcement][3.8-announcement]
|
||||
* [Kickstarter Announcement][kickstarter-announcement]
|
||||
* [Mozilla Grant][mozilla-grant]
|
||||
* [Funding][funding]
|
||||
* [Release Notes][release-notes]
|
||||
* [Jobs][jobs]
|
||||
|
||||
## Development
|
||||
|
||||
See the [Contribution guidelines][contributing] for information on how to clone
|
||||
|
|
@ -323,68 +242,15 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|||
[sponsors]: https://fund.django-rest-framework.org/topics/funding/#our-sponsors
|
||||
|
||||
[quickstart]: tutorial/quickstart.md
|
||||
[tut-1]: tutorial/1-serialization.md
|
||||
[tut-2]: tutorial/2-requests-and-responses.md
|
||||
[tut-3]: tutorial/3-class-based-views.md
|
||||
[tut-4]: tutorial/4-authentication-and-permissions.md
|
||||
[tut-5]: tutorial/5-relationships-and-hyperlinked-apis.md
|
||||
[tut-6]: tutorial/6-viewsets-and-routers.md
|
||||
[tut-7]: tutorial/7-schemas-and-client-libraries.md
|
||||
|
||||
[request]: api-guide/requests.md
|
||||
[response]: api-guide/responses.md
|
||||
[views]: api-guide/views.md
|
||||
[generic-views]: api-guide/generic-views.md
|
||||
[viewsets]: api-guide/viewsets.md
|
||||
[routers]: api-guide/routers.md
|
||||
[parsers]: api-guide/parsers.md
|
||||
[renderers]: api-guide/renderers.md
|
||||
[serializers]: api-guide/serializers.md
|
||||
[fields]: api-guide/fields.md
|
||||
[relations]: api-guide/relations.md
|
||||
[validators]: api-guide/validators.md
|
||||
[authentication]: api-guide/authentication.md
|
||||
[permissions]: api-guide/permissions.md
|
||||
[throttling]: api-guide/throttling.md
|
||||
[filtering]: api-guide/filtering.md
|
||||
[pagination]: api-guide/pagination.md
|
||||
[versioning]: api-guide/versioning.md
|
||||
[contentnegotiation]: api-guide/content-negotiation.md
|
||||
[metadata]: api-guide/metadata.md
|
||||
[schemas]: api-guide/schemas.md
|
||||
[formatsuffixes]: api-guide/format-suffixes.md
|
||||
[reverse]: api-guide/reverse.md
|
||||
[exceptions]: api-guide/exceptions.md
|
||||
[status]: api-guide/status-codes.md
|
||||
[testing]: api-guide/testing.md
|
||||
[settings]: api-guide/settings.md
|
||||
|
||||
[documenting-your-api]: topics/documenting-your-api.md
|
||||
[api-clients]: topics/api-clients.md
|
||||
[internationalization]: topics/internationalization.md
|
||||
[ajax-csrf-cors]: topics/ajax-csrf-cors.md
|
||||
[html-and-forms]: topics/html-and-forms.md
|
||||
[browser-enhancements]: topics/browser-enhancements.md
|
||||
[browsableapi]: topics/browsable-api.md
|
||||
[rest-hypermedia-hateoas]: topics/rest-hypermedia-hateoas.md
|
||||
[contributing]: topics/contributing.md
|
||||
[project-management]: topics/project-management.md
|
||||
[third-party-packages]: topics/third-party-packages.md
|
||||
[tutorials-and-resources]: topics/tutorials-and-resources.md
|
||||
[3.0-announcement]: topics/3.0-announcement.md
|
||||
[3.1-announcement]: topics/3.1-announcement.md
|
||||
[3.2-announcement]: topics/3.2-announcement.md
|
||||
[3.3-announcement]: topics/3.3-announcement.md
|
||||
[3.4-announcement]: topics/3.4-announcement.md
|
||||
[3.5-announcement]: topics/3.5-announcement.md
|
||||
[3.6-announcement]: topics/3.6-announcement.md
|
||||
[3.7-announcement]: topics/3.7-announcement.md
|
||||
[3.8-announcement]: topics/3.8-announcement.md
|
||||
[kickstarter-announcement]: topics/kickstarter-announcement.md
|
||||
[mozilla-grant]: topics/mozilla-grant.md
|
||||
[funding]: topics/funding.md
|
||||
[release-notes]: topics/release-notes.md
|
||||
[jobs]: topics/jobs.md
|
||||
[contributing]: community/contributing.md
|
||||
[funding]: community/funding.md
|
||||
|
||||
[group]: https://groups.google.com/forum/?fromgroups#!forum/django-rest-framework
|
||||
[botbot]: https://botbot.me/freenode/restframework/
|
||||
|
|
|
|||
|
|
@ -1,158 +0,0 @@
|
|||
# Django REST framework 2.2
|
||||
|
||||
The 2.2 release represents an important point for REST framework, with the addition of Python 3 support, and the introduction of an official deprecation policy.
|
||||
|
||||
## Python 3 support
|
||||
|
||||
Thanks to some fantastic work from [Xavier Ordoquy][xordoquy], Django REST framework 2.2 now supports Python 3. You'll need to be running Django 1.5, and it's worth keeping in mind that Django's Python 3 support is currently [considered experimental][django-python-3].
|
||||
|
||||
Django 1.6's Python 3 support is expected to be officially labeled as 'production-ready'.
|
||||
|
||||
If you want to start ensuring that your own projects are Python 3 ready, we can highly recommend Django's [Porting to Python 3][porting-python-3] documentation.
|
||||
|
||||
Django REST framework's Python 2.6 support now requires 2.6.5 or above, in line with [Django 1.5's Python compatibility][python-compat].
|
||||
|
||||
## Deprecation policy
|
||||
|
||||
We've now introduced an official deprecation policy, which is in line with [Django's deprecation policy][django-deprecation-policy]. This policy will make it easy for you to continue to track the latest, greatest version of REST framework.
|
||||
|
||||
The timeline for deprecation works as follows:
|
||||
|
||||
* Version 2.2 introduces some API changes as detailed in the release notes. It remains fully backwards compatible with 2.1, but will raise `PendingDeprecationWarning` warnings if you use bits of API that are due to be deprecated. These warnings are silent by default, but can be explicitly enabled when you're ready to start migrating any required changes. For example if you start running your tests using `python -Wd manage.py test`, you'll be warned of any API changes you need to make.
|
||||
|
||||
* Version 2.3 will escalate these warnings to `DeprecationWarning`, which is loud by default.
|
||||
|
||||
* Version 2.4 will remove the deprecated bits of API entirely.
|
||||
|
||||
Note that in line with Django's policy, any parts of the framework not mentioned in the documentation should generally be considered private API, and may be subject to change.
|
||||
|
||||
## Community
|
||||
|
||||
As of the 2.2 merge, we've also hit an impressive milestone. The number of committers listed in [the credits][credits], is now at over **one hundred individuals**. Each name on that list represents at least one merged pull request, however large or small.
|
||||
|
||||
Our [mailing list][mailing-list] and #restframework IRC channel are also very active, and we've got a really impressive rate of development both on REST framework itself, and on third party packages such as the great [django-rest-framework-docs][django-rest-framework-docs] package from [Marc Gibbons][marcgibbons].
|
||||
|
||||
---
|
||||
|
||||
## API changes
|
||||
|
||||
The 2.2 release makes a few changes to the API, in order to make it more consistent, simple, and easier to use.
|
||||
|
||||
### Cleaner to-many related fields
|
||||
|
||||
The `ManyRelatedField()` style is being deprecated in favor of a new `RelatedField(many=True)` syntax.
|
||||
|
||||
For example, if a user is associated with multiple questions, which we want to represent using a primary key relationship, we might use something like the following:
|
||||
|
||||
class UserSerializer(serializers.HyperlinkedModelSerializer):
|
||||
questions = serializers.PrimaryKeyRelatedField(many=True)
|
||||
|
||||
class Meta:
|
||||
fields = ('username', 'questions')
|
||||
|
||||
The new syntax is cleaner and more obvious, and the change will also make the documentation cleaner, simplify the internal API, and make writing custom relational fields easier.
|
||||
|
||||
The change also applies to serializers. If you have a nested serializer, you should start using `many=True` for to-many relationships. For example, a serializer representation of an Album that can contain many Tracks might look something like this:
|
||||
|
||||
class TrackSerializer(serializer.ModelSerializer):
|
||||
class Meta:
|
||||
model = Track
|
||||
fields = ('name', 'duration')
|
||||
|
||||
class AlbumSerializer(serializer.ModelSerializer):
|
||||
tracks = TrackSerializer(many=True)
|
||||
|
||||
class Meta:
|
||||
model = Album
|
||||
fields = ('album_name', 'artist', 'tracks')
|
||||
|
||||
Additionally, the change also applies when serializing or deserializing data. For example to serialize a queryset of models you should now use the `many=True` flag.
|
||||
|
||||
serializer = SnippetSerializer(Snippet.objects.all(), many=True)
|
||||
serializer.data
|
||||
|
||||
This more explicit behavior on serializing and deserializing data [makes integration with non-ORM backends such as MongoDB easier][564], as instances to be serialized can include the `__iter__` method, without incorrectly triggering list-based serialization, or requiring workarounds.
|
||||
|
||||
The implicit to-many behavior on serializers, and the `ManyRelatedField` style classes will continue to function, but will raise a `PendingDeprecationWarning`, which can be made visible using the `-Wd` flag.
|
||||
|
||||
**Note**: If you need to forcibly turn off the implicit "`many=True` for `__iter__` objects" behavior, you can now do so by specifying `many=False`. This will become the default (instead of the current default of `None`) once the deprecation of the implicit behavior is finalised in version 2.4.
|
||||
|
||||
### Cleaner optional relationships
|
||||
|
||||
Serializer relationships for nullable Foreign Keys will change from using the current `null=True` flag, to instead using `required=False`.
|
||||
|
||||
For example, is a user account has an optional foreign key to a company, that you want to express using a hyperlink, you might use the following field in a `Serializer` class:
|
||||
|
||||
current_company = serializers.HyperlinkedRelatedField(required=False)
|
||||
|
||||
This is in line both with the rest of the serializer fields API, and with Django's `Form` and `ModelForm` API.
|
||||
|
||||
Using `required` throughout the serializers API means you won't need to consider if a particular field should take `blank` or `null` arguments instead of `required`, and also means there will be more consistent behavior for how fields are treated when they are not present in the incoming data.
|
||||
|
||||
The `null=True` argument will continue to function, and will imply `required=False`, but will raise a `PendingDeprecationWarning`.
|
||||
|
||||
### Cleaner CharField syntax
|
||||
|
||||
The `CharField` API previously took an optional `blank=True` argument, which was intended to differentiate between null CharField input, and blank CharField input.
|
||||
|
||||
In keeping with Django's CharField API, REST framework's `CharField` will only ever return the empty string, for missing or `None` inputs. The `blank` flag will no longer be in use, and you should instead just use the `required=<bool>` flag. For example:
|
||||
|
||||
extra_details = CharField(required=False)
|
||||
|
||||
The `blank` keyword argument will continue to function, but will raise a `PendingDeprecationWarning`.
|
||||
|
||||
### Simpler object-level permissions
|
||||
|
||||
Custom permissions classes previously used the signature `.has_permission(self, request, view, obj=None)`. This method would be called twice, firstly for the global permissions check, with the `obj` parameter set to `None`, and again for the object-level permissions check when appropriate, with the `obj` parameter set to the relevant model instance.
|
||||
|
||||
The global permissions check and object-level permissions check are now separated into two separate methods, which gives a cleaner, more obvious API.
|
||||
|
||||
* Global permission checks now use the `.has_permission(self, request, view)` signature.
|
||||
* Object-level permission checks use a new method `.has_object_permission(self, request, view, obj)`.
|
||||
|
||||
For example, the following custom permission class:
|
||||
|
||||
class IsOwner(permissions.BasePermission):
|
||||
"""
|
||||
Custom permission to only allow owners of an object to view or edit it.
|
||||
Model instances are expected to include an `owner` attribute.
|
||||
"""
|
||||
|
||||
def has_permission(self, request, view, obj=None):
|
||||
if obj is None:
|
||||
# Ignore global permissions check
|
||||
return True
|
||||
|
||||
return obj.owner == request.user
|
||||
|
||||
Now becomes:
|
||||
|
||||
class IsOwner(permissions.BasePermission):
|
||||
"""
|
||||
Custom permission to only allow owners of an object to view or edit it.
|
||||
Model instances are expected to include an `owner` attribute.
|
||||
"""
|
||||
|
||||
def has_object_permission(self, request, view, obj):
|
||||
return obj.owner == request.user
|
||||
|
||||
If you're overriding the `BasePermission` class, the old-style signature will continue to function, and will correctly handle both global and object-level permissions checks, but its use will raise a `PendingDeprecationWarning`.
|
||||
|
||||
Note also that the usage of the internal APIs for permission checking on the `View` class has been cleaned up slightly, and is now documented and subject to the deprecation policy in all future versions.
|
||||
|
||||
### More explicit hyperlink relations behavior
|
||||
|
||||
When using a serializer with a `HyperlinkedRelatedField` or `HyperlinkedIdentityField`, the hyperlinks would previously use absolute URLs if the serializer context included a `'request'` key, and fall back to using relative URLs otherwise. This could lead to non-obvious behavior, as it might not be clear why some serializers generated absolute URLs, and others do not.
|
||||
|
||||
From version 2.2 onwards, serializers with hyperlinked relationships *always* require a `'request'` key to be supplied in the context dictionary. The implicit behavior will continue to function, but its use will raise a `PendingDeprecationWarning`.
|
||||
|
||||
[xordoquy]: https://github.com/xordoquy
|
||||
[django-python-3]: https://docs.djangoproject.com/en/stable/faq/install/#can-i-use-django-with-python-3
|
||||
[porting-python-3]: https://docs.djangoproject.com/en/stable/topics/python3/
|
||||
[python-compat]: https://docs.djangoproject.com/en/stable/releases/1.5/#python-compatibility
|
||||
[django-deprecation-policy]: https://docs.djangoproject.com/en/stable/internals/release-process/#internal-release-deprecation-policy
|
||||
[credits]: http://www.django-rest-framework.org/topics/credits
|
||||
[mailing-list]: https://groups.google.com/forum/?fromgroups#!forum/django-rest-framework
|
||||
[django-rest-framework-docs]: https://github.com/marcgibbons/django-rest-framework-docs
|
||||
[marcgibbons]: https://github.com/marcgibbons/
|
||||
[564]: https://github.com/encode/django-rest-framework/issues/564
|
||||
|
|
@ -1,264 +0,0 @@
|
|||
# Django REST framework 2.3
|
||||
|
||||
REST framework 2.3 makes it even quicker and easier to build your Web APIs.
|
||||
|
||||
## ViewSets and Routers
|
||||
|
||||
The 2.3 release introduces the [ViewSet][viewset] and [Router][router] classes.
|
||||
|
||||
A viewset is simply a type of class-based view that allows you to group multiple views into a single common class.
|
||||
|
||||
Routers allow you to automatically determine the URLconf for your viewset classes.
|
||||
|
||||
As an example of just how simple REST framework APIs can now be, here's an API written in a single `urls.py` module:
|
||||
|
||||
"""
|
||||
A REST framework API for viewing and editing users and groups.
|
||||
"""
|
||||
from django.conf.urls.defaults import url, include
|
||||
from django.contrib.auth.models import User, Group
|
||||
from rest_framework import viewsets, routers
|
||||
|
||||
|
||||
# ViewSets define the view behavior.
|
||||
class UserViewSet(viewsets.ModelViewSet):
|
||||
model = User
|
||||
|
||||
class GroupViewSet(viewsets.ModelViewSet):
|
||||
model = Group
|
||||
|
||||
|
||||
# Routers provide an easy way of automatically determining the URL conf
|
||||
router = routers.DefaultRouter()
|
||||
router.register(r'users', UserViewSet)
|
||||
router.register(r'groups', GroupViewSet)
|
||||
|
||||
|
||||
# Wire up our API using automatic URL routing.
|
||||
# Additionally, we include login URLs for the browsable API.
|
||||
urlpatterns = [
|
||||
url(r'^', include(router.urls)),
|
||||
url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework'))
|
||||
]
|
||||
|
||||
The best place to get started with ViewSets and Routers is to take a look at the [newest section in the tutorial][part-6], which demonstrates their usage.
|
||||
|
||||
## Simpler views
|
||||
|
||||
This release rationalises the API and implementation of the generic views, dropping the dependency on Django's `SingleObjectMixin` and `MultipleObjectMixin` classes, removing a number of unneeded attributes, and generally making the implementation more obvious and easy to work with.
|
||||
|
||||
This improvement is reflected in improved documentation for the `GenericAPIView` base class, and should make it easier to determine how to override methods on the base class if you need to write customized subclasses.
|
||||
|
||||
## Easier Serializers
|
||||
|
||||
REST framework lets you be totally explicit regarding how you want to represent relationships, allowing you to choose between styles such as hyperlinking or primary key relationships.
|
||||
|
||||
The ability to specify exactly how you want to represent relationships is powerful, but it also introduces complexity. In order to keep things more simple, REST framework now allows you to include reverse relationships simply by including the field name in the `fields` metadata of the serializer class.
|
||||
|
||||
For example, in REST framework 2.2, reverse relationships needed to be included explicitly on a serializer class.
|
||||
|
||||
class BlogSerializer(serializers.ModelSerializer):
|
||||
comments = serializers.PrimaryKeyRelatedField(many=True)
|
||||
|
||||
class Meta:
|
||||
model = Blog
|
||||
fields = ('id', 'title', 'created', 'comments')
|
||||
|
||||
As of 2.3, you can simply include the field name, and the appropriate serializer field will automatically be used for the relationship.
|
||||
|
||||
class BlogSerializer(serializers.ModelSerializer):
|
||||
"""
|
||||
Don't need to specify the 'comments' field explicitly anymore.
|
||||
"""
|
||||
class Meta:
|
||||
model = Blog
|
||||
fields = ('id', 'title', 'created', 'comments')
|
||||
|
||||
Similarly, you can now easily include the primary key in hyperlinked relationships, simply by adding the field name to the metadata.
|
||||
|
||||
class BlogSerializer(serializers.HyperlinkedModelSerializer):
|
||||
"""
|
||||
This is a hyperlinked serializer, which default to using
|
||||
a field named 'url' as the primary identifier.
|
||||
Note that we can now easily also add in the 'id' field.
|
||||
"""
|
||||
class Meta:
|
||||
model = Blog
|
||||
fields = ('url', 'id', 'title', 'created', 'comments')
|
||||
|
||||
## More flexible filtering
|
||||
|
||||
The `FILTER_BACKEND` setting has moved to pending deprecation, in favor of a `DEFAULT_FILTER_BACKENDS` setting that takes a *list* of filter backend classes, instead of a single filter backend class.
|
||||
|
||||
The generic view `filter_backend` attribute has also been moved to pending deprecation in favor of a `filter_backends` setting.
|
||||
|
||||
Being able to specify multiple filters will allow for more flexible, powerful behavior. New filter classes to handle searching and ordering of results are planned to be released shortly.
|
||||
|
||||
---
|
||||
|
||||
# API Changes
|
||||
|
||||
## Simplified generic view classes
|
||||
|
||||
The functionality provided by `SingleObjectAPIView` and `MultipleObjectAPIView` base classes has now been moved into the base class `GenericAPIView`. The implementation of this base class is simple enough that providing subclasses for the base classes of detail and list views is somewhat unnecessary.
|
||||
|
||||
Additionally the base generic view no longer inherits from Django's `SingleObjectMixin` or `MultipleObjectMixin` classes, simplifying the implementation, and meaning you don't need to cross-reference across to Django's codebase.
|
||||
|
||||
Using the `SingleObjectAPIView` and `MultipleObjectAPIView` base classes continues to be supported, but will raise a `PendingDeprecationWarning`. You should instead simply use `GenericAPIView` as the base for any generic view subclasses.
|
||||
|
||||
### Removed attributes
|
||||
|
||||
The following attributes and methods, were previously present as part of Django's generic view implementations, but were unneeded and unused and have now been entirely removed.
|
||||
|
||||
* context_object_name
|
||||
* get_context_data()
|
||||
* get_context_object_name()
|
||||
|
||||
The following attributes and methods, which were previously present as part of Django's generic view implementations have also been entirely removed.
|
||||
|
||||
* paginator_class
|
||||
* get_paginator()
|
||||
* get_allow_empty()
|
||||
* get_slug_field()
|
||||
|
||||
There may be cases when removing these bits of API might mean you need to write a little more code if your view has highly customized behavior, but generally we believe that providing a coarser-grained API will make the views easier to work with, and is the right trade-off to make for the vast majority of cases.
|
||||
|
||||
Note that the listed attributes and methods have never been a documented part of the REST framework API, and as such are not covered by the deprecation policy.
|
||||
|
||||
### Simplified methods
|
||||
|
||||
The `get_object` and `get_paginate_by` methods no longer take an optional queryset argument. This makes overridden these methods more obvious, and a little more simple.
|
||||
|
||||
Using an optional queryset with these methods continues to be supported, but will raise a `PendingDeprecationWarning`.
|
||||
|
||||
The `paginate_queryset` method no longer takes a `page_size` argument, or returns a four-tuple of pagination information. Instead it simply takes a queryset argument, and either returns a `page` object with an appropriate page size, or returns `None`, if pagination is not configured for the view.
|
||||
|
||||
Using the `page_size` argument is still supported and will trigger the old-style return type, but will raise a `PendingDeprecationWarning`.
|
||||
|
||||
### Deprecated attributes
|
||||
|
||||
The following attributes are used to control queryset lookup, and have all been moved into a pending deprecation state.
|
||||
|
||||
* pk_url_kwarg = 'pk'
|
||||
* slug_url_kwarg = 'slug'
|
||||
* slug_field = 'slug'
|
||||
|
||||
Their usage is replaced with a single attribute:
|
||||
|
||||
* lookup_field = 'pk'
|
||||
|
||||
This attribute is used both as the regex keyword argument in the URL conf, and as the model field to filter against when looking up a model instance. To use non-pk based lookup, simply set the `lookup_field` argument to an alternative field, and ensure that the keyword argument in the url conf matches the field name.
|
||||
|
||||
For example, a view with 'username' based lookup might look like this:
|
||||
|
||||
class UserDetail(generics.RetrieveAPIView):
|
||||
lookup_field = 'username'
|
||||
queryset = User.objects.all()
|
||||
serializer_class = UserSerializer
|
||||
|
||||
And would have the following entry in the urlconf:
|
||||
|
||||
url(r'^users/(?P<username>\w+)/$', UserDetail.as_view()),
|
||||
|
||||
Usage of the old-style attributes continues to be supported, but will raise a `PendingDeprecationWarning`.
|
||||
|
||||
The `allow_empty` attribute is also deprecated. To use `allow_empty=False` style behavior you should explicitly override `get_queryset` and raise an `Http404` on empty querysets.
|
||||
|
||||
For example:
|
||||
|
||||
class DisallowEmptyQuerysetMixin(object):
|
||||
def get_queryset(self):
|
||||
queryset = super(DisallowEmptyQuerysetMixin, self).get_queryset()
|
||||
if not queryset.exists():
|
||||
raise Http404
|
||||
return queryset
|
||||
|
||||
In our opinion removing lesser-used attributes like `allow_empty` helps us move towards simpler generic view implementations, making them more obvious to use and override, and re-enforcing the preferred style of developers writing their own base classes and mixins for custom behavior rather than relying on the configurability of the generic views.
|
||||
|
||||
## Simpler URL lookups
|
||||
|
||||
The `HyperlinkedRelatedField` class now takes a single optional `lookup_field` argument, that replaces the `pk_url_kwarg`, `slug_url_kwarg`, and `slug_field` arguments.
|
||||
|
||||
For example, you might have a field that references it's relationship by a hyperlink based on a slug field:
|
||||
|
||||
account = HyperlinkedRelatedField(read_only=True,
|
||||
lookup_field='slug',
|
||||
view_name='account-detail')
|
||||
|
||||
Usage of the old-style attributes continues to be supported, but will raise a `PendingDeprecationWarning`.
|
||||
|
||||
## FileUploadParser
|
||||
|
||||
2.3 adds a `FileUploadParser` parser class, that supports raw file uploads, in addition to the existing multipart upload support.
|
||||
|
||||
## DecimalField
|
||||
|
||||
2.3 introduces a `DecimalField` serializer field, which returns `Decimal` instances.
|
||||
|
||||
For most cases APIs using model fields will behave as previously, however if you are using a custom renderer, not provided by REST framework, then you may now need to add support for rendering `Decimal` instances to your renderer implementation.
|
||||
|
||||
## ModelSerializers and reverse relationships
|
||||
|
||||
The support for adding reverse relationships to the `fields` option on a `ModelSerializer` class means that the `get_related_field` and `get_nested_field` method signatures have now changed.
|
||||
|
||||
In the unlikely event that you're providing a custom serializer class, and implementing these methods you should note the new call signature for both methods is now `(self, model_field, related_model, to_many)`. For reverse relationships `model_field` will be `None`.
|
||||
|
||||
The old-style signature will continue to function but will raise a `PendingDeprecationWarning`.
|
||||
|
||||
## View names and descriptions
|
||||
|
||||
The mechanics of how the names and descriptions used in the browsable API are generated has been modified and cleaned up somewhat.
|
||||
|
||||
If you've been customizing this behavior, for example perhaps to use `rst` markup for the browsable API, then you'll need to take a look at the implementation to see what updates you need to make.
|
||||
|
||||
Note that the relevant methods have always been private APIs, and the docstrings called them out as intended to be deprecated.
|
||||
|
||||
---
|
||||
|
||||
# Other notes
|
||||
|
||||
## More explicit style
|
||||
|
||||
The usage of `model` attribute in generic Views is still supported, but it's usage is generally being discouraged throughout the documentation, in favour of the setting the more explicit `queryset` and `serializer_class` attributes.
|
||||
|
||||
For example, the following is now the recommended style for using generic views:
|
||||
|
||||
class AccountListView(generics.RetrieveAPIView):
|
||||
queryset = MyModel.objects.all()
|
||||
serializer_class = MyModelSerializer
|
||||
|
||||
Using an explicit `queryset` and `serializer_class` attributes makes the functioning of the view more clear than using the shortcut `model` attribute.
|
||||
|
||||
It also makes the usage of the `get_queryset()` or `get_serializer_class()` methods more obvious.
|
||||
|
||||
class AccountListView(generics.RetrieveAPIView):
|
||||
serializer_class = MyModelSerializer
|
||||
|
||||
def get_queryset(self):
|
||||
"""
|
||||
Determine the queryset dynamically, depending on the
|
||||
user making the request.
|
||||
|
||||
Note that overriding this method follows on more obviously now
|
||||
that an explicit `queryset` attribute is the usual view style.
|
||||
"""
|
||||
return self.user.accounts
|
||||
|
||||
## Django 1.3 support
|
||||
|
||||
The 2.3.x release series will be the last series to provide compatibility with Django 1.3.
|
||||
|
||||
## Version 2.2 API changes
|
||||
|
||||
All API changes in 2.2 that previously raised `PendingDeprecationWarning` will now raise a `DeprecationWarning`, which is loud by default.
|
||||
|
||||
## What comes next?
|
||||
|
||||
* Support for read-write nested serializers is almost complete, and due to be released in the next few weeks.
|
||||
* Extra filter backends for searching and ordering of results are planned to be added shortly.
|
||||
|
||||
The next few months should see a renewed focus on addressing outstanding tickets. The 2.4 release is currently planned for around August-September.
|
||||
|
||||
[viewset]: ../api-guide/viewsets.md
|
||||
[router]: ../api-guide/routers.md
|
||||
[part-6]: ../tutorial/6-viewsets-and-routers.md
|
||||
|
|
@ -1,172 +0,0 @@
|
|||
# Django REST framework 2.4
|
||||
|
||||
The 2.4 release is largely an intermediate step, tying up some outstanding issues prior to the 3.x series.
|
||||
|
||||
## Version requirements
|
||||
|
||||
Support for Django 1.3 has been dropped.
|
||||
The lowest supported version of Django is now 1.4.2.
|
||||
|
||||
The current plan is for REST framework to remain in lockstep with [Django's long-term support policy][lts-releases].
|
||||
|
||||
## Django 1.7 support
|
||||
|
||||
The optional authtoken application now includes support for *both* Django 1.7 schema migrations, *and* for old-style `south` migrations.
|
||||
|
||||
**If you are using authtoken, and you want to continue using `south`, you must upgrade your `south` package to version 1.0.**
|
||||
|
||||
## Deprecation of `.model` view attribute
|
||||
|
||||
The `.model` attribute on view classes is an optional shortcut for either or both of `.serializer_class` and `.queryset`. Its usage results in more implicit, less obvious behavior.
|
||||
|
||||
The documentation has previously stated that usage of the more explicit style is prefered, and we're now taking that one step further and deprecating the usage of the `.model` shortcut.
|
||||
|
||||
Doing so will mean that there are cases of API code where you'll now need to include a serializer class where you previously were just using the `.model` shortcut. However we firmly believe that it is the right trade-off to make.
|
||||
|
||||
Removing the shortcut takes away an unnecessary layer of abstraction, and makes your codebase more explicit without any significant extra complexity. It also results in better consistency, as there's now only one way to set the serializer class and queryset attributes for the view, instead of two.
|
||||
|
||||
The `DEFAULT_MODEL_SERIALIZER_CLASS` API setting is now also deprecated.
|
||||
|
||||
## Updated test runner
|
||||
|
||||
We now have a new test runner for developing against the project,, that uses the excellent [py.test](https://docs.pytest.org/) library.
|
||||
|
||||
To use it make sure you have first installed the test requirements.
|
||||
|
||||
pip install -r requirements-test.txt
|
||||
|
||||
Then run the `runtests.py` script.
|
||||
|
||||
./runtests.py
|
||||
|
||||
The new test runner also includes [flake8](https://flake8.readthedocs.io) code linting, which should help keep our coding style consistent.
|
||||
|
||||
#### Test runner flags
|
||||
|
||||
Run using a more concise output style.
|
||||
|
||||
./runtests -q
|
||||
|
||||
Run the tests using a more concise output style, no coverage, no flake8.
|
||||
|
||||
./runtests --fast
|
||||
|
||||
Don't run the flake8 code linting.
|
||||
|
||||
./runtests --nolint
|
||||
|
||||
Only run the flake8 code linting, don't run the tests.
|
||||
|
||||
./runtests --lintonly
|
||||
|
||||
Run the tests for a given test case.
|
||||
|
||||
./runtests MyTestCase
|
||||
|
||||
Run the tests for a given test method.
|
||||
|
||||
./runtests MyTestCase.test_this_method
|
||||
|
||||
Shorter form to run the tests for a given test method.
|
||||
|
||||
./runtests test_this_method
|
||||
|
||||
Note: The test case and test method matching is fuzzy and will sometimes run other tests that contain a partial string match to the given command line input.
|
||||
|
||||
## Improved viewset routing
|
||||
|
||||
The `@action` and `@link` decorators were inflexible in that they only allowed additional routes to be added against instance style URLs, not against list style URLs.
|
||||
|
||||
The `@action` and `@link` decorators have now been moved to pending deprecation, and the `@list_route` and `@detail_route` decorators have been introduced.
|
||||
|
||||
Here's an example of using the new decorators. Firstly we have a detail-type route named "set_password" that acts on a single instance, and takes a `pk` argument in the URL. Secondly we have a list-type route named "recent_users" that acts on a queryset, and does not take any arguments in the URL.
|
||||
|
||||
class UserViewSet(viewsets.ModelViewSet):
|
||||
"""
|
||||
A viewset that provides the standard actions
|
||||
"""
|
||||
queryset = User.objects.all()
|
||||
serializer_class = UserSerializer
|
||||
|
||||
@detail_route(methods=['post'])
|
||||
def set_password(self, request, pk=None):
|
||||
user = self.get_object()
|
||||
serializer = PasswordSerializer(data=request.DATA)
|
||||
if serializer.is_valid():
|
||||
user.set_password(serializer.data['password'])
|
||||
user.save()
|
||||
return Response({'status': 'password set'})
|
||||
else:
|
||||
return Response(serializer.errors,
|
||||
status=status.HTTP_400_BAD_REQUEST)
|
||||
|
||||
@list_route()
|
||||
def recent_users(self, request):
|
||||
recent_users = User.objects.all().order('-last_login')
|
||||
page = self.paginate_queryset(recent_users)
|
||||
serializer = self.get_pagination_serializer(page)
|
||||
return Response(serializer.data)
|
||||
|
||||
For more details, see the [viewsets documentation](../api-guide/viewsets.md).
|
||||
|
||||
## Throttle behavior
|
||||
|
||||
There's one bugfix in 2.4 that's worth calling out, as it will *invalidate existing throttle caches* when you upgrade.
|
||||
|
||||
We've now fixed a typo on the `cache_format` attribute. Previously this was named `"throtte_%(scope)s_%(ident)s"`, it is now `"throttle_%(scope)s_%(ident)s"`.
|
||||
|
||||
If you're concerned about the invalidation you have two options.
|
||||
|
||||
* Manually pre-populate your cache with the fixed version.
|
||||
* Set the `cache_format` attribute on your throttle class in order to retain the previous incorrect spelling.
|
||||
|
||||
## Other features
|
||||
|
||||
There are also a number of other features and bugfixes as [listed in the release notes][2-4-release-notes]. In particular these include:
|
||||
|
||||
[Customizable view name and description functions][view-name-and-description-settings] for use with the browsable API, by using the `VIEW_NAME_FUNCTION` and `VIEW_DESCRIPTION_FUNCTION` settings.
|
||||
|
||||
Smarter [client IP identification for throttling][client-ip-identification], with the addition of the `NUM_PROXIES` setting.
|
||||
|
||||
Added the standardized `Retry-After` header to throttled responses, as per [RFC 6585](https://tools.ietf.org/html/rfc6585). This should now be used in preference to the custom `X-Throttle-Wait-Seconds` header which will be fully deprecated in 3.0.
|
||||
|
||||
## Deprecations
|
||||
|
||||
All API changes in 2.3 that previously raised `PendingDeprecationWarning` will now raise a `DeprecationWarning`, which is loud by default.
|
||||
|
||||
All API changes in 2.3 that previously raised `DeprecationWarning` have now been removed entirely.
|
||||
|
||||
Furter details on these deprecations is available in the [2.3 announcement][2-3-announcement].
|
||||
|
||||
## Labels and milestones
|
||||
|
||||
Although not strictly part of the 2.4 release it's also worth noting here that we've been working hard towards improving our triage process.
|
||||
|
||||
The [labels that we use in GitHub][github-labels] have been cleaned up, and all existing tickets triaged. Any given ticket should have one and only one label, indicating its current state.
|
||||
|
||||
We've also [started using milestones][github-milestones] in order to track tickets against particular releases.
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
**Above**: *Overview of our current use of labels and milestones in GitHub.*
|
||||
|
||||
---
|
||||
|
||||
We hope both of these changes will help make the management process more clear and obvious and help keep tickets well-organised and relevant.
|
||||
|
||||
## Next steps
|
||||
|
||||
The next planned release will be 3.0, featuring an improved and simplified serializer implementation.
|
||||
|
||||
Once again, many thanks to all the generous [backers and sponsors][kickstarter-sponsors] who've helped make this possible!
|
||||
|
||||
[lts-releases]: https://docs.djangoproject.com/en/stable/internals/release-process/#long-term-support-lts-releases
|
||||
[2-4-release-notes]: release-notes#240
|
||||
[view-name-and-description-settings]: ../api-guide/settings#view-names-and-descriptions
|
||||
[client-ip-identification]: ../api-guide/throttling#how-clients-are-identified
|
||||
[2-3-announcement]: 2.3-announcement
|
||||
[github-labels]: https://github.com/encode/django-rest-framework/issues
|
||||
[github-milestones]: https://github.com/encode/django-rest-framework/milestones
|
||||
[kickstarter-sponsors]: kickstarter-announcement#sponsors
|
||||
|
|
@ -1,97 +0,0 @@
|
|||
# Django REST framework 2.0
|
||||
|
||||
> Most people just make the mistake that it should be simple to design simple things. In reality, the effort required to design something is inversely proportional to the simplicity of the result.
|
||||
>
|
||||
> — [Roy Fielding][cite]
|
||||
|
||||
---
|
||||
|
||||
**Announcement:** REST framework 2 released - Tue 30th Oct 2012
|
||||
|
||||
---
|
||||
|
||||
REST framework 2 is an almost complete reworking of the original framework, which comprehensively addresses some of the original design issues.
|
||||
|
||||
Because the latest version should be considered a re-release, rather than an incremental improvement, we've skipped a version, and called this release Django REST framework 2.0.
|
||||
|
||||
This article is intended to give you a flavor of what REST framework 2 is, and why you might want to give it a try.
|
||||
|
||||
## User feedback
|
||||
|
||||
Before we get cracking, let's start with the hard sell, with a few bits of feedback from some early adopters…
|
||||
|
||||
"Django REST framework 2 is beautiful. Some of the API design is worthy of @kennethreitz." - [Kit La Touche][quote1]
|
||||
|
||||
"Since it's pretty much just Django, controlling things like URLs has been a breeze... I think [REST framework 2] has definitely got the right approach here; even simple things like being able to override a function called post to do custom work during rather than having to intimately know what happens during a post make a huge difference to your productivity." - [Ian Strachan][quote2]
|
||||
|
||||
"I switched to the 2.0 branch and I don't regret it - fully refactored my code in another ½ day and it's *much* more to my tastes" - [Bruno Desthuilliers][quote3]
|
||||
|
||||
Sounds good, right? Let's get into some details...
|
||||
|
||||
## Serialization
|
||||
|
||||
REST framework 2 includes a totally re-worked serialization engine, that was initially intended as a replacement for Django's existing inflexible fixture serialization, and which meets the following design goals:
|
||||
|
||||
* A declarative serialization API, that mirrors Django's `Forms`/`ModelForms` API.
|
||||
* Structural concerns are decoupled from encoding concerns.
|
||||
* Able to support rendering and parsing to many formats, including both machine-readable representations and HTML forms.
|
||||
* Validation that can be mapped to obvious and comprehensive error responses.
|
||||
* Serializers that support both nested, flat, and partially-nested representations.
|
||||
* Relationships that can be expressed as primary keys, hyperlinks, slug fields, and other custom representations.
|
||||
|
||||
Mapping between the internal state of the system and external representations of that state is the core concern of building Web APIs. Designing serializers that allow the developer to do so in a flexible and obvious way is a deceptively difficult design task, and with the new serialization API we think we've pretty much nailed it.
|
||||
|
||||
## Generic views
|
||||
|
||||
When REST framework was initially released at the start of 2011, the current Django release was version 1.2. REST framework included a backport of Django 1.3's upcoming `View` class, but it didn't take full advantage of the generic view implementations.
|
||||
|
||||
With the new release the generic views in REST framework now tie in with Django's generic views. The end result is that framework is clean, lightweight and easy to use.
|
||||
|
||||
## Requests, Responses & Views
|
||||
|
||||
REST framework 2 includes `Request` and `Response` classes, than are used in place of Django's existing `HttpRequest` and `HttpResponse` classes. Doing so allows logic such as parsing the incoming request or rendering the outgoing response to be supported transparently by the framework.
|
||||
|
||||
The `Request`/`Response` approach leads to a much cleaner API, less logic in the view itself, and a simple, obvious request-response cycle.
|
||||
|
||||
REST framework 2 also allows you to work with both function-based and class-based views. For simple API views all you need is a single `@api_view` decorator, and you're good to go.
|
||||
|
||||
|
||||
## API Design
|
||||
|
||||
Pretty much every aspect of REST framework has been reworked, with the aim of ironing out some of the design flaws of the previous versions. Each of the components of REST framework are cleanly decoupled, and can be used independently of each-other, and there are no monolithic resource classes, overcomplicated mixin combinations, or opinionated serialization or URL routing decisions.
|
||||
|
||||
## The Browsable API
|
||||
|
||||
Django REST framework's most unique feature is the way it is able to serve up both machine-readable representations, and a fully browsable HTML representation to the same endpoints.
|
||||
|
||||
Browsable Web APIs are easier to work with, visualize and debug, and generally makes it easier and more frictionless to inspect and work with.
|
||||
|
||||
With REST framework 2, the browsable API gets a snazzy new bootstrap-based theme that looks great and is even nicer to work with.
|
||||
|
||||
There are also some functionality improvements - actions such as as `POST` and `DELETE` will only display if the user has the appropriate permissions.
|
||||
|
||||
![Browsable API][image]
|
||||
|
||||
**Image above**: An example of the browsable API in REST framework 2
|
||||
|
||||
## Documentation
|
||||
|
||||
As you can see the documentation for REST framework has been radically improved. It gets a completely new style, using markdown for the documentation source, and a bootstrap-based theme for the styling.
|
||||
|
||||
We're really pleased with how the docs style looks - it's simple and clean, is easy to navigate around, and we think it reads great.
|
||||
|
||||
## Summary
|
||||
|
||||
In short, we've engineered the hell outta this thing, and we're incredibly proud of the result.
|
||||
|
||||
If you're interested please take a browse around the documentation. [The tutorial][tut] is a great place to get started.
|
||||
|
||||
There's also a [live sandbox version of the tutorial API][sandbox] available for testing.
|
||||
|
||||
[cite]: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724
|
||||
[quote1]: https://twitter.com/kobutsu/status/261689665952833536
|
||||
[quote2]: https://groups.google.com/d/msg/django-rest-framework/heRGHzG6BWQ/ooVURgpwVC0J
|
||||
[quote3]: https://groups.google.com/d/msg/django-rest-framework/flsXbvYqRoY/9lSyntOf5cUJ
|
||||
[image]: ../img/quickstart.png
|
||||
[tut]: ../tutorial/1-serialization.md
|
||||
[sandbox]: https://restframework.herokuapp.com/
|
||||
|
|
@ -12,17 +12,17 @@ Nested data structures are easy enough to work with if they're read-only - simpl
|
|||
|
||||
*Example of a **read-only** nested serializer. Nothing complex to worry about here.*
|
||||
|
||||
class ToDoItemSerializer(serializers.ModelSerializer):
|
||||
class Meta:
|
||||
model = ToDoItem
|
||||
fields = ('text', 'is_completed')
|
||||
class ToDoItemSerializer(serializers.ModelSerializer):
|
||||
class Meta:
|
||||
model = ToDoItem
|
||||
fields = ('text', 'is_completed')
|
||||
|
||||
class ToDoListSerializer(serializers.ModelSerializer):
|
||||
items = ToDoItemSerializer(many=True, read_only=True)
|
||||
class ToDoListSerializer(serializers.ModelSerializer):
|
||||
items = ToDoItemSerializer(many=True, read_only=True)
|
||||
|
||||
class Meta:
|
||||
model = ToDoList
|
||||
fields = ('title', 'items')
|
||||
class Meta:
|
||||
model = ToDoList
|
||||
fields = ('title', 'items')
|
||||
|
||||
Some example output from our serializer.
|
||||
|
||||
|
|
|
|||
|
|
@ -299,18 +299,18 @@ Now we can start up a sample server that serves our snippets.
|
|||
|
||||
Quit out of the shell...
|
||||
|
||||
quit()
|
||||
quit()
|
||||
|
||||
...and start up Django's development server.
|
||||
|
||||
python manage.py runserver
|
||||
python manage.py runserver
|
||||
|
||||
Validating models...
|
||||
Validating models...
|
||||
|
||||
0 errors found
|
||||
Django version 1.11, using settings 'tutorial.settings'
|
||||
Development server is running at http://127.0.0.1:8000/
|
||||
Quit the server with CONTROL-C.
|
||||
0 errors found
|
||||
Django version 1.11, using settings 'tutorial.settings'
|
||||
Development server is running at http://127.0.0.1:8000/
|
||||
Quit the server with CONTROL-C.
|
||||
|
||||
In another terminal window, we can test the server.
|
||||
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ We'll also add a couple of views to `views.py`. We'd like to just use read-only
|
|||
|
||||
Make sure to also import the `UserSerializer` class
|
||||
|
||||
from snippets.serializers import UserSerializer
|
||||
from snippets.serializers import UserSerializer
|
||||
|
||||
Finally we need to add those views into the API, by referencing them from the URL conf. Add the following to the patterns in `snippets/urls.py`.
|
||||
|
||||
|
|
|
|||
37
mkdocs.yml
37
mkdocs.yml
|
|
@ -59,21 +59,22 @@ pages:
|
|||
- 'Browser Enhancements': 'topics/browser-enhancements.md'
|
||||
- 'The Browsable API': 'topics/browsable-api.md'
|
||||
- 'REST, Hypermedia & HATEOAS': 'topics/rest-hypermedia-hateoas.md'
|
||||
- 'Third Party Packages': 'topics/third-party-packages.md'
|
||||
- 'Tutorials and Resources': 'topics/tutorials-and-resources.md'
|
||||
- 'Contributing to REST framework': 'topics/contributing.md'
|
||||
- 'Project management': 'topics/project-management.md'
|
||||
- 'Jobs': 'topics/jobs.md'
|
||||
- '3.0 Announcement': 'topics/3.0-announcement.md'
|
||||
- '3.1 Announcement': 'topics/3.1-announcement.md'
|
||||
- '3.2 Announcement': 'topics/3.2-announcement.md'
|
||||
- '3.3 Announcement': 'topics/3.3-announcement.md'
|
||||
- '3.4 Announcement': 'topics/3.4-announcement.md'
|
||||
- '3.5 Announcement': 'topics/3.5-announcement.md'
|
||||
- '3.6 Announcement': 'topics/3.6-announcement.md'
|
||||
- '3.7 Announcement': 'topics/3.7-announcement.md'
|
||||
- '3.8 Announcement': 'topics/3.8-announcement.md'
|
||||
- 'Kickstarter Announcement': 'topics/kickstarter-announcement.md'
|
||||
- 'Mozilla Grant': 'topics/mozilla-grant.md'
|
||||
- 'Funding': 'topics/funding.md'
|
||||
- 'Release Notes': 'topics/release-notes.md'
|
||||
- Community:
|
||||
- 'Tutorials and Resources': 'community/tutorials-and-resources.md'
|
||||
- 'Third Party Packages': 'community/third-party-packages.md'
|
||||
- 'Contributing to REST framework': 'community/contributing.md'
|
||||
- 'Project management': 'community/project-management.md'
|
||||
- 'Release Notes': 'community/release-notes.md'
|
||||
- '3.8 Announcement': 'community/3.8-announcement.md'
|
||||
- '3.7 Announcement': 'community/3.7-announcement.md'
|
||||
- '3.6 Announcement': 'community/3.6-announcement.md'
|
||||
- '3.5 Announcement': 'community/3.5-announcement.md'
|
||||
- '3.4 Announcement': 'community/3.4-announcement.md'
|
||||
- '3.3 Announcement': 'community/3.3-announcement.md'
|
||||
- '3.2 Announcement': 'community/3.2-announcement.md'
|
||||
- '3.1 Announcement': 'community/3.1-announcement.md'
|
||||
- '3.0 Announcement': 'community/3.0-announcement.md'
|
||||
- 'Kickstarter Announcement': 'community/kickstarter-announcement.md'
|
||||
- 'Mozilla Grant': 'community/mozilla-grant.md'
|
||||
- 'Funding': 'community/funding.md'
|
||||
- 'Jobs': 'community/jobs.md'
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user