diff options
Diffstat (limited to 'docs/topics')
| -rw-r--r-- | docs/topics/2.2-announcement.md | 159 | ||||
| -rw-r--r-- | docs/topics/2.3-announcement.md | 264 | ||||
| -rw-r--r-- | docs/topics/ajax-csrf-cors.md | 41 | ||||
| -rw-r--r-- | docs/topics/browsable-api.md | 18 | ||||
| -rw-r--r-- | docs/topics/browser-enhancements.md | 16 | ||||
| -rw-r--r-- | docs/topics/contributing.md | 136 | ||||
| -rw-r--r-- | docs/topics/credits.md | 105 | ||||
| -rw-r--r-- | docs/topics/csrf.md | 12 | ||||
| -rw-r--r-- | docs/topics/migration.md | 89 | ||||
| -rw-r--r-- | docs/topics/release-notes.md | 270 | ||||
| -rw-r--r-- | docs/topics/rest-framework-2-announcement.md | 10 | ||||
| -rw-r--r-- | docs/topics/rest-hypermedia-hateoas.md | 2 |
12 files changed, 983 insertions, 139 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/2.3-announcement.md b/docs/topics/2.3-announcement.md new file mode 100644 index 00000000..4df9c819 --- /dev/null +++ b/docs/topics/2.3-announcement.md @@ -0,0 +1,264 @@ +# REST framework 2.3 announcement + +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, patterns, 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 browseable API. + urlpatterns = patterns('', + 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 dependancy 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 explict 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 unusedand 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 appropraite 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-inforcing 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 implmentation. + +## 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 revese 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 browseable 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 browseable 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 explict `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 explict `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 compatiblity 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 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..8ee01824 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. @@ -63,6 +60,17 @@ All of the [Bootstrap components][bcomponents] are available. The browsable API makes use of the Bootstrap tooltips component. Any element with the `js-tooltip` class and a `title` attribute has that title content displayed in a tooltip on hover after a 1000ms delay. +### Login Template + +To add branding and customize the look-and-feel of the auth login template, create a template called `login.html` and add it to your project, eg: `templates/rest_framework/login.html`, that extends the `rest_framework/base_login.html` template. + +You can add your site name or branding by including the branding block: + + {% block branding %} + <h3 style="margin: 0 0 20px;">My Site Name</h3> + {% endblock %} + +You can also customize the style by adding the `bootstrap_theme` or `style` block similar to `api.html`. ### Advanced Customization 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/contributing.md b/docs/topics/contributing.md index 7fd61c10..1d1fe892 100644 --- a/docs/topics/contributing.md +++ b/docs/topics/contributing.md @@ -4,12 +4,138 @@ > > — [Tim Berners-Lee][cite] -## Running the tests +There are many ways you can contribute to Django REST framework. We'd like it to be a community-led project, so please get involved and help shape the future of the project. -## Building the docs +# Community -## Managing compatibility issues +If you use and enjoy REST framework please consider [staring the project on GitHub][github], and [upvoting it on Django packages][django-packages]. Doing so helps potential new users see that the project is well used, and help us continue to attract new users. -**Describe compat module** +You might also consider writing a blog post on your experience with using REST framework, writing a tutorial about using the project with a particular javascript framework, or simply sharing the love on Twitter. -[cite]: http://www.w3.org/People/Berners-Lee/FAQ.html
\ No newline at end of file +Other really great ways you can help move the community forward include helping answer questions on the [discussion group][google-group], or setting up an [email alert on StackOverflow][so-filter] so that you get notified of any new questions with the `django-rest-framework` tag. + +When answering questions make sure to help future contributors find their way around by hyperlinking wherever possible to related threads and tickets, and include backlinks from those items if relevant. + +# Issues + +It's really helpful if you make sure you address issues to the correct channel. Usage questions should be directed to the [discussion group][google-group]. Feature requests, bug reports and other issues should be raised on the GitHub [issue tracker][issues]. + +Some tips on good issue reporting: + +* When decribing issues try to phrase your ticket in terms of the *behavior* you think needs changing rather than the *code* you think need changing. +* Search the issue list first for related items, and make sure you're running the latest version of REST framework before reporting an issue. +* If reporting a bug, then try to include a pull request with a failing test case. This'll help us quickly identify if there is a valid issue, and make sure that it gets fixed more quickly if there is one. + + + +* TODO: Triage + +# Development + +* git clone & PYTHONPATH +* Pep8 +* Recommend editor that runs pep8 + +### Pull requests + +* Make pull requests early +* Describe branching + +### Managing compatibility issues + +* Describe compat module + +# Testing + +* Running the tests +* tox + +# Documentation + +The documentation for REST framework is built from the [Markdown][markdown] source files in [the docs directory][docs]. + +There are many great markdown editors that make working with the documentation really easy. The [Mou editor for Mac][mou] is one such editor that comes highly recommended. + +## Building the documentation + +To build the documentation, simply run the `mkdocs.py` script. + + ./mkdocs.py + +This will build the html output into the `html` directory. + +You can build the documentation and open a preview in a browser window by using the `-p` flag. + + ./mkdocs.py -p + +## Language style + +Documentation should be in American English. The tone of the documentation is very important - try to stick to a simple, plain, objective and well-balanced style where possible. + +Some other tips: + +* Keep paragraphs reasonably short. +* Use double spacing after the end of sentences. +* Don't use the abbreviations such as 'e.g..' but instead use long form, such as 'For example'. + +## Markdown style + +There are a couple of conventions you should follow when working on the documentation. + +##### 1. Headers + +Headers should use the hash style. For example: + + ### Some important topic + +The underline style should not be used. **Don't do this:** + + Some important topic + ==================== + +##### 2. Links + +Links should always use the reference style, with the referenced hyperlinks kept at the end of the document. + + Here is a link to [some other thing][other-thing]. + + More text... + + [other-thing]: http://example.com/other/thing + +This style helps keep the documentation source consistent and readable. + +If you are hyperlinking to another REST framework document, you should use a relative link, and link to the `.md` suffix. For example: + + [authentication]: ../api-guide/authentication.md + +Linking in this style means you'll be able to click the hyperlink in your markdown editor to open the referenced document. When the documentation is built, these links will be converted into regular links to HTML pages. + +##### 3. Notes + +If you want to draw attention to a note or warning, use a pair of enclosing lines, like so: + + --- + + **Note:** Make sure you do this thing. + + --- + +# Third party packages + +* Django reusable app + +# Core committers + +* Still use pull reqs +* Credits + +[cite]: http://www.w3.org/People/Berners-Lee/FAQ.html +[github]: https://github.com/tomchristie/django-rest-framework +[django-packages]: https://www.djangopackages.com/grids/g/api/ +[google-group]: https://groups.google.com/forum/?fromgroups#!forum/django-rest-framework +[so-filter]: http://stackexchange.com/filters/66475/rest-framework +[issues]: https://github.com/tomchristie/django-rest-framework/issues?state=open +[markdown]: http://daringfireball.net/projects/markdown/basics +[docs]: https://github.com/tomchristie/django-rest-framework/tree/master/docs +[mou]: http://mouapp.com/ diff --git a/docs/topics/credits.md b/docs/topics/credits.md index 8b8cac1a..8151b4d3 100644 --- a/docs/topics/credits.md +++ b/docs/topics/credits.md @@ -2,9 +2,9 @@ The following people have helped make REST framework great. -* Tom Christie - [tomchristie] +* 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] @@ -81,6 +81,49 @@ The following people have helped make REST framework great. * Szymon Teżewski - [sunscrapers] * Joel Marcotte - [joual] * Trey Hunner - [treyhunner] +* Roman Akinfold - [akinfold] +* Toran Billups - [toranb] +* Sébastien Béal - [sebastibe] +* Andrew Hankinson - [ahankinson] +* Juan Riaza - [juanriaza] +* Michael Mior - [michaelmior] +* Marc Tamlyn - [mjtamlyn] +* 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] +* Sitong Peng - [stoneg] +* Victor Shih - [vshih] +* Atle Frenvik Sveen - [atlefren] +* J Paul Reed - [preed] +* Matt Majewski - [forgingdestiny] +* Jerome Chen - [chenjyw] +* Andrew Hughes - [eyepulp] +* Daniel Hepper - [dhepper] +* Hamish Campbell - [hamishcampbell] +* Marlon Bailey - [avinash240] +* James Summerfield - [jsummerfield] +* Andy Freeland - [rouge8] Many thanks to everyone who's contributed to the project. @@ -92,9 +135,9 @@ Project hosting is with [GitHub]. Continuous integration testing is managed with [Travis CI][travis-ci]. -The [live sandbox][sandbox] is hosted on [Heroku]. +The [live sandbox][sandbox] is hosted on [Heroku]. -Various inspiration taken from the [Piston], [Tastypie] and [Dagny] projects. +Various inspiration taken from the [Rails], [Piston], [Tastypie], [Dagny] and [django-viewsets] projects. Development of REST framework 2.0 was sponsored by [DabApps]. @@ -103,16 +146,17 @@ Development of REST framework 2.0 was sponsored by [DabApps]. 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/ [github]: https://github.com/tomchristie/django-rest-framework [travis-ci]: https://secure.travis-ci.org/tomchristie/django-rest-framework +[rails]: http://rubyonrails.org/ [piston]: https://bitbucket.org/jespern/django-piston [tastypie]: https://github.com/toastdriven/django-tastypie [dagny]: https://github.com/zacharyvoase/dagny +[django-viewsets]: https://github.com/BertrandBordage/django-viewsets [dabapps]: http://lab.dabapps.com [sandbox]: http://restframework.herokuapp.com/ [heroku]: http://www.heroku.com/ @@ -120,7 +164,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 @@ -135,7 +179,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 @@ -197,3 +241,46 @@ You can also contact [@_tomchristie][twitter] directly on twitter. [sunscrapers]: https://github.com/sunscrapers [joual]: https://github.com/joual [treyhunner]: https://github.com/treyhunner +[akinfold]: https://github.com/akinfold +[toranb]: https://github.com/toranb +[sebastibe]: https://github.com/sebastibe +[ahankinson]: https://github.com/ahankinson +[juanriaza]: https://github.com/juanriaza +[michaelmior]: https://github.com/michaelmior +[mjtamlyn]: https://github.com/mjtamlyn +[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 +[stoneg]: https://github.com/stoneg +[vshih]: https://github.com/vshih +[atlefren]: https://github.com/atlefren +[preed]: https://github.com/preed +[forgingdestiny]: https://github.com/forgingdestiny +[chenjyw]: https://github.com/chenjyw +[eyepulp]: https://github.com/eyepulp +[dhepper]: https://github.com/dhepper +[hamishcampbell]: https://github.com/hamishcampbell +[avinash240]: https://github.com/avinash240 +[jsummerfield]: https://github.com/jsummerfield +[rouge8]: https://github.com/rouge8 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/migration.md b/docs/topics/migration.md deleted file mode 100644 index 25fc9074..00000000 --- a/docs/topics/migration.md +++ /dev/null @@ -1,89 +0,0 @@ -# 2.0 Migration Guide - -> Move fast and break things -> -> — Mark Zuckerberg, [the Hacker Way][cite]. - -REST framework 2.0 introduces a radical redesign of the core components, and a large number of backwards breaking changes. - -### Serialization redesign. - -REST framework's serialization and deserialization previously used a slightly odd combination of serializers for output, and Django Forms and Model Forms for input. The serialization core has been completely redesigned based on work that was originally intended for Django core. - -2.0's form-like serializers comprehensively address those issues, and are a much more flexible and clean solution to the problems around accepting both form-based and non-form based inputs. - -### Generic views improved. - -When REST framework 0.1 was released the current Django version was 1.2. REST framework included a backport of the Django 1.3's upcoming `View` class, but it didn't take full advantage of the generic view implementations. - -As of 2.0 the generic views in REST framework tie in much more cleanly and obviously with Django's existing codebase, and the mixin architecture is radically simplified. - -### Cleaner request-response cycle. - -REST framework 2.0's request-response cycle is now much less complex. - -* Responses inherit from `SimpleTemplateResponse`, allowing rendering to be delegated to the response, not handled by the view. -* Requests extend the regular `HttpRequest`, allowing authentication and parsing to be delegated to the request, not handled by the view. - -### Renamed attributes & classes. - -Various attributes and classes have been renamed in order to fit in better with Django's conventions. - -## Example: Blog Posts API - -Let's take a look at an example from the REST framework 0.4 documentation... - - from djangorestframework.resources import ModelResource - from djangorestframework.reverse import reverse - from blogpost.models import BlogPost, Comment - - - class BlogPostResource(ModelResource): - """ - A Blog Post has a *title* and *content*, and can be associated - with zero or more comments. - """ - model = BlogPost - fields = ('created', 'title', 'slug', 'content', 'url', 'comments') - ordering = ('-created',) - - def url(self, instance): - return reverse('blog-post', - kwargs={'key': instance.key}, - request=self.request) - - def comments(self, instance): - return reverse('comments', - kwargs={'blogpost': instance.key}, - request=self.request) - - - class CommentResource(ModelResource): - """ - A Comment is associated with a given Blog Post and has a - *username* and *comment*, and optionally a *rating*. - """ - model = Comment - fields = ('username', 'comment', 'created', 'rating', 'url', 'blogpost') - ordering = ('-created',) - - def blogpost(self, instance): - return reverse('blog-post', - kwargs={'key': instance.blogpost.key}, - request=self.request) - -There's a bit of a mix of concerns going on there. We've got some information about how the data should be serialized, such as the `fields` attribute, and some information about how it should be retrieved from the database - the `ordering` attribute. - -Let's start to re-write this for REST framework 2.0. - - from rest_framework import serializers - - class BlogPostSerializer(serializers.HyperlinkedModelSerializer): - model = BlogPost - fields = ('created', 'title', 'slug', 'content', 'url', 'comments') - - class CommentSerializer(serializers.HyperlinkedModelSerializer): - model = Comment - fields = ('username', 'comment', 'created', 'rating', 'url', 'blogpost') - -[cite]: http://www.wired.com/business/2012/02/zuck-letter/ diff --git a/docs/topics/release-notes.md b/docs/topics/release-notes.md index 71fa3c03..560dd305 100644 --- a/docs/topics/release-notes.md +++ b/docs/topics/release-notes.md @@ -4,10 +4,245 @@ > > — Eric S. Raymond, [The Cathedral and the Bazaar][cite]. -## 2.1.x series +## Versioning + +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 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 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.3.x series ### Master +* Bugfix: HyperlinkedIdentityField now uses `lookup_field` kwarg. + +### 2.3.2 + +**Date**: 16th May 2013 + +* Added SearchFilter +* Added OrderingFilter +* Added GenericViewSet +* Bugfix: Multiple `@action` and `@link` methods now allowed on viewsets. +* Bugfix: Fix API Root view issue with DjangoModelPermissions + +### 2.3.2 + +**Date**: 8th May 2013 + +* Bugfix: Fix `TIME_FORMAT`, `DATETIME_FORMAT` and `DATE_FORMAT` settings. +* Bugfix: Fix `DjangoFilterBackend` issue, failing when used on view with queryset attribute. + +### 2.3.1 + +**Date**: 7th May 2013 + +* Bugfix: Fix breadcrumb rendering issue. + +### 2.3.0 + +**Date**: 7th May 2013 + +* ViewSets and Routers. +* ModelSerializers support reverse relations in 'fields' option. +* HyperLinkedModelSerializers support 'id' field in 'fields' option. +* Cleaner generic views. +* Support for multiple filter classes. +* FileUploadParser support for raw file uploads. +* DecimalField support. +* Made Login template easier to restyle. +* Bugfix: Fix issue with depth>1 on ModelSerializer. + +**Note**: See the [2.3 announcement][2.3-announcement] for full details. + +--- + +## 2.2.x series + +### 2.2.7 + +**Date**: 17th April 2013 + +* Loud failure when view does not return a `Response` or `HttpResponse`. +* Bugfix: Fix for Django 1.3 compatiblity. +* Bugfix: Allow overridden `get_object()` to work correctly. + +### 2.2.6 + +**Date**: 4th April 2013 + +* OAuth2 authentication no longer requires unneccessary URL parameters in addition to the token. +* URL hyperlinking in browsable API now handles more cases correctly. +* Long HTTP headers in browsable API are broken in multiple lines when possible. +* Bugfix: Fix regression with DjangoFilterBackend not worthing correctly with single object views. +* Bugfix: OAuth should fail hard when invalid token used. +* Bugfix: Fix serializer potentially returning `None` object for models that define `__bool__` or `__len__`. + +### 2.2.5 + +**Date**: 26th March 2013 + +* Serializer support for bulk create and bulk update operations. +* Regression fix: Date and time fields return date/time objects by default. Fixes regressions caused by 2.2.2. See [#743][743] for more details. +* Bugfix: Fix 500 error is OAuth not attempted with OAuthAuthentication class installed. +* `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 browsable 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 browsable 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. +* 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 + +* Added `PATCH` support. +* Added `RetrieveUpdateAPIView`. +* Remove unused internal `save_m2m` flag on `ModelSerializer.save()`. +* Tweak behavior of hyperlinked fields with an explicit format suffix. +* Relation changes are now persisted in `.save()` instead of in `.restore_object()`. +* Bugfix: Fix issue with FileField raising exception instead of validation error when files=None. +* Bugfix: Partial updates should not set default values if field is not included. + +### 2.1.14 + +**Date**: 31st Dec 2012 + +* Bugfix: ModelSerializers now include reverse FK fields on creation. +* Bugfix: Model fields with `blank=True` are now `required=False` by default. +* Bugfix: Nested serializers now support nullable relationships. + +**Note**: From 2.1.14 onwards, relational fields move out of the `fields.py` module and into the new `relations.py` module, in order to separate them from regular data type fields, such as `CharField` and `IntegerField`. + +This change will not affect user code, so long as it's following the recommended import style of `from rest_framework import serializers` and referring to fields using the style `serializers.PrimaryKeyRelatedField`. + + +### 2.1.13 + +**Date**: 28th Dec 2012 + +* Support configurable `STATICFILES_STORAGE` storage. * Bugfix: Related fields now respect the required flag, and may be required=False. ### 2.1.12 @@ -15,14 +250,14 @@ **Date**: 21st Dec 2012 * Bugfix: Fix bug that could occur using ChoiceField. -* Bugfix: Fix exception in browseable API on DELETE. +* Bugfix: Fix exception in browsable API on DELETE. * Bugfix: Fix issue where pk was was being set to a string if set by URL kwarg. ### 2.1.11 **Date**: 17th Dec 2012 -* Bugfix: Fix issue with M2M fields in browseable API. +* Bugfix: Fix issue with M2M fields in browsable API. ### 2.1.10 @@ -105,7 +340,7 @@ * Support use of HTML exception templates. Eg. `403.html` * Hyperlinked fields take optional `slug_field`, `slug_url_kwarg` and `pk_url_kwarg` arguments. -* Bugfix: Deal with optional trailing slashs properly when generating breadcrumbs. +* Bugfix: Deal with optional trailing slashes properly when generating breadcrumbs. * Bugfix: Make textareas same width as other fields in browsable API. * Private API change: `.get_serializer` now uses same `instance` and `data` ordering as serializer initialization. @@ -113,16 +348,16 @@ **Date**: 5th Nov 2012 -**Warning**: Please read [this thread][2.1.0-notes] regarding the `instance` and `data` keyword args before updating to 2.1.0. - * **Serializer `instance` and `data` keyword args have their position swapped.** * `queryset` argument is now optional on writable model fields. * Hyperlinked related fields optionally take `slug_field` and `slug_url_kwarg` arguments. * Support Django's cache framework. * Minor field improvements. (Don't stringify dicts, more robust many-pk fields.) -* Bugfix: Support choice field in Browseable API. +* Bugfix: Support choice field in Browsable API. * Bugfix: Related fields with `read_only=True` do not require a `queryset` argument. +**API-incompatible changes**: Please read [this thread][2.1.0-notes] regarding the `instance` and `data` keyword args before updating to 2.1.0. + --- ## 2.0.x series @@ -159,9 +394,9 @@ * Allow views to specify template used by TemplateRenderer * More consistent error responses * Some serializer fixes -* Fix internet explorer ajax behaviour +* Fix internet explorer ajax behavior * Minor xml and yaml fixes -* Improve setup (eg use staticfiles, not the defunct ADMIN_MEDIA_PREFIX) +* Improve setup (e.g. use staticfiles, not the defunct ADMIN_MEDIA_PREFIX) * Sensible absolute URL generation, not using hacky set_script_prefix --- @@ -172,13 +407,13 @@ * Added DjangoModelPermissions class to support `django.contrib.auth` style permissions. * Use `staticfiles` for css files. - - Easier to override. Won't conflict with customised admin styles (eg grappelli) + - Easier to override. Won't conflict with customized admin styles (e.g. grappelli) * Templates are now nicely namespaced. - Allows easier overriding. * Drop implied 'pk' filter if last arg in urlconf is unnamed. - - Too magical. Explict is better than implicit. -* Saner template variable autoescaping. -* Tider setup.py + - Too magical. Explicit is better than implicit. +* Saner template variable auto-escaping. +* Tidier setup.py * Updated for URLObject 2.0 * Bugfixes: - Bug with PerUserThrottling when user contains unicode chars. @@ -266,5 +501,14 @@ * 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 +[2.3-announcement]: 2.3-announcement.md +[743]: https://github.com/tomchristie/django-rest-framework/pull/743 +[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 diff --git a/docs/topics/rest-framework-2-announcement.md b/docs/topics/rest-framework-2-announcement.md index 885d1918..309548d0 100644 --- a/docs/topics/rest-framework-2-announcement.md +++ b/docs/topics/rest-framework-2-announcement.md @@ -62,19 +62,19 @@ REST framework 2 also allows you to work with both function-based and class-base 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 independantly of each-other, and there are no monolithic resource classes, overcomplicated mixin combinations, or opinionated serialization or URL routing decisions. -## The Browseable API +## 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. -Browseable Web APIs are easier to work with, visualize and debug, and generally makes it easier and more frictionless to inspect and work with. +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 browseable API gets a snazzy new bootstrap-based theme that looks great and is even nicer to 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 improvments - actions such as as `POST` and `DELETE` will only display if the user has the appropriate permissions. -![Browseable API][image] +![Browsable API][image] -**Image above**: An example of the browseable API in REST framework 2 +**Image above**: An example of the browsable API in REST framework 2 ## Documentation diff --git a/docs/topics/rest-hypermedia-hateoas.md b/docs/topics/rest-hypermedia-hateoas.md index 10ab9dfe..43e5a8c6 100644 --- a/docs/topics/rest-hypermedia-hateoas.md +++ b/docs/topics/rest-hypermedia-hateoas.md @@ -26,7 +26,7 @@ REST framework is an agnostic Web API toolkit. It does help guide you towards b ## What REST framework provides. -It is self evident that REST framework makes it possible to build Hypermedia APIs. The browseable API that it offers is built on HTML - the hypermedia language of the web. +It is self evident that REST framework makes it possible to build Hypermedia APIs. The browsable API that it offers is built on HTML - the hypermedia language of the web. REST framework also includes [serialization] and [parser]/[renderer] components that make it easy to build appropriate media types, [hyperlinked relations][fields] for building well-connected systems, and great support for [content negotiation][conneg]. |