diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 698029959..b963a4993 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -14,7 +14,7 @@ If you use REST framework, we'd love you to be vocal about your experiences with 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. +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. ## Code of conduct @@ -33,12 +33,12 @@ Some tips on good issue reporting: * When describing 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 will help us quickly identify if there is a valid issue, and make sure that it gets fixed more quickly if there is one. -* Feature requests will often be closed with a recommendation that they be implemented outside of the core REST framework library. Keeping new feature requests implemented as third party libraries allows us to keep down the maintainence overhead of REST framework, so that the focus can be on continued stability, bugfixes, and great documentation. +* Feature requests will often be closed with a recommendation that they be implemented outside of the core REST framework library. Keeping new feature requests implemented as third party libraries allows us to keep down the maintenance overhead of REST framework, so that the focus can be on continued stability, bugfixes, and great documentation. * Closing an issue doesn't necessarily mean the end of a discussion. If you believe your issue has been closed incorrectly, explain why and we'll consider if it needs to be reopened. ## Triaging issues -Getting involved in triaging incoming issues is a good way to start contributing. Every single ticket that comes into the ticket tracker needs to be reviewed in order to determine what the next steps should be. Anyone can help out with this, you just need to be willing to +Getting involved in triaging incoming issues is a good way to start contributing. Every single ticket that comes into the ticket tracker needs to be reviewed in order to determine what the next steps should be. Anyone can help out with this, you just need to be willing to * Read through the ticket - does it make sense, is it missing any context that would help explain it better? * Is the ticket reported in the correct place, would it be better suited as a discussion on the discussion group? @@ -62,7 +62,6 @@ To run the tests, clone the repository, and then: virtualenv env env/bin/activate pip install -r requirements.txt - pip install -r requirements-test.txt # Run the tests ./runtests.py @@ -83,7 +82,7 @@ GitHub's documentation for working on pull requests is [available here][pull-req Always run the tests before submitting pull requests, and ideally run `tox` in order to check that your modifications are compatible with both Python 2 and Python 3, and that they run properly on all supported versions of Django. -Once you've made a pull request take a look at the travis build status in the GitHub interface and make sure the tests are runnning as you'd expect. +Once you've made a pull request take a look at the travis build status in the GitHub interface and make sure the tests are running as you'd expect. ![Travis status][travis-status] @@ -130,8 +129,8 @@ There are a couple of conventions you should follow when working on the document Headers should use the hash style. For example: ### Some important topic - -The underline style should not be used. **Don't do this:** + +The underline style should not be used. **Don't do this:** Some important topic ==================== @@ -141,9 +140,9 @@ The underline style should not be used. **Don't do this:** 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. @@ -159,9 +158,9 @@ Linking in this style means you'll be able to click the hyperlink in your markdo If you want to draw attention to a note or warning, use a pair of enclosing lines, like so: --- - + **Note:** A useful documentation note. - + --- # Third party packages diff --git a/README.md b/README.md index 12c109069..8b17901c8 100644 --- a/README.md +++ b/README.md @@ -1,15 +1,15 @@ -# Django REST framework +# [Django REST framework][docs] [![build-status-image]][travis] [![pypi-version]][pypi] -**Awesome web-browseable Web APIs.** +**Awesome web-browsable Web APIs.** Full documentation for the project is available at [http://www.django-rest-framework.org][docs]. --- -**Note**: The incoming 3.0 version has now been merged to the `master` branch on GitHub. For the source of the currently available PyPI version, please see the `2.4.4` tag. +**Note**: We have now released Django REST framework 3.0. For older codebases you may want to refer to the version 2.4.4 [source code](https://github.com/tomchristie/django-rest-framework/tree/version-2.4.x), and [documentation](http://tomchristie.github.io/rest-framework-2-docs/). --- @@ -19,15 +19,15 @@ Django REST framework is a powerful and flexible toolkit for building Web APIs. Some reasons you might want to use REST framework: -* The [Web browseable API][sandbox] is a huge useability win for your developers. -* [Authentication policies][authentication] including [OAuth1a][oauth1-section] and [OAuth2][oauth2-section] through the rest-framework-oauth package. +* The [Web browsable API][sandbox] is a huge usability win for your developers. +* [Authentication policies][authentication] including optional packages for [OAuth1a][oauth1-section] and [OAuth2][oauth2-section]. * [Serialization][serializers] that supports both [ORM][modelserializer-section] and [non-ORM][serializer-section] data sources. * Customizable all the way down - just use [regular function-based views][functionview-section] if you don't need the [more][generic-views] [powerful][viewsets] [features][routers]. * [Extensive documentation][index], and [great community support][group]. There is a live example API for testing purposes, [available here][sandbox]. -**Below**: *Screenshot from the browseable API* +**Below**: *Screenshot from the browsable API* ![Screenshot][image] @@ -86,7 +86,7 @@ router.register(r'users', UserViewSet) # Wire up our API using automatic URL routing. -# Additionally, we include login URLs for the browseable API. +# Additionally, we include login URLs for the browsable API. urlpatterns = [ url(r'^', include(router.urls)), url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework')) @@ -180,7 +180,7 @@ OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -[build-status-image]: https://secure.travis-ci.org/tomchristie/django-rest-framework.png?branch=master +[build-status-image]: https://secure.travis-ci.org/tomchristie/django-rest-framework.svg?branch=master [travis]: http://travis-ci.org/tomchristie/django-rest-framework?branch=master [pypi-version]: https://pypip.in/version/djangorestframework/badge.svg [pypi]: https://pypi.python.org/pypi/djangorestframework diff --git a/docs/api-guide/fields.md b/docs/api-guide/fields.md index 391a52e52..e4ef1d4aa 100644 --- a/docs/api-guide/fields.md +++ b/docs/api-guide/fields.md @@ -310,6 +310,9 @@ Used by `ModelSerializer` to automatically generate fields if the corresponding **Signature:** `ChoiceField(choices)` - `choices` - A list of valid values, or a list of `(key, display_name)` tuples. +- `allow_blank` - If set to `True` then the empty string should be considered a valid value. If set to `False` then the empty string is considered invalid and will raise a validation error. Defaults to `False`. + +Both the `allow_blank` and `allow_null` are valid options on `ChoiceField`, although it is highly recommended that you only use one and not both. `allow_blank` should be preferred for textual choices, and `allow_null` should be preferred for numeric or other non-textual choices. ## MultipleChoiceField @@ -318,6 +321,9 @@ A field that can accept a set of zero, one or many values, chosen from a limited **Signature:** `MultipleChoiceField(choices)` - `choices` - A list of valid values, or a list of `(key, display_name)` tuples. +- `allow_blank` - If set to `True` then the empty string should be considered a valid value. If set to `False` then the empty string is considered invalid and will raise a validation error. Defaults to `False`. + +As with `ChoiceField`, both the `allow_blank` and `allow_null` options are valid, although it is highly recommended that you only use one and not both. `allow_blank` should be preferred for textual choices, and `allow_null` should be preferred for numeric or other non-textual choices. --- @@ -453,7 +459,7 @@ If you want to create a custom field, you'll need to subclass `Field` and then o The `.to_representation()` method is called to convert the initial datatype into a primitive, serializable datatype. -The `to_internal_value()` method is called to restore a primitive datatype into its internal python representation. +The `to_internal_value()` method is called to restore a primitive datatype into its internal python representation. This method should raise a `serializer.ValidationError` if the data is invalid. Note that the `WritableField` class that was present in version 2.x no longer exists. You should subclass `Field` and override `to_internal_value()` if the field supports data input. @@ -498,6 +504,53 @@ As an example, let's create a field that can be used represent the class name of """ return obj.__class__.__name__ +#### Raising validation errors + +Our `ColorField` class above currently does not perform any data validation. +To indicate invalid data, we should raise a `serializers.ValidationError`, like so: + + def to_internal_value(self, data): + if not isinstance(data, six.text_type): + msg = 'Incorrect type. Expected a string, but got %s' + raise ValidationError(msg % type(data).__name__) + + if not re.match(r'^rgb\([0-9]+,[0-9]+,[0-9]+\)$', data): + raise ValidationError('Incorrect format. Expected `rgb(#,#,#)`.') + + data = data.strip('rgb(').rstrip(')') + red, green, blue = [int(col) for col in data.split(',')] + + if any([col > 255 or col < 0 for col in (red, green, blue)]): + raise ValidationError('Value out of range. Must be between 0 and 255.') + + return Color(red, green, blue) + +The `.fail()` method is a shortcut for raising `ValidationError` that takes a message string from the `error_messages` dictionary. For example: + + default_error_messages = { + 'incorrect_type': 'Incorrect type. Expected a string, but got {input_type}', + 'incorrect_format': 'Incorrect format. Expected `rgb(#,#,#)`.', + 'out_of_range': 'Value out of range. Must be between 0 and 255.' + } + + def to_internal_value(self, data): + if not isinstance(data, six.text_type): + msg = 'Incorrect type. Expected a string, but got %s' + self.fail('incorrect_type', input_type=type(data).__name__) + + if not re.match(r'^rgb\([0-9]+,[0-9]+,[0-9]+\)$', data): + self.fail('incorrect_format') + + data = data.strip('rgb(').rstrip(')') + red, green, blue = [int(col) for col in data.split(',')] + + if any([col > 255 or col < 0 for col in (red, green, blue)]): + self.fail('out_of_range') + + return Color(red, green, blue) + +This style keeps you error messages more cleanly separated from your code, and should be preferred. + # Third party packages The following third party packages are also available. diff --git a/docs/api-guide/serializers.md b/docs/api-guide/serializers.md index 0ee80d53f..5fe6b4c29 100644 --- a/docs/api-guide/serializers.md +++ b/docs/api-guide/serializers.md @@ -96,7 +96,7 @@ If we want to be able to return complete object instances based on the validated If your object instances correspond to Django models you'll also want to ensure that these methods save the object to the database. For example, if `Comment` was a Django model, the methods might look like this: def create(self, validated_data): - return Comment.objcts.create(**validated_data) + return Comment.objects.create(**validated_data) def update(self, instance, validated_data): instance.email = validated_data.get('email', instance.email) @@ -104,7 +104,7 @@ If your object instances correspond to Django models you'll also want to ensure instance.created = validated_data.get('created', instance.created) instance.save() return instance - + Now when deserializing data, we can call `.save()` to return an object instance, based on the validated data. comment = serializer.save() @@ -113,7 +113,7 @@ Calling `.save()` will either create a new instance, or update an existing insta # .save() will create a new instance. serializer = CommentSerializer(data=data) - + # .save() will update the existing `comment` instance. serializer = CommentSerializer(comment, data=data) @@ -140,7 +140,7 @@ For example: class ContactForm(serializers.Serializer): email = serializers.EmailField() message = serializers.CharField() - + def save(self): email = self.validated_data['email'] message = self.validated_data['message'] @@ -230,7 +230,7 @@ Serializer classes can also include reusable validators that are applied to the name = serializers.CharField() room_number = serializers.IntegerField(choices=[101, 102, 103, 201]) date = serializers.DateField() - + class Meta: # Each room only has one event per day. validators = UniqueTogetherValidator( @@ -326,9 +326,9 @@ Here's an example for an `update()` method on our previous `UserSerializer` clas # would need to be handled. profile = instance.profile - user.username = validated_data.get('username', instance.username) - user.email = validated_data.get('email', instance.email) - user.save() + instance.username = validated_data.get('username', instance.username) + instance.email = validated_data.get('email', instance.email) + instance.save() profile.is_premium_member = profile_data.get( 'is_premium_member', @@ -340,7 +340,7 @@ Here's an example for an `update()` method on our previous `UserSerializer` clas ) profile.save() - return user + return instance Because the behavior of nested creates and updates can be ambiguous, and may require complex dependancies between related models, REST framework 3 requires you to always write these methods explicitly. The default `ModelSerializer` `.create()` and `.update()` methods do not include support for writable nested representations. @@ -448,7 +448,7 @@ To do so, open the Django shell, using `python manage.py shell`, then import the id = IntegerField(label='ID', read_only=True) name = CharField(allow_blank=True, max_length=100, required=False) owner = PrimaryKeyRelatedField(queryset=User.objects.all()) - + ## Specifying which fields should be included If you only want a subset of the default fields to be used in a model serializer, you can do so using `fields` or `exclude` options, just as you would with a `ModelForm`. @@ -505,6 +505,21 @@ This option should be a list or tuple of field names, and is declared as follows Model fields which have `editable=False` set, and `AutoField` fields will be set to read-only by default, and do not need to be added to the `read_only_fields` option. +--- + +**Note**: There is a special-case where a read-only field is part of a `unique_together` constraint at the model level. In this case the field is required by the serializer class in order to validate the constraint, but should also not be editable by the user. + +The right way to deal with this is to specify the field explicitly on the serializer, providing both the `read_only=True` and `default=…` keyword arguments. + +One example of this is a read-only relation to the currently authenticated `User` which is `unique_together` with another identifier. In this case you would declare the user field like so: + + user = serializers.PrimaryKeyRelatedField(read_only=True, default=serializers.CurrentUserDefault()) + +Please review the [Validators Documentation](/api-guide/validators/) for details on the [UniqueTogetherValidator](/api-guide/validators/#uniquetogethervalidator) and [CurrentUserDefault](/api-guide/validators/#currentuserdefault) classes. + +--- + + ## Specifying additional keyword arguments for fields. There is also a shortcut allowing you to specify arbitrary additional keyword arguments on fields, using the `extra_kwargs` option. Similarly to `read_only_fields` this means you do not need to explicitly declare the field on the serializer. @@ -516,7 +531,7 @@ This option is a dictionary, mapping field names to a dictionary of keyword argu model = User fields = ('email', 'username', 'password') extra_kwargs = {'password': {'write_only': True}} - + def create(self, validated_data): user = User( email=validated_data['email'], @@ -567,13 +582,13 @@ There needs to be a way of determining which views should be used for hyperlinki By default hyperlinks are expected to correspond to a view name that matches the style `'{model_name}-detail'`, and looks up the instance by a `pk` keyword argument. -You can override a URL field view name and lookup field by using either, or both of, the `view_name` and `lookup_field` options in the `extra_field_kwargs` setting, like so: +You can override a URL field view name and lookup field by using either, or both of, the `view_name` and `lookup_field` options in the `extra_kwargs` setting, like so: class AccountSerializer(serializers.HyperlinkedModelSerializer): class Meta: model = Account fields = ('account_url', 'account_name', 'users', 'created') - extra_field_kwargs = { + extra_kwargs = { 'url': {'view_name': 'accounts', 'lookup_field': 'account_name'} 'users': {'lookup_field': 'username'} } @@ -656,7 +671,7 @@ To support multiple updates you'll need to do so explicitly. When writing your m * How do you determine which instance should be updated for each item in the list of data? * How should insertions be handled? Are they invalid, or do they create new objects? * How should removals be handled? Do they imply object deletion, or removing a relationship? Should they be silently ignored, or are they invalid? -* How should ordering be handled? Does changing the position of two items imply any state change or is it ignored? +* How should ordering be handled? Does changing the position of two items imply any state change or is it ignored? Here's an example of how you might choose to implement multiple updates: @@ -689,6 +704,21 @@ Here's an example of how you might choose to implement multiple updates: It is possible that a third party package may be included alongside the 3.1 release that provides some automatic support for multiple update operations, similar to the `allow_add_remove` behavior that was present in REST framework 2. +#### Customizing ListSerializer initialization + +When a serializer with `many=True` is instantiated, we need to determine which arguments and keyword arguments should be passed to the `.__init__()` method for both the child `Serializer` class, and for the parent `ListSerializer` class. + +The default implementation is to pass all arguments to both classes, except for `validators`, and any custom keyword arguments, both of which are assumed to be intended for the child serializer class. + +Occasionally you might need to explicitly specify how the child and parent classes should be instantiated when `many=True` is passed. You can do so by using the `many_init` class method. + + @classmethod + def many_init(cls, *args, **kwargs): + # Instantiate the child serializer. + kwargs['child'] = cls() + # Instantiate the parent list serializer. + return CustomListSerializer(*args, **kwargs) + --- # BaseSerializer diff --git a/docs/api-guide/validators.md b/docs/api-guide/validators.md index f087e1914..8f5a89298 100644 --- a/docs/api-guide/validators.md +++ b/docs/api-guide/validators.md @@ -1,4 +1,4 @@ - +source: validators.py --- diff --git a/docs/api-guide/views.md b/docs/api-guide/views.md index 31c62682f..291fe7376 100644 --- a/docs/api-guide/views.md +++ b/docs/api-guide/views.md @@ -127,19 +127,26 @@ REST framework also allows you to work with regular function based views. It pr ## @api_view() -**Signature:** `@api_view(http_method_names)` +**Signature:** `@api_view(http_method_names=['GET'])` -The core of this functionality is the `api_view` decorator, which takes a list of HTTP methods that your view should respond to. For example, this is how you would write a very simple view that just manually returns some data: +The core of this functionality is the `api_view` decorator, which takes a list of HTTP methods that your view should respond to. For example, this is how you would write a very simple view that just manually returns some data: from rest_framework.decorators import api_view - @api_view(['GET']) + @api_view() def hello_world(request): return Response({"message": "Hello, world!"}) - This view will use the default renderers, parsers, authentication classes etc specified in the [settings]. +By default only `GET` methods will be accepted. Other methods will respond with "405 Method Not Allowed". To alter this behavior, specify which methods the view allows, like so: + + @api_view(['GET', 'POST']) + def hello_world(request): + if request.method == 'POST': + return Response({"message": "Got some data!", "data": request.data}) + return Response({"message": "Hello, world!"}) + ## API policy decorators To override the default settings, REST framework provides a set of additional decorators which can be added to your views. These must come *after* (below) the `@api_view` decorator. For example, to create a view that uses a [throttle][throttling] to ensure it can only be called once per day by a particular user, use the `@throttle_classes` decorator, passing a list of throttle classes: diff --git a/docs/api-guide/viewsets.md b/docs/api-guide/viewsets.md index 28186c643..3e37cef89 100644 --- a/docs/api-guide/viewsets.md +++ b/docs/api-guide/viewsets.md @@ -201,6 +201,8 @@ Note that you can use any of the standard attributes or method overrides provide def get_queryset(self): return self.request.user.accounts.all() +Note however that upon removal of the `queryset` property from your `ViewSet`, any associated [router][routers] will be unable to derive the base_name of your Model automatically, and so you you will have to specify the `base_name` kwarg as part of your [router registration][routers]. + Also note that although this class provides the complete set of create/list/retrieve/update/destroy actions by default, you can restrict the available operations by using the standard permission classes. ## ReadOnlyModelViewSet @@ -243,3 +245,4 @@ To create a base viewset class that provides `create`, `list` and `retrieve` ope By creating your own base `ViewSet` classes, you can provide common behavior that can be reused in multiple viewsets across your API. [cite]: http://guides.rubyonrails.org/routing.html +[routers]: routers.md diff --git a/docs/img/1-kuwaitnet.png b/docs/img/1-kuwaitnet.png deleted file mode 100644 index c73b68154..000000000 Binary files a/docs/img/1-kuwaitnet.png and /dev/null differ diff --git a/docs/img/autocomplete.png b/docs/img/autocomplete.png deleted file mode 100644 index 29075b257..000000000 Binary files a/docs/img/autocomplete.png and /dev/null differ diff --git a/docs/index.md b/docs/index.md index 136f344e6..502d352cb 100644 --- a/docs/index.md +++ b/docs/index.md @@ -4,13 +4,15 @@ - +

--- **Note**: This is the documentation for the **version 3.0** of REST framework. Documentation for [version 2.4](http://tomchristie.github.io/rest-framework-2-docs/) is also available. +For more details see the [3.0 release notes][3.0-announcement]. + ---

@@ -31,8 +33,8 @@ Django REST framework is a powerful and flexible toolkit that makes it easy to b Some reasons you might want to use REST framework: -* The [Web browseable API][sandbox] is a huge usability win for your developers. -* [Authentication policies][authentication] including [OAuth1a][oauth1-section] and [OAuth2][oauth2-section] through the rest-framework-oauth package. +* The [Web browsable API][sandbox] is a huge usability win for your developers. +* [Authentication policies][authentication] including optional packages for [OAuth1a][oauth1-section] and [OAuth2][oauth2-section]. * [Serialization][serializers] that supports both [ORM][modelserializer-section] and [non-ORM][serializer-section] data sources. * Customizable all the way down - just use [regular function-based views][functionview-section] if you don't need the [more][generic-views] [powerful][viewsets] [features][routers]. * [Extensive documentation][index], and [great community support][group]. @@ -127,7 +129,7 @@ Here's our project's root `urls.py` module: router.register(r'users', UserViewSet) # Wire up our API using automatic URL routing. - # Additionally, we include login URLs for the browseable API. + # Additionally, we include login URLs for the browsable API. urlpatterns = [ url(r'^', include(router.urls)), url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework')) @@ -196,6 +198,7 @@ General guides to using REST framework. * [2.2 Announcement][2.2-announcement] * [2.3 Announcement][2.3-announcement] * [2.4 Announcement][2.4-announcement] +* [3.0 Announcement][3.0-announcement] * [Kickstarter Announcement][kickstarter-announcement] * [Release Notes][release-notes] * [Credits][credits] @@ -310,6 +313,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. [2.2-announcement]: topics/2.2-announcement.md [2.3-announcement]: topics/2.3-announcement.md [2.4-announcement]: topics/2.4-announcement.md +[3.0-announcement]: topics/3.0-announcement.md [kickstarter-announcement]: topics/kickstarter-announcement.md [release-notes]: topics/release-notes.md [credits]: topics/credits.md diff --git a/docs/topics/2.2-announcement.md b/docs/topics/2.2-announcement.md index 1df52cff2..e6220f427 100644 --- a/docs/topics/2.2-announcement.md +++ b/docs/topics/2.2-announcement.md @@ -1,4 +1,4 @@ -# REST framework 2.2 announcement +# Django REST framework 2.2 The 2.2 release represents an important point for REST framework, with the addition of Python 3 support, and the introduction of an official deprecation policy. diff --git a/docs/topics/2.3-announcement.md b/docs/topics/2.3-announcement.md index 9c9f3e9f6..21d9f1dbc 100644 --- a/docs/topics/2.3-announcement.md +++ b/docs/topics/2.3-announcement.md @@ -1,4 +1,4 @@ -# REST framework 2.3 announcement +# Django REST framework 2.3 REST framework 2.3 makes it even quicker and easier to build your Web APIs. @@ -35,7 +35,7 @@ As an example of just how simple REST framework APIs can now be, here's an API w # Wire up our API using automatic URL routing. - # Additionally, we include login URLs for the browseable API. + # Additionally, we include login URLs for the browsable API. urlpatterns = [ url(r'^', include(router.urls)), url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework')) @@ -207,9 +207,9 @@ The old-style signature will continue to function but will raise a `PendingDepre ## 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. +The mechanics of how the names and descriptions used in the browsable API are generated has been modified and cleaned up somewhat. -If you've been customizing this behavior, for example perhaps to use `rst` markup for the browseable API, then you'll need to take a look at the implementation to see what updates you need to make. +If you've been customizing this behavior, for example perhaps to use `rst` markup for the browsable API, then you'll need to take a look at the implementation to see what updates you need to make. Note that the relevant methods have always been private APIs, and the docstrings called them out as intended to be deprecated. diff --git a/docs/topics/2.4-announcement.md b/docs/topics/2.4-announcement.md index f38c743c0..4ca35290c 100644 --- a/docs/topics/2.4-announcement.md +++ b/docs/topics/2.4-announcement.md @@ -1,4 +1,4 @@ -# REST framework 2.4 announcement +# Django REST framework 2.4 The 2.4 release is largely an intermediate step, tying up some outstanding issues prior to the 3.x series. diff --git a/docs/topics/3.0-announcement.md b/docs/topics/3.0-announcement.md index b32fe5102..0710766f7 100644 --- a/docs/topics/3.0-announcement.md +++ b/docs/topics/3.0-announcement.md @@ -1,14 +1,16 @@ -# REST framework 3.0 +# Django REST framework 3.0 The 3.0 release of Django REST framework is the result of almost four years of iteration and refinement. It comprehensively addresses some of the previous remaining design issues in serializers, fields and the generic views. -This release is incremental in nature. There *are* some breaking API changes, and upgrading *will* require you to read the release notes carefully, but the migration path should otherwise be relatively straightforward. +**This release is incremental in nature. There *are* some breaking API changes, and upgrading *will* require you to read the release notes carefully, but the migration path should otherwise be relatively straightforward.** The difference in quality of the REST framework API and implementation should make writing, maintaining and debugging your application far easier. -3.0 is the first of three releases that have been funded by our recent [Kickstarter campaign](kickstarter.com/projects/tomchristie/django-rest-framework-3). +3.0 is the first of three releases that have been funded by our recent [Kickstarter campaign][kickstarter]. -As ever, a huge thank you to our many [wonderful sponsors](sponsors). If you're looking for a Django gig, and want to work with smart community-minded folks, you should probably check out that list and see who's hiring. +As ever, a huge thank you to our many [wonderful sponsors][sponsors]. If you're looking for a Django gig, and want to work with smart community-minded folks, you should probably check out that list and see who's hiring. + +--- ## New features @@ -26,10 +28,18 @@ Notable features of this new release include: Significant new functionality continues to be planned for the 3.1 and 3.2 releases. These releases will correspond to the two [Kickstarter stretch goals](https://www.kickstarter.com/projects/tomchristie/django-rest-framework-3) - "Feature improvements" and "Admin interface". Further 3.x releases will present simple upgrades, without the same level of fundamental API changes necessary for the 3.0 release. -Below is an in-depth guide to the API changes and migration notes for 3.0. +--- + +#### REST framework: Under the hood. + +This talk from the [Django: Under the Hood](http://www.djangounderthehood.com/) event in Amsterdam, Nov 2014, gives some good background context on the design decisions behind 3.0. + + --- +*Below is an in-depth guide to the API changes and migration notes for 3.0.* + ## Request objects #### The `.data` and `.query_params` properties. @@ -51,6 +61,8 @@ Instead of passing the files argument separately: The usage of `request.QUERY_PARAMS` is now pending deprecation in favor of the lowercased `request.query_params`. +--- + ## Serializers #### Single-step object creation. @@ -149,7 +161,7 @@ Previously `serializers.ValidationError` error was simply a synonym for `django. The reason behind this is that Django's `ValidationError` class is intended for use with HTML forms and its API makes using it slightly awkward with nested validation errors that can occur in serializers. -For most users this change shouldn't require any updates to your codebase, but it is worth ensuring that whenever raising validation errors you are always using the `serializers.ValidationError` exception class, and not Django's built-in exception. +For most users this change shouldn't require any updates to your codebase, but it is worth ensuring that whenever raising validation errors you should prefer using the `serializers.ValidationError` exception class, and not Django's built-in exception. We strongly recommend that you use the namespaced import style of `import serializers` and not `from serializers import ValidationError` in order to avoid any potential confusion. @@ -218,7 +230,18 @@ If you absolutely need to preserve `transform_` behavior, for exampl This change also means that we no longer use the `.full_clean()` method on model instances, but instead perform all validation explicitly on the serializer. This gives a cleaner separation, and ensures that there's no automatic validation behavior on `ModelSerializer` classes that can't also be easily replicated on regular `Serializer` classes. -It's important to note that this change also means that the model `.clean()` method will not be called as part of serializer validation, as it would be if using a `ModelForm`. Use the serializer `.validate()` method to perform a final validation step on incoming data where required. +For the most part this change should be transparent. Field validation and uniqueness checks will still be run as normal, but the implementation is a little different. + +The one difference that you do need to note is that the `.clean()` method will not be called as part of serializer validation, as it would be if using a `ModelForm`. Use the serializer `.validate()` method to perform a final validation step on incoming data where required. + +There may be some cases where you really do need to keep validation logic in the model `.clean()` method, and cannot instead separate it into the serializer `.validate()`. You can do so by explicitly instantiating a model instance in the `.validate()` method. + + def validate(self, attrs): + instance = ExampleModel(**attrs) + instance.clean() + return attrs + +Again, you really should look at properly separating the validation logic out of the model method if possible, but the above might be useful in some backwards compatibility cases, or for an easy migration path. #### Writable nested serialization. @@ -524,6 +547,8 @@ The following class is an example of a generic serializer that can handle coerci # Force anything else to its string representation. output[attribute_name] = str(attribute) +--- + ## Serializer fields #### The `Field` and `ReadOnly` field classes. @@ -540,22 +565,22 @@ We now use the following: * `Field` is the base class for all fields. It does not include any default implementation for either serializing or deserializing data. * `ReadOnlyField` is a concrete implementation for read-only fields that simply returns the attribute value without modification. -#### The `required`, `allow_none`, `allow_blank` and `default` arguments. +#### The `required`, `allow_null`, `allow_blank` and `default` arguments. REST framework now has more explicit and clear control over validating empty values for fields. Previously the meaning of the `required=False` keyword argument was underspecified. In practice its use meant that a field could either be not included in the input, or it could be included, but be `None` or the empty string. -We now have a better separation, with separate `required`, `allow_none` and `allow_blank` arguments. +We now have a better separation, with separate `required`, `allow_null` and `allow_blank` arguments. The following set of arguments are used to control validation of empty values: * `required=False`: The value does not need to be present in the input, and will not be passed to `.create()` or `.update()` if it is not seen. * `default=`: The value does not need to be present in the input, and a default value will be passed to `.create()` or `.update()` if it is not seen. -* `allow_none=True`: `None` is a valid input. +* `allow_null=True`: `None` is a valid input. * `allow_blank=True`: `''` is valid input. For `CharField` and subclasses only. -Typically you'll want to use `required=False` if the corresponding model field has a default value, and additionally set either `allow_none=True` or `allow_blank=True` if required. +Typically you'll want to use `required=False` if the corresponding model field has a default value, and additionally set either `allow_null=True` or `allow_blank=True` if required. The `default` argument is also available and always implies that the field is not required to be in the input. It is unnecessary to use the `required` argument when a default is specified, and doing so will result in an error. @@ -710,10 +735,11 @@ The `UniqueTogetherValidator` should be applied to a serializer, and takes a `qu position = serializers.IntegerField() name = serializers.CharField(max_length=100) - default_validators = [UniqueTogetherValidator( - queryset=RaceResult.objects.all(), - fields=('category', 'position') - )] + class Meta: + validators = [UniqueTogetherValidator( + queryset=RaceResult.objects.all(), + fields=('category', 'position') + )] #### The `UniqueForDateValidator` classes. @@ -721,6 +747,8 @@ REST framework also now includes explicit validator classes for validating the ` These classes are documented in the [Validators](../api-guide/validators.md) section of the documentation. +--- + ## Generic views #### Simplification of view logic. @@ -769,12 +797,16 @@ The generic views now raise `ValidationFailed` exception for invalid data. This This change means that you can now easily customize the style of error responses across your entire API, without having to modify any of the generic views. +--- + ## The metadata API Behavior for dealing with `OPTIONS` requests was previously built directly into the class based views. This has now been properly separated out into a Metadata API that allows the same pluggable style as other API policies in REST framework. This makes it far easier to use a different style for `OPTIONS` responses throughout your API, and makes it possible to create third-party metadata policies. +--- + ## Serializers as HTML forms REST framework 3.0 includes templated HTML form rendering for serializers. @@ -806,6 +838,8 @@ Similarly, to use a radio button control instead of the default `select` control This API should be considered provisional, and there may be minor alterations with the incoming 3.1 release. +--- + ## API style There are some improvements in the default style we use in our API responses. @@ -899,12 +933,17 @@ Or modify it on an individual serializer field, using the `coerce_to_string` key The default JSON renderer will return float objects for un-coerced `Decimal` instances. This allows you to easily switch between string or float representations for decimals depending on your API design needs. -## Miscellaneous notes. +--- + +## Miscellaneous notes * The serializer `ChoiceField` does not currently display nested choices, as was the case in 2.4. This will be address as part of 3.1. * Due to the new templated form rendering, the 'widget' option is no longer valid. This means there's no easy way of using third party "autocomplete" widgets for rendering select inputs that contain a large number of choices. You'll either need to use a regular select or a plain text input. We may consider addressing this in 3.1 or 3.2 if there's sufficient demand. +* Some of the default validation error messages were rewritten and might no longer be pre-translated. You can still [create language files with Django][django-localization] if you wish to localize them. -## What's coming next. +--- + +## What's coming next 3.0 is an incremental release, and there are several upcoming features that will build on the baseline improvements that it makes. @@ -919,5 +958,7 @@ The 3.2 release is planned to introduce an alternative admin-style interface to You can follow development on the GitHub site, where we use [milestones to indicate planning timescales](https://github.com/tomchristie/django-rest-framework/milestones). +[kickstarter]: http://kickstarter.com/projects/tomchristie/django-rest-framework-3 [sponsors]: http://www.django-rest-framework.org/topics/kickstarter-announcement/#sponsors [mixins.py]: https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/mixins.py +[django-localization]: https://docs.djangoproject.com/en/dev/topics/i18n/translation/#localization-how-to-create-language-files diff --git a/docs/topics/contributing.md b/docs/topics/contributing.md index 99f4fc3c8..c9626ebff 100644 --- a/docs/topics/contributing.md +++ b/docs/topics/contributing.md @@ -62,7 +62,6 @@ To run the tests, clone the repository, and then: virtualenv env source env/bin/activate pip install -r requirements.txt - pip install -r requirements-test.txt # Run the tests ./runtests.py diff --git a/docs/topics/kickstarter-announcement.md b/docs/topics/kickstarter-announcement.md index 91ead751b..9f99e3e6e 100644 --- a/docs/topics/kickstarter-announcement.md +++ b/docs/topics/kickstarter-announcement.md @@ -2,7 +2,7 @@ --- - + --- @@ -43,20 +43,20 @@ We've now blazed way past all our goals, with a staggering £30,000 (~$50,000), Our platinum sponsors have each made a hugely substantial contribution to the future development of Django REST framework, and I simply can't thank them enough.

