diff options
Diffstat (limited to 'docs/topics')
| -rw-r--r-- | docs/topics/2.2-announcement.md | 159 | ||||
| -rw-r--r-- | docs/topics/ajax-csrf-cors.md | 41 | ||||
| -rw-r--r-- | docs/topics/browsable-api.md | 7 | ||||
| -rw-r--r-- | docs/topics/browser-enhancements.md | 16 | ||||
| -rw-r--r-- | docs/topics/credits.md | 51 | ||||
| -rw-r--r-- | docs/topics/csrf.md | 12 | ||||
| -rw-r--r-- | docs/topics/release-notes.md | 124 |
7 files changed, 384 insertions, 26 deletions
diff --git a/docs/topics/2.2-announcement.md b/docs/topics/2.2-announcement.md new file mode 100644 index 00000000..d7164ce4 --- /dev/null +++ b/docs/topics/2.2-announcement.md @@ -0,0 +1,159 @@ +# REST framework 2.2 announcement + +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 implict "`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 signatute `.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 seperated into two seperate 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 it's 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 fallback 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 it's use will raise a `PendingDeprecationWarning`. + +[xordoquy]: https://github.com/xordoquy +[django-python-3]: https://docs.djangoproject.com/en/dev/faq/install/#can-i-use-django-with-python-3 +[porting-python-3]: https://docs.djangoproject.com/en/dev/topics/python3/ +[python-compat]: https://docs.djangoproject.com/en/dev/releases/1.5/#python-compatibility +[django-deprecation-policy]: https://docs.djangoproject.com/en/dev/internals/release-process/#internal-release-deprecation-policy +[credits]: http://django-rest-framework.org/topics/credits.html +[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/ +[issues]: https://github.com/tomchristie/django-rest-framework/issues +[564]: https://github.com/tomchristie/django-rest-framework/issues/564 diff --git a/docs/topics/ajax-csrf-cors.md b/docs/topics/ajax-csrf-cors.md new file mode 100644 index 00000000..f7d12940 --- /dev/null +++ b/docs/topics/ajax-csrf-cors.md @@ -0,0 +1,41 @@ +# Working with AJAX, CSRF & CORS + +> "Take a close look at possible CSRF / XSRF vulnerabilities on your own websites. They're the worst kind of vulnerability — very easy to exploit by attackers, yet not so intuitively easy to understand for software developers, at least until you've been bitten by one." +> +> — [Jeff Atwood][cite] + +## Javascript clients + +If your building a javascript client to interface with your Web API, you'll need to consider if the client can use the same authentication policy that is used by the rest of the website, and also determine if you need to use CSRF tokens or CORS headers. + +AJAX requests that are made within the same context as the API they are interacting with will typically use `SessionAuthentication`. This ensures that once a user has logged in, any AJAX requests made can be authenticated using the same session-based authentication that is used for the rest of the website. + +AJAX requests that are made on a different site from the API they are communicating with will typically need to use a non-session-based authentication scheme, such as `TokenAuthentication`. + +## CSRF protection + +[Cross Site Request Forgery][csrf] protection is a mechanism of guarding against a particular type of attack, which can occur when a user has not logged out of a web site, and continues to have a valid session. In this circumstance a malicious site may be able to perform actions against the target site, within the context of the logged-in session. + +To guard against these type of attacks, you need to do two things: + +1. Ensure that the 'safe' HTTP operations, such as `GET`, `HEAD` and `OPTIONS` cannot be used to alter any server-side state. +2. Ensure that any 'unsafe' HTTP operations, such as `POST`, `PUT`, `PATCH` and `DELETE`, always require a valid CSRF token. + +If you're using `SessionAuthentication` you'll need to include valid CSRF tokens for any `POST`, `PUT`, `PATCH` or `DELETE` operations. + +The Django documentation describes how to [include CSRF tokens in AJAX requests][csrf-ajax]. + +## CORS + +[Cross-Origin Resource Sharing][cors] is a mechanism for allowing clients to interact with APIs that are hosted on a different domain. CORS works by requiring the server to include a specific set of headers that allow a browser to determine if and when cross-domain requests should be allowed. + +The best way to deal with CORS in REST framework is to add the required response headers in middleware. This ensures that CORS is supported transparently, without having to change any behavior in your views. + +[Otto Yiu][ottoyiu] maintains the [django-cors-headers] package, which is known to work correctly with REST framework APIs. + +[cite]: http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html +[csrf]: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) +[csrf-ajax]: https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax +[cors]: http://www.w3.org/TR/cors/ +[ottoyiu]: https://github.com/ottoyiu/ +[django-cors-headers]: https://github.com/ottoyiu/django-cors-headers/ diff --git a/docs/topics/browsable-api.md b/docs/topics/browsable-api.md index 9fe82e69..5f80c4f9 100644 --- a/docs/topics/browsable-api.md +++ b/docs/topics/browsable-api.md @@ -35,23 +35,20 @@ A suitable replacement theme can be generated using Bootstrap's [Customize Tool] You can also change the navbar variant, which by default is `navbar-inverse`, using the `bootstrap_navbar_variant` block. The empty `{% block bootstrap_navbar_variant %}{% endblock %}` will use the original Bootstrap navbar style. -For more specific CSS tweaks, use the `extra_style` block instead. +For more specific CSS tweaks, use the `style` block instead. ### Blocks All of the blocks available in the browsable API base template that can be used in your `api.html`. -* `blockbots` - `<meta>` tag that blocks crawlers * `bodyclass` - (empty) class attribute for the `<body>` * `bootstrap_theme` - CSS for the Bootstrap theme * `bootstrap_navbar_variant` - CSS class for the navbar * `branding` - section of the navbar, see [Bootstrap components][bcomponentsnav] * `breadcrumbs` - Links showing resource nesting, allowing the user to go back up the resources. It's recommended to preserve these, but they can be overridden using the breadcrumbs block. -* `extrastyle` - (empty) extra CSS for the page -* `extrahead` - (empty) extra markup for the page `<head>` * `footer` - Any copyright notices or similar footer materials can go here (by default right-aligned) -* `global_heading` - (empty) Use to insert content below the header but before the breadcrumbs. +* `style` - CSS stylesheets for the page * `title` - title of the page * `userlinks` - This is a list of links on the right of the header, by default containing login/logout links. To add links instead of replace, use {{ block.super }} to preserve the authentication links. diff --git a/docs/topics/browser-enhancements.md b/docs/topics/browser-enhancements.md index 6a11f0fa..ce07fe95 100644 --- a/docs/topics/browser-enhancements.md +++ b/docs/topics/browser-enhancements.md @@ -19,6 +19,21 @@ For example, given the following form: `request.method` would return `"DELETE"`. +## HTTP header based method overriding + +REST framework also supports method overriding via the semi-standard `X-HTTP-Method-Override` header. This can be useful if you are working with non-form content such as JSON and are working with an older web server and/or hosting provider that doesn't recognise particular HTTP methods such as `PATCH`. For example [Amazon Web Services ELB][aws_elb]. + +To use it, make a `POST` request, setting the `X-HTTP-Method-Override` header. + +For example, making a `PATCH` request via `POST` in jQuery: + + $.ajax({ + url: '/myresource/', + method: 'POST', + headers: {'X-HTTP-Method-Override': 'PATCH'}, + ... + }); + ## Browser based submission of non-form content Browser-based submission of content types other than form are supported by @@ -62,3 +77,4 @@ as well as how to support content types other than form-encoded data. [rails]: http://guides.rubyonrails.org/form_helpers.html#how-do-forms-with-put-or-delete-methods-work [html5]: http://www.w3.org/TR/html5-diff/#changes-2010-06-24 [put_delete]: http://amundsen.com/examples/put-delete-forms/ +[aws_elb]: https://forums.aws.amazon.com/thread.jspa?messageID=400724 diff --git a/docs/topics/credits.md b/docs/topics/credits.md index b0b00c12..b533daa9 100644 --- a/docs/topics/credits.md +++ b/docs/topics/credits.md @@ -4,7 +4,7 @@ The following people have helped make REST framework great. * Tom Christie - [tomchristie] * Marko Tibold - [markotibold] -* Paul Bagwell - [pbgwl] +* Paul Miller - [paulmillr] * Sébastien Piquemal - [sebpiq] * Carmen Wick - [cwick] * Alex Ehlke - [aehlke] @@ -19,7 +19,7 @@ The following people have helped make REST framework great. * Craig Blaszczyk - [jakul] * Garcia Solero - [garciasolero] * Tom Drummond - [devioustree] -* Danilo Bargen - [gwrtheyrn] +* Danilo Bargen - [dbrgn] * Andrew McCloud - [amccloud] * Thomas Steinacher - [thomasst] * Meurig Freeman - [meurig] @@ -91,6 +91,27 @@ The following people have helped make REST framework great. * Richard Wackerbarth - [wackerbarth] * Johannes Spielmann - [shezi] * James Cleveland - [radiosilence] +* Steve Gregory - [steve-gregory] +* Federico Capoano - [nemesisdesign] +* Bruno Renié - [brutasse] +* Kevin Stone - [kevinastone] +* Guglielmo Celata - [guglielmo] +* Mike Tums - [mktums] +* Michael Elovskikh - [wronglink] +* Michał Jaworski - [swistakm] +* Andrea de Marco - [z4r] +* Fernando Rocha - [fernandogrd] +* Xavier Ordoquy - [xordoquy] +* Adam Wentz - [floppya] +* Andreas Pelme - [pelme] +* Ryan Detzel - [ryanrdetzel] +* Omer Katz - [thedrow] +* Wiliam Souza - [waa] +* Jonas Braun - [iekadou] +* Ian Dash - [bitmonkey] +* Bouke Haarsma - [bouke] +* Pierre Dulac - [dulaccc] +* Dave Kuhn - [kuhnza] Many thanks to everyone who's contributed to the project. @@ -114,7 +135,6 @@ For usage questions please see the [REST framework discussion group][group]. You can also contact [@_tomchristie][twitter] directly on twitter. -[email]: mailto:tom@tomchristie.com [twitter]: http://twitter.com/_tomchristie [bootstrap]: http://twitter.github.com/bootstrap/ [markdown]: http://daringfireball.net/projects/markdown/ @@ -130,7 +150,7 @@ You can also contact [@_tomchristie][twitter] directly on twitter. [tomchristie]: https://github.com/tomchristie [markotibold]: https://github.com/markotibold -[pbgwl]: https://github.com/pbgwl +[paulmillr]: https://github.com/paulmillr [sebpiq]: https://github.com/sebpiq [cwick]: https://github.com/cwick [aehlke]: https://github.com/aehlke @@ -145,7 +165,7 @@ You can also contact [@_tomchristie][twitter] directly on twitter. [jakul]: https://github.com/jakul [garciasolero]: https://github.com/garciasolero [devioustree]: https://github.com/devioustree -[gwrtheyrn]: https://github.com/gwrtheyrn +[dbrgn]: https://github.com/dbrgn [amccloud]: https://github.com/amccloud [thomasst]: https://github.com/thomasst [meurig]: https://github.com/meurig @@ -217,3 +237,24 @@ You can also contact [@_tomchristie][twitter] directly on twitter. [wackerbarth]: https://github.com/wackerbarth [shezi]: https://github.com/shezi [radiosilence]: https://github.com/radiosilence +[steve-gregory]: https://github.com/steve-gregory +[nemesisdesign]: https://github.com/nemesisdesign +[brutasse]: https://github.com/brutasse +[kevinastone]: https://github.com/kevinastone +[guglielmo]: https://github.com/guglielmo +[mktums]: https://github.com/mktums +[wronglink]: https://github.com/wronglink +[swistakm]: https://github.com/swistakm +[z4r]: https://github.com/z4r +[fernandogrd]: https://github.com/fernandogrd +[xordoquy]: https://github.com/xordoquy +[floppya]: https://github.com/floppya +[pelme]: https://github.com/pelme +[ryanrdetzel]: https://github.com/ryanrdetzel +[thedrow]: https://github.com/thedrow +[waa]: https://github.com/wiliamsouza +[iekadou]: https://github.com/iekadou +[bitmonkey]: https://github.com/bitmonkey +[bouke]: https://github.com/bouke +[dulaccc]: https://github.com/dulaccc +[kuhnza]: https://github.com/kuhnza diff --git a/docs/topics/csrf.md b/docs/topics/csrf.md deleted file mode 100644 index 043144c1..00000000 --- a/docs/topics/csrf.md +++ /dev/null @@ -1,12 +0,0 @@ -# Working with AJAX and CSRF - -> "Take a close look at possible CSRF / XSRF vulnerabilities on your own websites. They're the worst kind of vulnerability -- very easy to exploit by attackers, yet not so intuitively easy to understand for software developers, at least until you've been bitten by one." -> -> — [Jeff Atwood][cite] - -* Explain need to add CSRF token to AJAX requests. -* Explain deferred CSRF style used by REST framework -* Why you should use Django's standard login/logout views, and not REST framework view - - -[cite]: http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html diff --git a/docs/topics/release-notes.md b/docs/topics/release-notes.md index f43dc1d3..c45fff88 100644 --- a/docs/topics/release-notes.md +++ b/docs/topics/release-notes.md @@ -8,29 +8,140 @@ Minor version numbers (0.0.x) are used for changes that are API compatible. You should be able to upgrade between minor point releases without any other code changes. -Medium version numbers (0.x.0) may include minor API changes. You should read the release notes carefully before upgrading between medium point releases. +Medium version numbers (0.x.0) may include API changes, in line with the [deprecation policy][deprecation-policy]. You should read the release notes carefully before upgrading between medium point releases. -Major version numbers (x.0.0) are reserved for project milestones. No major point releases are currently planned. +Major version numbers (x.0.0) are reserved for substantial project milestones. No major point releases are currently planned. + +## Deprecation policy + +REST framework releases follow a formal deprecation policy, which is in line with [Django's deprecation policy][django-deprecation-policy]. + +The timeline for deprecation of a feature present in version 1.0 would work as follows: + +* Version 1.1 would remain **fully backwards compatible** with 1.0, but would raise `PendingDeprecationWarning` warnings if you use the feature 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 1.2 would escalate these warnings to `DeprecationWarning`, which is loud by default. + +* Version 1.3 would 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. + +## Upgrading + +To upgrade Django REST framework to the latest version, use pip: + + pip install -U djangorestframework + +You can determine your currently installed version using `pip freeze`: + + pip freeze | grep djangorestframework --- -## 2.1.x series +## 2.2.x series ### Master +* `Serializer.save()` now supports arbitrary keyword args which are passed through to the object `.save()` method. Mixins use `force_insert` and `force_update` where appropriate, resulting in one less database query. + +### 2.2.4 + +**Date**: 13th March 2013 + +* OAuth 2 support. +* OAuth 1.0a support. +* Support X-HTTP-Method-Override header. +* Filtering backends are now applied to the querysets for object lookups as well as lists. (Eg you can use a filtering backend to control which objects should 404) +* Deal with error data nicely when deserializing lists of objects. +* Extra override hook to configure `DjangoModelPermissions` for unauthenticated users. +* Bugfix: Fix regression which caused extra database query on paginated list views. +* Bugfix: Fix pk relationship bug for some types of 1-to-1 relations. +* Bugfix: Workaround for Django bug causing case where `Authtoken` could be registered for cascade delete from `User` even if not installed. + +### 2.2.3 + +**Date**: 7th March 2013 + +* Bugfix: Fix None values for for `DateField`, `DateTimeField` and `TimeField`. + +### 2.2.2 + +**Date**: 6th March 2013 + +* Support for custom input and output formats for `DateField`, `DateTimeField` and `TimeField`. +* Cleanup: Request authentication is no longer lazily evaluated, instead authentication is always run, which results in more consistent, obvious behavior. Eg. Supplying bad auth credentials will now always return an error response, even if no permissions are set on the view. +* Bugfix for serializer data being uncacheable with pickle protocol 0. +* Bugfixes for model field validation edge-cases. +* Bugfix for authtoken migration while using a custom user model and south. + +### 2.2.1 + +**Date**: 22nd Feb 2013 + +* Security fix: Use `defusedxml` package to address XML parsing vulnerabilities. +* Raw data tab added to browseable API. (Eg. Allow for JSON input.) +* Added TimeField. +* Serializer fields can be mapped to any method that takes no args, or only takes kwargs which have defaults. +* Unicode support for view names/descriptions in browseable API. +* Bugfix: request.DATA should return an empty `QueryDict` with no data, not `None`. +* Bugfix: Remove unneeded field validation, which caused extra queries. + +**Security note**: Following the [disclosure of security vulnerabilities][defusedxml-announce] in Python's XML parsing libraries, use of the `XMLParser` class now requires the `defusedxml` package to be installed. + +The security vulnerabilities only affect APIs which use the `XMLParser` class, by enabling it in any views, or by having it set in the `DEFAULT_PARSER_CLASSES` setting. Note that the `XMLParser` class is not enabled by default, so this change should affect a minority of users. + +### 2.2.0 + +**Date**: 13th Feb 2013 + +* Python 3 support. +* Added a `post_save()` hook to the generic views. +* Allow serializers to handle dicts as well as objects. +* Deprecate `ManyRelatedField()` syntax in favor of `RelatedField(many=True)` +* Deprecate `null=True` on relations in favor of `required=False`. +* Deprecate `blank=True` on CharFields, just use `required=False`. +* Deprecate optional `obj` argument in permissions checks in favor of `has_object_permission`. +* Deprecate implicit hyperlinked relations behavior. +* Bugfix: Fix broken DjangoModelPermissions. +* Bugfix: Allow serializer output to be cached. +* Bugfix: Fix styling on browsable API login. +* Bugfix: Fix issue with deserializing empty to-many relations. +* Bugfix: Ensure model field validation is still applied for ModelSerializer subclasses with an custom `.restore_object()` method. + +**Note**: See the [2.2 announcement][2.2-announcement] for full details. + +--- + +## 2.1.x series + +### 2.1.17 + +**Date**: 26th Jan 2013 + +* Support proper 401 Unauthorized responses where appropriate, instead of always using 403 Forbidden. * Support json encoding of timedelta objects. +* `format_suffix_patterns()` now supports `include` style URL patterns. +* Bugfix: Fix issues with custom pagination serializers. +* Bugfix: Nested serializers now accept `source='*'` argument. +* Bugfix: Return proper validation errors when incorrect types supplied for relational fields. +* Bugfix: Support nullable FKs with `SlugRelatedField`. +* Bugfix: Don't call custom validation methods if the field has an error. + +**Note**: If the primary authentication class is `TokenAuthentication` or `BasicAuthentication`, a view will now correctly return 401 responses to unauthenticated access, with an appropriate `WWW-Authenticate` header, instead of 403 responses. ### 2.1.16 **Date**: 14th Jan 2013 -* Deprecate django.utils.simplejson in favor of Python 2.6's built-in json module. +* Deprecate `django.utils.simplejson` in favor of Python 2.6's built-in json module. * Bugfix: `auto_now`, `auto_now_add` and other `editable=False` fields now default to read-only. * Bugfix: PK fields now only default to read-only if they are an AutoField or if `editable=False`. * Bugfix: Validation errors instead of exceptions when serializers receive incorrect types. * Bugfix: Validation errors instead of exceptions when related fields receive incorrect types. * Bugfix: Handle ObjectDoesNotExist exception when serializing null reverse one-to-one +**Note**: Prior to 2.1.16, The Decimals would render in JSON using floating point if `simplejson` was installed, but otherwise render using string notation. Now that use of `simplejson` has been deprecated, Decimals will consistently render using string notation. See [#582] for more details. + ### 2.1.15 **Date**: 3rd Jan 2013 @@ -319,7 +430,12 @@ This change will not affect user code, so long as it's following the recommended * Initial release. [cite]: http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html +[deprecation-policy]: #deprecation-policy +[django-deprecation-policy]: https://docs.djangoproject.com/en/dev/internals/release-process/#internal-release-deprecation-policy +[defusedxml-announce]: http://blog.python.org/2013/02/announcing-defusedxml-fixes-for-xml.html +[2.2-announcement]: 2.2-announcement.md [staticfiles14]: https://docs.djangoproject.com/en/1.4/howto/static-files/#with-a-template-tag [staticfiles13]: https://docs.djangoproject.com/en/1.3/howto/static-files/#with-a-template-tag [2.1.0-notes]: https://groups.google.com/d/topic/django-rest-framework/Vv2M0CMY9bg/discussion [announcement]: rest-framework-2-announcement.md +[#582]: https://github.com/tomchristie/django-rest-framework/issues/582 |