@@ -68,31 +68,31 @@ Our platinum sponsors have each made a hugely substantial contribution to the fu Our gold sponsors include companies large and small. Many thanks for their significant funding of the project and their commitment to sustainable open-source development. @@ -105,41 +105,41 @@ Our gold sponsors include companies large and small. Many thanks for their signi The serious financial contribution that our silver sponsors have made is very much appreciated. I'd like to say a particular thank you to individuals who have choosen to privately support the project at this level.
diff --git a/docs/topics/release-notes.md b/docs/topics/release-notes.md index 531875891..f00d3c54e 100644 --- a/docs/topics/release-notes.md +++ b/docs/topics/release-notes.md @@ -38,6 +38,41 @@ You can determine your currently installed version using `pip freeze`: --- +## 3.0.x series + +### 3.0.1 + +**Date**: [December 2014][3.0.1-milestone]. + +* More helpful error message when the default Serializer `create()` fails. ([#2013][gh2013]) +* Raise error when attempting to save serializer if data is not valid. ([#2098][gh2098]) +* Fix `FileUploadParser` breaks with empty file names and multiple upload handlers. ([#2109][gh2109]) +* Improve `BindingDict` to support standard dict-functions. ([#2135][gh2135], [#2163][gh2163]) +* Add `validate()` to `ListSerializer`. ([#2168][gh2168], [#2225][gh2225], [#2232][gh2232]) +* Fix JSONP renderer failing to escape some characters. ([#2169][gh2169], [#2195][gh2195]) +* Add missing default style for `FileField`. ([#2172][gh2172]) +* Actions are required when calling `ViewSet.as_view()`. ([#2175][gh2175]) +* Add `allow_blank` to `ChoiceField`. ([#2184][gh2184], [#2239][gh2239]) +* Cosmetic fixes in the HTML renderer. ([#2187][gh2187]) +* Raise error if `fields` on serializer is not a list of strings. ([#2193][gh2193], [#2213][gh2213]) +* Improve checks for nested creates and updates. ([#2194][gh2194], [#2196][gh2196]) +* `validated_attrs` argument renamed to `validated_data` in `Serializer` `create()`/`update()`. ([#2197][gh2197]) +* Remove deprecated code to reflect the dropped Django versions. ([#2200][gh2200]) +* Better serializer errors for nested writes. ([#2202][gh2202], [#2215][gh2215]) +* Fix pagination and custom permissions incompatibility. ([#2205][gh2205]) +* Raise error if `fields` on serializer is not a list of strings. ([#2213][gh2213]) +* Add missing translation markers for relational fields. ([#2231][gh2231]) +* Improve field lookup behavior for dicts/mappings. ([#2244][gh2244], [#2243][gh2243]) +* Optimized hyperlinked PK. ([#2242][gh2242]) + +### 3.0.0 + +**Date**: 1st December 2014 + +For full details see the [3.0 release announcement](3.0-announcement.md). + +--- + ## 2.4.x series ### 2.4.4 @@ -121,7 +156,7 @@ You can determine your currently installed version using `pip freeze`: * Add `UnicodeYAMLRenderer` that extends `YAMLRenderer` with unicode. * Fix `parse_header` argument convertion. * Fix mediatype detection under Python 3. -* Web browseable API now offers blank option on dropdown when the field is not required. +* Web browsable API now offers blank option on dropdown when the field is not required. * `APIException` representation improved for logging purposes. * Allow source="*" within nested serializers. * Better support for custom oauth2 provider backends. @@ -200,7 +235,7 @@ You can determine your currently installed version using `pip freeze`: * Added `MAX_PAGINATE_BY` setting and `max_paginate_by` generic view attribute. * Added `cache` attribute to throttles to allow overriding of default cache. * 'Raw data' tab in browsable API now contains pre-populated data. -* 'Raw data' and 'HTML form' tab preference in browseable API now saved between page views. +* 'Raw data' and 'HTML form' tab preference in browsable API now saved between page views. * Bugfix: `required=True` argument fixed for boolean serializer fields. * Bugfix: `client.force_authenticate(None)` should also clear session info if it exists. * Bugfix: Client sending empty string instead of file now clears `FileField`. @@ -630,3 +665,35 @@ For older release notes, [please see the GitHub repo](old-release-notes). [ticket-582]: https://github.com/tomchristie/django-rest-framework/issues/582 [rfc-6266]: http://tools.ietf.org/html/rfc6266#section-4.3 [old-release-notes]: https://github.com/tomchristie/django-rest-framework/blob/2.4.4/docs/topics/release-notes.md#04x-series +[3.0.1-milestone]: https://github.com/tomchristie/django-rest-framework/issues?q=milestone%3A%223.0.1+Release%22 + + +[gh2013]: https://github.com/tomchristie/django-rest-framework/issues/2013 +[gh2098]: https://github.com/tomchristie/django-rest-framework/issues/2098 +[gh2109]: https://github.com/tomchristie/django-rest-framework/issues/2109 +[gh2135]: https://github.com/tomchristie/django-rest-framework/issues/2135 +[gh2163]: https://github.com/tomchristie/django-rest-framework/issues/2163 +[gh2168]: https://github.com/tomchristie/django-rest-framework/issues/2168 +[gh2169]: https://github.com/tomchristie/django-rest-framework/issues/2169 +[gh2172]: https://github.com/tomchristie/django-rest-framework/issues/2172 +[gh2175]: https://github.com/tomchristie/django-rest-framework/issues/2175 +[gh2184]: https://github.com/tomchristie/django-rest-framework/issues/2184 +[gh2187]: https://github.com/tomchristie/django-rest-framework/issues/2187 +[gh2193]: https://github.com/tomchristie/django-rest-framework/issues/2193 +[gh2194]: https://github.com/tomchristie/django-rest-framework/issues/2194 +[gh2195]: https://github.com/tomchristie/django-rest-framework/issues/2195 +[gh2196]: https://github.com/tomchristie/django-rest-framework/issues/2196 +[gh2197]: https://github.com/tomchristie/django-rest-framework/issues/2197 +[gh2200]: https://github.com/tomchristie/django-rest-framework/issues/2200 +[gh2202]: https://github.com/tomchristie/django-rest-framework/issues/2202 +[gh2205]: https://github.com/tomchristie/django-rest-framework/issues/2205 +[gh2213]: https://github.com/tomchristie/django-rest-framework/issues/2213 +[gh2213]: https://github.com/tomchristie/django-rest-framework/issues/2213 +[gh2215]: https://github.com/tomchristie/django-rest-framework/issues/2215 +[gh2225]: https://github.com/tomchristie/django-rest-framework/issues/2225 +[gh2231]: https://github.com/tomchristie/django-rest-framework/issues/2231 +[gh2232]: https://github.com/tomchristie/django-rest-framework/issues/2232 +[gh2239]: https://github.com/tomchristie/django-rest-framework/issues/2239 +[gh2242]: https://github.com/tomchristie/django-rest-framework/issues/2242 +[gh2243]: https://github.com/tomchristie/django-rest-framework/issues/2243 +[gh2244]: https://github.com/tomchristie/django-rest-framework/issues/2244 diff --git a/docs/topics/rest-framework-2-announcement.md b/docs/topics/rest-framework-2-announcement.md index a7746932e..ed41bb486 100644 --- a/docs/topics/rest-framework-2-announcement.md +++ b/docs/topics/rest-framework-2-announcement.md @@ -1,6 +1,4 @@ -# Django REST framework 2 - -What it is, and why you should care. +# Django REST framework 2.0 > Most people just make the mistake that it should be simple to design simple things. In reality, the effort required to design something is inversely proportional to the simplicity of the result. > diff --git a/docs/topics/third-party-resources.md b/docs/topics/third-party-resources.md index ffb490af3..6f4df2886 100644 --- a/docs/topics/third-party-resources.md +++ b/docs/topics/third-party-resources.md @@ -1,14 +1,18 @@ # Third Party Resources +> Software ecosystems […] establish a community that further accelerates the sharing of knowledge, content, issues, expertise and skills. +> +> — [Jan Bosch][cite]. + ## About Third Party Packages Third Party Packages allow developers to share code that extends the functionality of Django REST framework, in order to support additional use-cases. -We **support**, **encourage** and **strongly favour** the creation of Third Party Packages to encapsulate new behaviour rather than adding additional functionality directly to Django REST Framework. +We **support**, **encourage** and **strongly favor** the creation of Third Party Packages to encapsulate new behavior rather than adding additional functionality directly to Django REST Framework. -We aim to make creating Third Party Packages as easy as possible, whilst keeping the **simplicity** of the core API and ensuring that **maintenance** of the main project remains under control. If a Third Party Package proves popular it is relatively easy to move it into the main project; removing features is much more problematic. +We aim to make creating third party packages as easy as possible, whilst keeping a **simple** and **well maintained** core API. By promoting third party packages we ensure that the responsibility for a package remains with its author. If a package proves suitably popular it can always be considered for inclusion into the core REST framework. -If you have an idea for a new feature please consider how it may be packaged as a Third Party Package. We're always happy to dicuss ideas on the [Mailing List][discussion-group]. +If you have an idea for a new feature please consider how it may be packaged as a Third Party Package. We're always happy to discuss ideas on the [Mailing List][discussion-group]. ## How to create a Third Party Package @@ -93,7 +97,7 @@ The cookiecutter template includes a `runtests.py` which uses the `pytest` packa Before running, you'll need to install a couple test requirements. - $ pip install -r requirements-test.txt + $ pip install -r requirements.txt Once requirements installed, you can run `runtests.py`. @@ -260,7 +264,7 @@ To submit new content, [open an issue][drf-create-issue] or [create a pull reque * [Web API performance: profiling Django REST framework][web-api-performance-profiling-django-rest-framework] * [API Development with Django and Django REST Framework][api-development-with-django-and-django-rest-framework] - +[cite]: http://www.software-ecosystems.com/Software_Ecosystems/Ecosystems.html [cookiecutter]: https://github.com/jpadilla/cookiecutter-django-rest-framework [new-repo]: https://github.com/new [create-a-repo]: https://help.github.com/articles/create-a-repo/ diff --git a/docs/tutorial/1-serialization.md b/docs/tutorial/1-serialization.md index a3c19858d..dea43cc0f 100644 --- a/docs/tutorial/1-serialization.md +++ b/docs/tutorial/1-serialization.md @@ -16,7 +16,6 @@ The tutorial is fairly in-depth, so you should probably get a cookie and a cup o Before we do anything else we'll create a new virtual environment, using [virtualenv]. This will make sure our package configuration is kept nicely isolated from any other projects we're working on. - :::bash virtualenv env source env/bin/activate @@ -75,12 +74,8 @@ For the purposes of this tutorial we're going to start by creating a simple `Sni title = models.CharField(max_length=100, blank=True, default='') code = models.TextField() linenos = models.BooleanField(default=False) - language = models.CharField(choices=LANGUAGE_CHOICES, - default='python', - max_length=100) - style = models.CharField(choices=STYLE_CHOICES, - default='friendly', - max_length=100) + language = models.CharField(choices=LANGUAGE_CHOICES, default='python', max_length=100) + style = models.CharField(choices=STYLE_CHOICES, default='friendly', max_length=100) class Meta: ordering = ('created',) @@ -101,30 +96,27 @@ The first thing we need to get started on our Web API is to provide a way of ser class SnippetSerializer(serializers.Serializer): pk = serializers.IntegerField(read_only=True) - title = serializers.CharField(required=False, - max_length=100) + title = serializers.CharField(required=False, allow_blank=True, max_length=100) code = serializers.CharField(style={'type': 'textarea'}) linenos = serializers.BooleanField(required=False) - language = serializers.ChoiceField(choices=LANGUAGE_CHOICES, - default='python') - style = serializers.ChoiceField(choices=STYLE_CHOICES, - default='friendly') + language = serializers.ChoiceField(choices=LANGUAGE_CHOICES, default='python') + style = serializers.ChoiceField(choices=STYLE_CHOICES, default='friendly') - def create(self, validated_attrs): + def create(self, validated_data): """ Create and return a new `Snippet` instance, given the validated data. """ - return Snippet.objects.create(**validated_attrs) + return Snippet.objects.create(**validated_data) - def update(self, instance, validated_attrs): + def update(self, instance, validated_data): """ Update and return an existing `Snippet` instance, given the validated data. """ - instance.title = validated_attrs.get('title', instance.title) - instance.code = validated_attrs.get('code', instance.code) - instance.linenos = validated_attrs.get('linenos', instance.linenos) - instance.language = validated_attrs.get('language', instance.language) - instance.style = validated_attrs.get('style', instance.style) + instance.title = validated_data.get('title', instance.title) + instance.code = validated_data.get('code', instance.code) + instance.linenos = validated_data.get('linenos', instance.linenos) + instance.language = validated_data.get('language', instance.language) + instance.style = validated_data.get('style', instance.style) instance.save() return instance @@ -181,7 +173,9 @@ Deserialization is similar. First we parse a stream into Python native datatype serializer = SnippetSerializer(data=data) serializer.is_valid() # True - serializer.object + serializer.validated_data + # OrderedDict([('title', ''), ('code', 'print "hello, world"\n'), ('linenos', False), ('language', 'python'), ('style', 'friendly')]) + serializer.save() # Notice how similar the API is to working with forms. The similarity should become even more apparent when we start writing views that use our serializer. @@ -210,7 +204,7 @@ One nice property that serializers have is that you can inspect all the fields i >>> from snippets.serializers import SnippetSerializer >>> serializer = SnippetSerializer() - >>> print repr(serializer) # In python 3 use `print(repr(serializer))` + >>> print(repr(serializer)) SnippetSerializer(): id = IntegerField(label='ID', read_only=True) title = CharField(allow_blank=True, max_length=100, required=False) @@ -301,7 +295,7 @@ We'll also need a view which corresponds to an individual snippet, and can be us Finally we need to wire these views up. Create the `snippets/urls.py` file: - from django.conf.urls import patterns, url + from django.conf.urls import url from snippets import views urlpatterns = [ @@ -332,17 +326,51 @@ Quit out of the shell... In another terminal window, we can test the server. -We can get a list of all of the snippets. +We can test our API using using [curl][curl] or [httpie][httpie]. Httpie is a user friendly http client that's written in Python. Let's install that. - curl http://127.0.0.1:8000/snippets/ +You can install httpie using pip: - [{"id": 1, "title": "", "code": "foo = \"bar\"\n", "linenos": false, "language": "python", "style": "friendly"}, {"id": 2, "title": "", "code": "print \"hello, world\"\n", "linenos": false, "language": "python", "style": "friendly"}] + pip install httpie -Or we can get a particular snippet by referencing its id. +Finally, we can get a list of all of the snippets: - curl http://127.0.0.1:8000/snippets/2/ + http http://127.0.0.1:8000/snippets/ - {"id": 2, "title": "", "code": "print \"hello, world\"\n", "linenos": false, "language": "python", "style": "friendly"} + HTTP/1.1 200 OK + ... + [ + { + "id": 1, + "title": "", + "code": "foo = \"bar\"\n", + "linenos": false, + "language": "python", + "style": "friendly" + }, + { + "id": 2, + "title": "", + "code": "print \"hello, world\"\n", + "linenos": false, + "language": "python", + "style": "friendly" + } + ] + +Or we can get a particular snippet by referencing its id: + + http http://127.0.0.1:8000/snippets/2/ + + HTTP/1.1 200 OK + ... + { + "id": 2, + "title": "", + "code": "print \"hello, world\"\n", + "linenos": false, + "language": "python", + "style": "friendly" + } Similarly, you can have the same json displayed by visiting these URLs in a web browser. @@ -359,3 +387,5 @@ We'll see how we can start to improve things in [part 2 of the tutorial][tut-2]. [sandbox]: http://restframework.herokuapp.com/ [virtualenv]: http://www.virtualenv.org/en/latest/index.html [tut-2]: 2-requests-and-responses.md +[httpie]: https://github.com/jakubroztocil/httpie#installation +[curl]: http://curl.haxx.se diff --git a/docs/tutorial/2-requests-and-responses.md b/docs/tutorial/2-requests-and-responses.md index 06a684b17..f416ed4c9 100644 --- a/docs/tutorial/2-requests-and-responses.md +++ b/docs/tutorial/2-requests-and-responses.md @@ -127,31 +127,64 @@ Go ahead and test the API from the command line, as we did in [tutorial part 1][ We can get a list of all of the snippets, as before. - curl http://127.0.0.1:8000/snippets/ + http http://127.0.0.1:8000/snippets/ - [{"id": 1, "title": "", "code": "foo = \"bar\"\n", "linenos": false, "language": "python", "style": "friendly"}, {"id": 2, "title": "", "code": "print \"hello, world\"\n", "linenos": false, "language": "python", "style": "friendly"}] + HTTP/1.1 200 OK + ... + [ + { + "id": 1, + "title": "", + "code": "foo = \"bar\"\n", + "linenos": false, + "language": "python", + "style": "friendly" + }, + { + "id": 2, + "title": "", + "code": "print \"hello, world\"\n", + "linenos": false, + "language": "python", + "style": "friendly" + } + ] We can control the format of the response that we get back, either by using the `Accept` header: - curl http://127.0.0.1:8000/snippets/ -H 'Accept: application/json' # Request JSON - curl http://127.0.0.1:8000/snippets/ -H 'Accept: text/html' # Request HTML + http http://127.0.0.1:8000/snippets/ Accept:application/json # Request JSON + http http://127.0.0.1:8000/snippets/ Accept:text/html # Request HTML Or by appending a format suffix: - curl http://127.0.0.1:8000/snippets/.json # JSON suffix - curl http://127.0.0.1:8000/snippets/.api # Browsable API suffix + http http://127.0.0.1:8000/snippets/.json # JSON suffix + http http://127.0.0.1:8000/snippets/.api # Browsable API suffix Similarly, we can control the format of the request that we send, using the `Content-Type` header. # POST using form data - curl -X POST http://127.0.0.1:8000/snippets/ -d "code=print 123" + http --form POST http://127.0.0.1:8000/snippets/ code="print 123" - {"id": 3, "title": "", "code": "print 123", "linenos": false, "language": "python", "style": "friendly"} + { + "id": 3, + "title": "", + "code": "print 123", + "linenos": false, + "language": "python", + "style": "friendly" + } # POST using JSON - curl -X POST http://127.0.0.1:8000/snippets/ -d '{"code": "print 456"}' -H "Content-Type: application/json" + http --json POST http://127.0.0.1:8000/snippets/ code="print 456" - {"id": 4, "title": "", "code": "print 456", "linenos": true, "language": "python", "style": "friendly"} + { + "id": 4, + "title": "", + "code": "print 456", + "linenos": true, + "language": "python", + "style": "friendly" + } Now go and open the API in a web browser, by visiting [http://127.0.0.1:8000/snippets/][devserver]. diff --git a/docs/tutorial/4-authentication-and-permissions.md b/docs/tutorial/4-authentication-and-permissions.md index 4e4edeeac..a6d27bf7e 100644 --- a/docs/tutorial/4-authentication-and-permissions.md +++ b/docs/tutorial/4-authentication-and-permissions.md @@ -43,7 +43,7 @@ And now we can add a `.save()` method to our model class: When that's all done we'll need to update our database tables. Normally we'd create a database migration in order to do that, but for the purposes of this tutorial, let's just delete the database and start again. - rm tmp.db + rm -f tmp.db db.sqlite3 rm -r snippets/migrations python manage.py makemigrations snippets python manage.py migrate @@ -59,7 +59,7 @@ Now that we've got some users to work with, we'd better add representations of t from django.contrib.auth.models import User class UserSerializer(serializers.ModelSerializer): - snippets = serializers.PrimaryKeyRelatedField(many=True) + snippets = serializers.PrimaryKeyRelatedField(many=True, queryset=Snippet.objects.all()) class Meta: model = User @@ -198,15 +198,25 @@ If we're interacting with the API programmatically we need to explicitly provide If we try to create a snippet without authenticating, we'll get an error: - curl -i -X POST http://127.0.0.1:8000/snippets/ -d "code=print 123" + http POST http://127.0.0.1:8000/snippets/ code="print 123" - {"detail": "Authentication credentials were not provided."} + { + "detail": "Authentication credentials were not provided." + } We can make a successful request by including the username and password of one of the users we created earlier. - curl -X POST http://127.0.0.1:8000/snippets/ -d "code=print 789" -u tom:password + http POST -a tom:password http://127.0.0.1:8000/snippets/ code="print 789" - {"id": 5, "owner": "tom", "title": "foo", "code": "print 789", "linenos": false, "language": "python", "style": "friendly"} + { + "id": 5, + "owner": "tom", + "title": "foo", + "code": "print 789", + "linenos": false, + "language": "python", + "style": "friendly" + } ## Summary diff --git a/docs/tutorial/5-relationships-and-hyperlinked-apis.md b/docs/tutorial/5-relationships-and-hyperlinked-apis.md index 50552616b..c21efd7f6 100644 --- a/docs/tutorial/5-relationships-and-hyperlinked-apis.md +++ b/docs/tutorial/5-relationships-and-hyperlinked-apis.md @@ -44,7 +44,7 @@ Instead of using a concrete generic view, we'll use the base class for represent As usual we need to add the new views that we've created in to our URLconf. We'll add a url pattern for our new API root in `snippets/urls.py`: - url(r'^$', 'api_root'), + url(r'^$', views.api_root), And then add a url pattern for the snippet highlights: @@ -75,7 +75,7 @@ The `HyperlinkedModelSerializer` has the following differences from `ModelSerial We can easily re-write our existing serializers to use hyperlinking. In your `snippets/serializers.py` add: class SnippetSerializer(serializers.HyperlinkedModelSerializer): - owner = serializers.Field(source='owner.username') + owner = serializers.ReadOnlyField(source='owner.username') highlight = serializers.HyperlinkedIdentityField(view_name='snippet-highlight', format='html') class Meta: @@ -85,7 +85,7 @@ We can easily re-write our existing serializers to use hyperlinking. In your `sn class UserSerializer(serializers.HyperlinkedModelSerializer): - snippets = serializers.HyperlinkedRelatedField(many=True, view_name='snippet-detail') + snippets = serializers.HyperlinkedRelatedField(many=True, view_name='snippet-detail', read_only=True) class Meta: model = User diff --git a/docs/tutorial/6-viewsets-and-routers.md b/docs/tutorial/6-viewsets-and-routers.md index 3fad509a1..816e9da69 100644 --- a/docs/tutorial/6-viewsets-and-routers.md +++ b/docs/tutorial/6-viewsets-and-routers.md @@ -112,7 +112,7 @@ Here's our re-wired `urls.py` file. router.register(r'users', views.UserViewSet) # The API URLs are now determined automatically by the router. - # Additionally, we include the login URLs for the browseable API. + # Additionally, we include the login URLs for the browsable API. urlpatterns = [ url(r'^', include(router.urls)), url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework')) @@ -130,7 +130,7 @@ That doesn't mean it's always the right approach to take. There's a similar set ## Reviewing our work -With an incredibly small amount of code, we've now got a complete pastebin Web API, which is fully web browseable, and comes complete with authentication, per-object permissions, and multiple renderer formats. +With an incredibly small amount of code, we've now got a complete pastebin Web API, which is fully web browsable, and comes complete with authentication, per-object permissions, and multiple renderer formats. We've walked through each step of the design process, and seen how if we need to customize anything we can gradually work our way down to simply using regular Django views. diff --git a/docs/tutorial/quickstart.md b/docs/tutorial/quickstart.md index 1c398c1ff..c3f959946 100644 --- a/docs/tutorial/quickstart.md +++ b/docs/tutorial/quickstart.md @@ -19,10 +19,10 @@ Create a new Django project named `tutorial`, then start a new app called `quick pip install djangorestframework # Set up a new project with a single application - django-admin.py startproject tutorial + django-admin.py startproject tutorial . cd tutorial django-admin.py startapp quickstart - cd .. + cd .. Now sync your database for the first time: @@ -100,7 +100,7 @@ Okay, now let's wire up the API URLs. On to `tutorial/urls.py`... router.register(r'groups', views.GroupViewSet) # Wire up our API using automatic URL routing. - # Additionally, we include login URLs for the browseable API. + # Additionally, we include login URLs for the browsable API. urlpatterns = [ url(r'^', include(router.urls)), url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework')) @@ -159,6 +159,33 @@ We can now access our API, both from the command-line, using tools like `curl`.. ] } +Or using the [httpie][httpie], command line tool... + + bash: http -a username:password http://127.0.0.1:8000/users/ + + HTTP/1.1 200 OK + ... + { + "count": 2, + "next": null, + "previous": null, + "results": [ + { + "email": "admin@example.com", + "groups": [], + "url": "http://localhost:8000/users/1/", + "username": "paul" + }, + { + "email": "tom@example.com", + "groups": [ ], + "url": "http://127.0.0.1:8000/users/2/", + "username": "tom" + } + ] + } + + Or directly through the browser... ![Quick start image][image] @@ -173,3 +200,4 @@ If you want to get a more in depth understanding of how REST framework fits toge [image]: ../img/quickstart.png [tutorial]: 1-serialization.md [guide]: ../#api-guide +[httpie]: https://github.com/jakubroztocil/httpie#installation diff --git a/docs_theme/base.html b/docs_theme/base.html index 25bd33ef0..b3066eb31 100644 --- a/docs_theme/base.html +++ b/docs_theme/base.html @@ -169,6 +169,7 @@ +