From 330c13296de35d4055c30b5b3642421707565e2b Mon Sep 17 00:00:00 2001 From: Tom Christie Date: Tue, 25 Nov 2014 16:04:38 +0000 Subject: Update documentation --- tutorial/1-serialization.html | 539 --------------- tutorial/1-serialization/index.html | 744 +++++++++++++++++++++ tutorial/2-requests-and-responses.html | 378 ----------- tutorial/2-requests-and-responses/index.html | 573 ++++++++++++++++ tutorial/3-class-based-views.html | 370 ---------- tutorial/3-class-based-views/index.html | 550 +++++++++++++++ tutorial/4-authentication-and-permissions.html | 406 ----------- .../4-authentication-and-permissions/index.html | 607 +++++++++++++++++ tutorial/5-relationships-and-hyperlinked-apis.html | 372 ----------- .../index.html | 560 ++++++++++++++++ tutorial/6-viewsets-and-routers.html | 361 ---------- tutorial/6-viewsets-and-routers/index.html | 550 +++++++++++++++ tutorial/quickstart.html | 380 ----------- tutorial/quickstart/index.html | 571 ++++++++++++++++ 14 files changed, 4155 insertions(+), 2806 deletions(-) delete mode 100644 tutorial/1-serialization.html create mode 100644 tutorial/1-serialization/index.html delete mode 100644 tutorial/2-requests-and-responses.html create mode 100644 tutorial/2-requests-and-responses/index.html delete mode 100644 tutorial/3-class-based-views.html create mode 100644 tutorial/3-class-based-views/index.html delete mode 100644 tutorial/4-authentication-and-permissions.html create mode 100644 tutorial/4-authentication-and-permissions/index.html delete mode 100644 tutorial/5-relationships-and-hyperlinked-apis.html create mode 100644 tutorial/5-relationships-and-hyperlinked-apis/index.html delete mode 100644 tutorial/6-viewsets-and-routers.html create mode 100644 tutorial/6-viewsets-and-routers/index.html delete mode 100644 tutorial/quickstart.html create mode 100644 tutorial/quickstart/index.html (limited to 'tutorial') diff --git a/tutorial/1-serialization.html b/tutorial/1-serialization.html deleted file mode 100644 index a94ef276..00000000 --- a/tutorial/1-serialization.html +++ /dev/null @@ -1,539 +0,0 @@ - - - - - Tutorial 1: Serialization - Django REST framework - - - - - - - - - - - - - - - - - - - - -
- - - -
-
- - - - -
- - - -
-

Tutorial 1: Serialization

-

Introduction

-

This tutorial will cover creating a simple pastebin code highlighting Web API. Along the way it will introduce the various components that make up REST framework, and give you a comprehensive understanding of how everything fits together.

-

The tutorial is fairly in-depth, so you should probably get a cookie and a cup of your favorite brew before getting started. If you just want a quick overview, you should head over to the quickstart documentation instead.

-
-

Note: The code for this tutorial is available in the tomchristie/rest-framework-tutorial repository on GitHub. The completed implementation is also online as a sandbox version for testing, available here.

-
-

Setting up a new environment

-

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.

-
-virtualenv env
-source env/bin/activate
-
-

Now that we're inside a virtualenv environment, we can install our package requirements.

-
pip install django
-pip install djangorestframework
-pip install pygments  # We'll be using this for the code highlighting
-
-

Note: To exit the virtualenv environment at any time, just type deactivate. For more information see the virtualenv documentation.

-

Getting started

-

Okay, we're ready to get coding. -To get started, let's create a new project to work with.

-
cd ~
-django-admin.py startproject tutorial
-cd tutorial
-
-

Once that's done we can create an app that we'll use to create a simple Web API.

-
python manage.py startapp snippets
-
-

The simplest way to get up and running will probably be to use an sqlite3 database for the tutorial. Edit the tutorial/settings.py file, and set the default database "ENGINE" to "sqlite3", and "NAME" to "tmp.db".

-
DATABASES = {
-    'default': {
-        'ENGINE': 'django.db.backends.sqlite3',
-        'NAME': 'tmp.db',
-        'USER': '',
-        'PASSWORD': '',
-        'HOST': '',
-        'PORT': '',
-    }
-}
-
-

We'll also need to add our new snippets app and the rest_framework app to INSTALLED_APPS.

-
INSTALLED_APPS = (
-    ...
-    'rest_framework',
-    'snippets',
-)
-
-

We also need to wire up the root urlconf, in the tutorial/urls.py file, to include our snippet app's URLs.

-
urlpatterns = [
-    url(r'^', include('snippets.urls')),
-]
-
-

Okay, we're ready to roll.

-

Creating a model to work with

-

For the purposes of this tutorial we're going to start by creating a simple Snippet model that is used to store code snippets. Go ahead and edit the snippets app's models.py file. Note: Good programming practices include comments. Although you will find them in our repository version of this tutorial code, we have omitted them here to focus on the code itself.

-
from django.db import models
-from pygments.lexers import get_all_lexers
-from pygments.styles import get_all_styles
-
-LEXERS = [item for item in get_all_lexers() if item[1]]
-LANGUAGE_CHOICES = sorted([(item[1][0], item[0]) for item in LEXERS])
-STYLE_CHOICES = sorted((item, item) for item in get_all_styles())
-
-
-class Snippet(models.Model):
-    created = models.DateTimeField(auto_now_add=True)
-    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)
-
-    class Meta:
-        ordering = ('created',)
-
-

Don't forget to sync the database for the first time.

-
python manage.py makemigrations snippets
-python manage.py migrate
-

Creating a Serializer class

-

The first thing we need to get started on our Web API is to provide a way of serializing and deserializing the snippet instances into representations such as json. We can do this by declaring serializers that work very similar to Django's forms. Create a file in the snippets directory named serializers.py and add the following.

-
from django.forms import widgets
-from rest_framework import serializers
-from snippets.models import Snippet, LANGUAGE_CHOICES, STYLE_CHOICES
-
-
-class SnippetSerializer(serializers.Serializer):
-    pk = serializers.Field()  # Note: `Field` is an untyped read-only field.
-    title = serializers.CharField(required=False,
-                                  max_length=100)
-    code = serializers.CharField(widget=widgets.Textarea,
-                                 max_length=100000)
-    linenos = serializers.BooleanField(required=False)
-    language = serializers.ChoiceField(choices=LANGUAGE_CHOICES,
-                                       default='python')
-    style = serializers.ChoiceField(choices=STYLE_CHOICES,
-                                    default='friendly')
-
-    def restore_object(self, attrs, instance=None):
-        """
-        Create or update a new snippet instance, given a dictionary
-        of deserialized field values.
-
-        Note that if we don't define this method, then deserializing
-        data will simply return a dictionary of items.
-        """
-        if instance:
-            # Update existing instance
-            instance.title = attrs.get('title', instance.title)
-            instance.code = attrs.get('code', instance.code)
-            instance.linenos = attrs.get('linenos', instance.linenos)
-            instance.language = attrs.get('language', instance.language)
-            instance.style = attrs.get('style', instance.style)
-            return instance
-
-        # Create new instance
-        return Snippet(**attrs)
-
-

The first part of the serializer class defines the fields that get serialized/deserialized. The restore_object method defines how fully fledged instances get created when deserializing data.

-

Notice that we can also use various attributes that would typically be used on form fields, such as widget=widgets.Textarea. These can be used to control how the serializer should render when displayed as an HTML form. This is particularly useful for controlling how the browsable API should be displayed, as we'll see later in the tutorial.

-

We can actually also save ourselves some time by using the ModelSerializer class, as we'll see later, but for now we'll keep our serializer definition explicit.

-

Working with Serializers

-

Before we go any further we'll familiarize ourselves with using our new Serializer class. Let's drop into the Django shell.

-
python manage.py shell
-
-

Okay, once we've got a few imports out of the way, let's create a couple of code snippets to work with.

-
from snippets.models import Snippet
-from snippets.serializers import SnippetSerializer
-from rest_framework.renderers import JSONRenderer
-from rest_framework.parsers import JSONParser
-
-snippet = Snippet(code='foo = "bar"\n')
-snippet.save()
-
-snippet = Snippet(code='print "hello, world"\n')
-snippet.save()
-
-

We've now got a few snippet instances to play with. Let's take a look at serializing one of those instances.

-
serializer = SnippetSerializer(snippet)
-serializer.data
-# {'pk': 2, 'title': u'', 'code': u'print "hello, world"\n', 'linenos': False, 'language': u'python', 'style': u'friendly'}
-
-

At this point we've translated the model instance into Python native datatypes. To finalize the serialization process we render the data into json.

-
content = JSONRenderer().render(serializer.data)
-content
-# '{"pk": 2, "title": "", "code": "print \\"hello, world\\"\\n", "linenos": false, "language": "python", "style": "friendly"}'
-
-

Deserialization is similar. First we parse a stream into Python native datatypes...

-
# This import will use either `StringIO.StringIO` or `io.BytesIO`
-# as appropriate, depending on if we're running Python 2 or Python 3.
-from rest_framework.compat import BytesIO
-
-stream = BytesIO(content)
-data = JSONParser().parse(stream)
-
-

...then we restore those native datatypes into to a fully populated object instance.

-
serializer = SnippetSerializer(data=data)
-serializer.is_valid()
-# True
-serializer.object
-# <Snippet: Snippet object>
-
-

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.

-

We can also serialize querysets instead of model instances. To do so we simply add a many=True flag to the serializer arguments.

-
serializer = SnippetSerializer(Snippet.objects.all(), many=True)
-serializer.data
-# [{'pk': 1, 'title': u'', 'code': u'foo = "bar"\n', 'linenos': False, 'language': u'python', 'style': u'friendly'}, {'pk': 2, 'title': u'', 'code': u'print "hello, world"\n', 'linenos': False, 'language': u'python', 'style': u'friendly'}]
-
-

Using ModelSerializers

-

Our SnippetSerializer class is replicating a lot of information that's also contained in the Snippet model. It would be nice if we could keep our code a bit more concise.

-

In the same way that Django provides both Form classes and ModelForm classes, REST framework includes both Serializer classes, and ModelSerializer classes.

-

Let's look at refactoring our serializer using the ModelSerializer class. -Open the file snippets/serializers.py again, and edit the SnippetSerializer class.

-
class SnippetSerializer(serializers.ModelSerializer):
-    class Meta:
-        model = Snippet
-        fields = ('id', 'title', 'code', 'linenos', 'language', 'style')
-
-

Writing regular Django views using our Serializer

-

Let's see how we can write some API views using our new Serializer class. -For the moment we won't use any of REST framework's other features, we'll just write the views as regular Django views.

-

We'll start off by creating a subclass of HttpResponse that we can use to render any data we return into json.

-

Edit the snippets/views.py file, and add the following.

-
from django.http import HttpResponse
-from django.views.decorators.csrf import csrf_exempt
-from rest_framework.renderers import JSONRenderer
-from rest_framework.parsers import JSONParser
-from snippets.models import Snippet
-from snippets.serializers import SnippetSerializer
-
-class JSONResponse(HttpResponse):
-    """
-    An HttpResponse that renders its content into JSON.
-    """
-    def __init__(self, data, **kwargs):
-        content = JSONRenderer().render(data)
-        kwargs['content_type'] = 'application/json'
-        super(JSONResponse, self).__init__(content, **kwargs)
-
-

The root of our API is going to be a view that supports listing all the existing snippets, or creating a new snippet.

-
@csrf_exempt
-def snippet_list(request):
-    """
-    List all code snippets, or create a new snippet.
-    """
-    if request.method == 'GET':
-        snippets = Snippet.objects.all()
-        serializer = SnippetSerializer(snippets, many=True)
-        return JSONResponse(serializer.data)
-
-    elif request.method == 'POST':
-        data = JSONParser().parse(request)
-        serializer = SnippetSerializer(data=data)
-        if serializer.is_valid():
-            serializer.save()
-            return JSONResponse(serializer.data, status=201)
-        return JSONResponse(serializer.errors, status=400)
-
-

Note that because we want to be able to POST to this view from clients that won't have a CSRF token we need to mark the view as csrf_exempt. This isn't something that you'd normally want to do, and REST framework views actually use more sensible behavior than this, but it'll do for our purposes right now.

-

We'll also need a view which corresponds to an individual snippet, and can be used to retrieve, update or delete the snippet.

-
@csrf_exempt
-def snippet_detail(request, pk):
-    """
-    Retrieve, update or delete a code snippet.
-    """
-    try:
-        snippet = Snippet.objects.get(pk=pk)
-    except Snippet.DoesNotExist:
-        return HttpResponse(status=404)
-
-    if request.method == 'GET':
-        serializer = SnippetSerializer(snippet)
-        return JSONResponse(serializer.data)
-
-    elif request.method == 'PUT':
-        data = JSONParser().parse(request)
-        serializer = SnippetSerializer(snippet, data=data)
-        if serializer.is_valid():
-            serializer.save()
-            return JSONResponse(serializer.data)
-        return JSONResponse(serializer.errors, status=400)
-
-    elif request.method == 'DELETE':
-        snippet.delete()
-        return HttpResponse(status=204)
-
-

Finally we need to wire these views up. Create the snippets/urls.py file:

-
from django.conf.urls import patterns, url
-from snippets import views
-
-urlpatterns = [
-    url(r'^snippets/$', views.snippet_list),
-    url(r'^snippets/(?P<pk>[0-9]+)/$', views.snippet_detail),
-]
-
-

It's worth noting that there are a couple of edge cases we're not dealing with properly at the moment. If we send malformed json, or if a request is made with a method that the view doesn't handle, then we'll end up with a 500 "server error" response. Still, this'll do for now.

-

Testing our first attempt at a Web API

-

Now we can start up a sample server that serves our snippets.

-

Quit out of the shell...

-
quit()
-
-

...and start up Django's development server.

-
python manage.py runserver
-
-Validating models...
-
-0 errors found
-Django version 1.4.3, using settings 'tutorial.settings'
-Development server is running at http://127.0.0.1:8000/
-Quit the server with CONTROL-C.
-
-

In another terminal window, we can test the server.

-

We can get a list of all of the snippets.

-
curl 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"}]
-
-

Or we can get a particular snippet by referencing its id.

-
curl http://127.0.0.1:8000/snippets/2/
-
-{"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.

-

Where are we now

-

We're doing okay so far, we've got a serialization API that feels pretty similar to Django's Forms API, and some regular Django views.

-

Our API views don't do anything particularly special at the moment, beyond serving json responses, and there are some error handling edge cases we'd still like to clean up, but it's a functioning Web API.

-

We'll see how we can start to improve things in part 2 of the tutorial.

-
-
-
-
- -
-
- - - - - - - - - - - diff --git a/tutorial/1-serialization/index.html b/tutorial/1-serialization/index.html new file mode 100644 index 00000000..e861ac0a --- /dev/null +++ b/tutorial/1-serialization/index.html @@ -0,0 +1,744 @@ + + + + + + + 1 - Serialization - Django REST framework + + + + + + + + + + + + + + + + + + + + + +
+ + + +
+
+ + + + +
+ + + +
+ + +

Tutorial 1: Serialization

+

Introduction

+

This tutorial will cover creating a simple pastebin code highlighting Web API. Along the way it will introduce the various components that make up REST framework, and give you a comprehensive understanding of how everything fits together.

+

The tutorial is fairly in-depth, so you should probably get a cookie and a cup of your favorite brew before getting started. If you just want a quick overview, you should head over to the quickstart documentation instead.

+
+

Note: The code for this tutorial is available in the tomchristie/rest-framework-tutorial repository on GitHub. The completed implementation is also online as a sandbox version for testing, available here.

+
+

Setting up a new environment

+

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
+
+

Now that we're inside a virtualenv environment, we can install our package requirements.

+
pip install django
+pip install djangorestframework
+pip install pygments  # We'll be using this for the code highlighting
+
+

Note: To exit the virtualenv environment at any time, just type deactivate. For more information see the virtualenv documentation.

+

Getting started

+

Okay, we're ready to get coding. +To get started, let's create a new project to work with.

+
cd ~
+django-admin.py startproject tutorial
+cd tutorial
+
+

Once that's done we can create an app that we'll use to create a simple Web API.

+
python manage.py startapp snippets
+
+

We'll need to add our new snippets app and the rest_framework app to INSTALLED_APPS. Let's edit the tutorial/settings.py file:

+
INSTALLED_APPS = (
+    ...
+    'rest_framework',
+    'snippets',
+)
+
+

We also need to wire up the root urlconf, in the tutorial/urls.py file, to include our snippet app's URLs.

+
urlpatterns = [
+    url(r'^', include('snippets.urls')),
+]
+
+

Okay, we're ready to roll.

+

Creating a model to work with

+

For the purposes of this tutorial we're going to start by creating a simple Snippet model that is used to store code snippets. Go ahead and edit the snippets/models.py file. Note: Good programming practices include comments. Although you will find them in our repository version of this tutorial code, we have omitted them here to focus on the code itself.

+
from django.db import models
+from pygments.lexers import get_all_lexers
+from pygments.styles import get_all_styles
+
+LEXERS = [item for item in get_all_lexers() if item[1]]
+LANGUAGE_CHOICES = sorted([(item[1][0], item[0]) for item in LEXERS])
+STYLE_CHOICES = sorted((item, item) for item in get_all_styles())
+
+
+class Snippet(models.Model):
+    created = models.DateTimeField(auto_now_add=True)
+    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)
+
+    class Meta:
+        ordering = ('created',)
+
+

We'll also need to create an initial migration for our snippet model, and sync the database for the first time.

+
python manage.py makemigrations snippets
+python manage.py migrate
+
+

Creating a Serializer class

+

The first thing we need to get started on our Web API is to provide a way of serializing and deserializing the snippet instances into representations such as json. We can do this by declaring serializers that work very similar to Django's forms. Create a file in the snippets directory named serializers.py and add the following.

+
from django.forms import widgets
+from rest_framework import serializers
+from snippets.models import Snippet, LANGUAGE_CHOICES, STYLE_CHOICES
+
+
+class SnippetSerializer(serializers.Serializer):
+    pk = serializers.IntegerField(read_only=True)
+    title = serializers.CharField(required=False,
+                                  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')
+
+    def create(self, validated_attrs):
+        """
+        Create and return a new `Snippet` instance, given the validated data.
+        """
+        return Snippet.objects.create(**validated_attrs)
+
+    def update(self, instance, validated_attrs):
+        """
+        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.save()
+        return instance
+
+

The first part of the serializer class defines the fields that get serialized/deserialized. The create() and update() methods define how fully fledged instances are created or modified when calling serializer.save()

+

A serializer class is very similar to a Django Form class, and includes similar validation flags on the various fields, such as required, max_length and default.

+

The field flags can also control how the serializer should be displayed in certain circumstances, such as when rendering to HTML. The style={'type': 'textarea'} flag above is equivelent to using widget=widgets.Textarea on a Django Form class. This is particularly useful for controlling how the browsable API should be displayed, as we'll see later in the tutorial.

+

We can actually also save ourselves some time by using the ModelSerializer class, as we'll see later, but for now we'll keep our serializer definition explicit.

+

Working with Serializers

+

Before we go any further we'll familiarize ourselves with using our new Serializer class. Let's drop into the Django shell.

+
python manage.py shell
+
+

Okay, once we've got a few imports out of the way, let's create a couple of code snippets to work with.

+
from snippets.models import Snippet
+from snippets.serializers import SnippetSerializer
+from rest_framework.renderers import JSONRenderer
+from rest_framework.parsers import JSONParser
+
+snippet = Snippet(code='foo = "bar"\n')
+snippet.save()
+
+snippet = Snippet(code='print "hello, world"\n')
+snippet.save()
+
+

We've now got a few snippet instances to play with. Let's take a look at serializing one of those instances.

+
serializer = SnippetSerializer(snippet)
+serializer.data
+# {'pk': 2, 'title': u'', 'code': u'print "hello, world"\n', 'linenos': False, 'language': u'python', 'style': u'friendly'}
+
+

At this point we've translated the model instance into Python native datatypes. To finalize the serialization process we render the data into json.

+
content = JSONRenderer().render(serializer.data)
+content
+# '{"pk": 2, "title": "", "code": "print \\"hello, world\\"\\n", "linenos": false, "language": "python", "style": "friendly"}'
+
+

Deserialization is similar. First we parse a stream into Python native datatypes...

+
# This import will use either `StringIO.StringIO` or `io.BytesIO`
+# as appropriate, depending on if we're running Python 2 or Python 3.
+from rest_framework.compat import BytesIO
+
+stream = BytesIO(content)
+data = JSONParser().parse(stream)
+
+

...then we restore those native datatypes into to a fully populated object instance.

+
serializer = SnippetSerializer(data=data)
+serializer.is_valid()
+# True
+serializer.object
+# <Snippet: Snippet object>
+
+

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.

+

We can also serialize querysets instead of model instances. To do so we simply add a many=True flag to the serializer arguments.

+
serializer = SnippetSerializer(Snippet.objects.all(), many=True)
+serializer.data
+# [{'pk': 1, 'title': u'', 'code': u'foo = "bar"\n', 'linenos': False, 'language': u'python', 'style': u'friendly'}, {'pk': 2, 'title': u'', 'code': u'print "hello, world"\n', 'linenos': False, 'language': u'python', 'style': u'friendly'}]
+
+

Using ModelSerializers

+

Our SnippetSerializer class is replicating a lot of information that's also contained in the Snippet model. It would be nice if we could keep our code a bit more concise.

+

In the same way that Django provides both Form classes and ModelForm classes, REST framework includes both Serializer classes, and ModelSerializer classes.

+

Let's look at refactoring our serializer using the ModelSerializer class. +Open the file snippets/serializers.py again, and edit the SnippetSerializer class.

+
class SnippetSerializer(serializers.ModelSerializer):
+    class Meta:
+        model = Snippet
+        fields = ('id', 'title', 'code', 'linenos', 'language', 'style')
+
+

Once nice property that serializers have is that you can inspect all the fields an serializer instance, by printing it's representation. Open the Django shell with python manange.py shell, then try the following:

+
>>> from snippets.serializers import SnippetSerializer
+>>> serializer = SnippetSerializer()
+>>> print repr(serializer)  # In python 3 use `print(repr(serializer))`
+SnippetSerializer():
+    id = IntegerField(label='ID', read_only=True)
+    title = CharField(allow_blank=True, max_length=100, required=False)
+    code = CharField(style={'type': 'textarea'})
+    linenos = BooleanField(required=False)
+    language = ChoiceField(choices=[('Clipper', 'FoxPro'), ('Cucumber', 'Gherkin'), ('RobotFramework', 'RobotFramework'), ('abap', 'ABAP'), ('ada', 'Ada')...
+    style = ChoiceField(choices=[('autumn', 'autumn'), ('borland', 'borland'), ('bw', 'bw'), ('colorful', 'colorful')...
+
+

It's important to remember that ModelSerializer classes don't do anything particularly magically, they are simply a shortcut to creating a serializer class with:

+
    +
  • An automatically determined set of fields.
  • +
  • Simple default implementations for the create() and update() methods.
  • +
+

Writing regular Django views using our Serializer

+

Let's see how we can write some API views using our new Serializer class. +For the moment we won't use any of REST framework's other features, we'll just write the views as regular Django views.

+

We'll start off by creating a subclass of HttpResponse that we can use to render any data we return into json.

+

Edit the snippets/views.py file, and add the following.

+
from django.http import HttpResponse
+from django.views.decorators.csrf import csrf_exempt
+from rest_framework.renderers import JSONRenderer
+from rest_framework.parsers import JSONParser
+from snippets.models import Snippet
+from snippets.serializers import SnippetSerializer
+
+class JSONResponse(HttpResponse):
+    """
+    An HttpResponse that renders its content into JSON.
+    """
+    def __init__(self, data, **kwargs):
+        content = JSONRenderer().render(data)
+        kwargs['content_type'] = 'application/json'
+        super(JSONResponse, self).__init__(content, **kwargs)
+
+

The root of our API is going to be a view that supports listing all the existing snippets, or creating a new snippet.

+
@csrf_exempt
+def snippet_list(request):
+    """
+    List all code snippets, or create a new snippet.
+    """
+    if request.method == 'GET':
+        snippets = Snippet.objects.all()
+        serializer = SnippetSerializer(snippets, many=True)
+        return JSONResponse(serializer.data)
+
+    elif request.method == 'POST':
+        data = JSONParser().parse(request)
+        serializer = SnippetSerializer(data=data)
+        if serializer.is_valid():
+            serializer.save()
+            return JSONResponse(serializer.data, status=201)
+        return JSONResponse(serializer.errors, status=400)
+
+

Note that because we want to be able to POST to this view from clients that won't have a CSRF token we need to mark the view as csrf_exempt. This isn't something that you'd normally want to do, and REST framework views actually use more sensible behavior than this, but it'll do for our purposes right now.

+

We'll also need a view which corresponds to an individual snippet, and can be used to retrieve, update or delete the snippet.

+
@csrf_exempt
+def snippet_detail(request, pk):
+    """
+    Retrieve, update or delete a code snippet.
+    """
+    try:
+        snippet = Snippet.objects.get(pk=pk)
+    except Snippet.DoesNotExist:
+        return HttpResponse(status=404)
+
+    if request.method == 'GET':
+        serializer = SnippetSerializer(snippet)
+        return JSONResponse(serializer.data)
+
+    elif request.method == 'PUT':
+        data = JSONParser().parse(request)
+        serializer = SnippetSerializer(snippet, data=data)
+        if serializer.is_valid():
+            serializer.save()
+            return JSONResponse(serializer.data)
+        return JSONResponse(serializer.errors, status=400)
+
+    elif request.method == 'DELETE':
+        snippet.delete()
+        return HttpResponse(status=204)
+
+

Finally we need to wire these views up. Create the snippets/urls.py file:

+
from django.conf.urls import patterns, url
+from snippets import views
+
+urlpatterns = [
+    url(r'^snippets/$', views.snippet_list),
+    url(r'^snippets/(?P<pk>[0-9]+)/$', views.snippet_detail),
+]
+
+

It's worth noting that there are a couple of edge cases we're not dealing with properly at the moment. If we send malformed json, or if a request is made with a method that the view doesn't handle, then we'll end up with a 500 "server error" response. Still, this'll do for now.

+

Testing our first attempt at a Web API

+

Now we can start up a sample server that serves our snippets.

+

Quit out of the shell...

+
quit()
+
+

...and start up Django's development server.

+
python manage.py runserver
+
+Validating models...
+
+0 errors found
+Django version 1.4.3, using settings 'tutorial.settings'
+Development server is running at http://127.0.0.1:8000/
+Quit the server with CONTROL-C.
+
+

In another terminal window, we can test the server.

+

We can get a list of all of the snippets.

+
curl 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"}]
+
+

Or we can get a particular snippet by referencing its id.

+
curl http://127.0.0.1:8000/snippets/2/
+
+{"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.

+

Where are we now

+

We're doing okay so far, we've got a serialization API that feels pretty similar to Django's Forms API, and some regular Django views.

+

Our API views don't do anything particularly special at the moment, beyond serving json responses, and there are some error handling edge cases we'd still like to clean up, but it's a functioning Web API.

+

We'll see how we can start to improve things in part 2 of the tutorial.

+ +
+ +
+ +
+ +
+ +
+
+ + + + + + + + + + + + + + \ No newline at end of file diff --git a/tutorial/2-requests-and-responses.html b/tutorial/2-requests-and-responses.html deleted file mode 100644 index 8add5464..00000000 --- a/tutorial/2-requests-and-responses.html +++ /dev/null @@ -1,378 +0,0 @@ - - - - - Tutorial 2: Requests and Responses - Django REST framework - - - - - - - - - - - - - - - - - - - - -
- - - -
-
- - - - -
- - - -
-

Tutorial 2: Requests and Responses

-

From this point we're going to really start covering the core of REST framework. -Let's introduce a couple of essential building blocks.

-

Request objects

-

REST framework introduces a Request object that extends the regular HttpRequest, and provides more flexible request parsing. The core functionality of the Request object is the request.DATA attribute, which is similar to request.POST, but more useful for working with Web APIs.

-
request.POST  # Only handles form data.  Only works for 'POST' method.
-request.DATA  # Handles arbitrary data.  Works for 'POST', 'PUT' and 'PATCH' methods.
-
-

Response objects

-

REST framework also introduces a Response object, which is a type of TemplateResponse that takes unrendered content and uses content negotiation to determine the correct content type to return to the client.

-
return Response(data)  # Renders to content type as requested by the client.
-
-

Status codes

-

Using numeric HTTP status codes in your views doesn't always make for obvious reading, and it's easy to not notice if you get an error code wrong. REST framework provides more explicit identifiers for each status code, such as HTTP_400_BAD_REQUEST in the status module. It's a good idea to use these throughout rather than using numeric identifiers.

-

Wrapping API views

-

REST framework provides two wrappers you can use to write API views.

-
    -
  1. The @api_view decorator for working with function based views.
  2. -
  3. The APIView class for working with class based views.
  4. -
-

These wrappers provide a few bits of functionality such as making sure you receive Request instances in your view, and adding context to Response objects so that content negotiation can be performed.

-

The wrappers also provide behaviour such as returning 405 Method Not Allowed responses when appropriate, and handling any ParseError exception that occurs when accessing request.DATA with malformed input.

-

Pulling it all together

-

Okay, let's go ahead and start using these new components to write a few views.

-

We don't need our JSONResponse class in views.py anymore, so go ahead and delete that. Once that's done we can start refactoring our views slightly.

-
from rest_framework import status
-from rest_framework.decorators import api_view
-from rest_framework.response import Response
-from snippets.models import Snippet
-from snippets.serializers import SnippetSerializer
-
-
-@api_view(['GET', 'POST'])
-def snippet_list(request):
-    """
-    List all snippets, or create a new snippet.
-    """
-    if request.method == 'GET':
-        snippets = Snippet.objects.all()
-        serializer = SnippetSerializer(snippets, many=True)
-        return Response(serializer.data)
-
-    elif request.method == 'POST':
-        serializer = SnippetSerializer(data=request.DATA)
-        if serializer.is_valid():
-            serializer.save()
-            return Response(serializer.data, status=status.HTTP_201_CREATED)
-        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
-
-

Our instance view is an improvement over the previous example. It's a little more concise, and the code now feels very similar to if we were working with the Forms API. We're also using named status codes, which makes the response meanings more obvious.

-

Here is the view for an individual snippet, in the views.py module.

-
@api_view(['GET', 'PUT', 'DELETE'])
-def snippet_detail(request, pk):
-    """
-    Retrieve, update or delete a snippet instance.
-    """
-    try:
-        snippet = Snippet.objects.get(pk=pk)
-    except Snippet.DoesNotExist:
-        return Response(status=status.HTTP_404_NOT_FOUND)
-
-    if request.method == 'GET':
-        serializer = SnippetSerializer(snippet)
-        return Response(serializer.data)
-
-    elif request.method == 'PUT':
-        serializer = SnippetSerializer(snippet, data=request.DATA)
-        if serializer.is_valid():
-            serializer.save()
-            return Response(serializer.data)
-        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
-
-    elif request.method == 'DELETE':
-        snippet.delete()
-        return Response(status=status.HTTP_204_NO_CONTENT)
-
-

This should all feel very familiar - it is not a lot different from working with regular Django views.

-

Notice that we're no longer explicitly tying our requests or responses to a given content type. request.DATA can handle incoming json requests, but it can also handle yaml and other formats. Similarly we're returning response objects with data, but allowing REST framework to render the response into the correct content type for us.

-

Adding optional format suffixes to our URLs

-

To take advantage of the fact that our responses are no longer hardwired to a single content type let's add support for format suffixes to our API endpoints. Using format suffixes gives us URLs that explicitly refer to a given format, and means our API will be able to handle URLs such as http://example.com/api/items/4.json.

-

Start by adding a format keyword argument to both of the views, like so.

-
def snippet_list(request, format=None):
-
-

and

-
def snippet_detail(request, pk, format=None):
-
-

Now update the urls.py file slightly, to append a set of format_suffix_patterns in addition to the existing URLs.

-
from django.conf.urls import patterns, url
-from rest_framework.urlpatterns import format_suffix_patterns
-from snippets import views
-
-urlpatterns = [
-    url(r'^snippets/$', views.snippet_list),
-    url(r'^snippets/(?P<pk>[0-9]+)$', views.snippet_detail),
-]
-
-urlpatterns = format_suffix_patterns(urlpatterns)
-
-

We don't necessarily need to add these extra url patterns in, but it gives us a simple, clean way of referring to a specific format.

-

How's it looking?

-

Go ahead and test the API from the command line, as we did in tutorial part 1. Everything is working pretty similarly, although we've got some nicer error handling if we send invalid requests.

-

We can get a list of all of the snippets, as before.

-
curl 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"}]
-
-

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
-
-

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
-
-

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"
-
-{"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"
-
-{"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/.

-

Browsability

-

Because the API chooses the content type of the response based on the client request, it will, by default, return an HTML-formatted representation of the resource when that resource is requested by a web browser. This allows for the API to return a fully web-browsable HTML representation.

-

Having a web-browsable API is a huge usability win, and makes developing and using your API much easier. It also dramatically lowers the barrier-to-entry for other developers wanting to inspect and work with your API.

-

See the browsable api topic for more information about the browsable API feature and how to customize it.

-

What's next?

-

In tutorial part 3, we'll start using class based views, and see how generic views reduce the amount of code we need to write.

-
-
-
-
- -
-
- - - - - - - - - - - diff --git a/tutorial/2-requests-and-responses/index.html b/tutorial/2-requests-and-responses/index.html new file mode 100644 index 00000000..aab35769 --- /dev/null +++ b/tutorial/2-requests-and-responses/index.html @@ -0,0 +1,573 @@ + + + + + + + 2 - Requests and responses - Django REST framework + + + + + + + + + + + + + + + + + + + + + +
+ + + +
+
+ + + + +
+ + + +
+ + +

Tutorial 2: Requests and Responses

+

From this point we're going to really start covering the core of REST framework. +Let's introduce a couple of essential building blocks.

+

Request objects

+

REST framework introduces a Request object that extends the regular HttpRequest, and provides more flexible request parsing. The core functionality of the Request object is the request.DATA attribute, which is similar to request.POST, but more useful for working with Web APIs.

+
request.POST  # Only handles form data.  Only works for 'POST' method.
+request.DATA  # Handles arbitrary data.  Works for 'POST', 'PUT' and 'PATCH' methods.
+
+

Response objects

+

REST framework also introduces a Response object, which is a type of TemplateResponse that takes unrendered content and uses content negotiation to determine the correct content type to return to the client.

+
return Response(data)  # Renders to content type as requested by the client.
+
+

Status codes

+

Using numeric HTTP status codes in your views doesn't always make for obvious reading, and it's easy to not notice if you get an error code wrong. REST framework provides more explicit identifiers for each status code, such as HTTP_400_BAD_REQUEST in the status module. It's a good idea to use these throughout rather than using numeric identifiers.

+

Wrapping API views

+

REST framework provides two wrappers you can use to write API views.

+
    +
  1. The @api_view decorator for working with function based views.
  2. +
  3. The APIView class for working with class based views.
  4. +
+

These wrappers provide a few bits of functionality such as making sure you receive Request instances in your view, and adding context to Response objects so that content negotiation can be performed.

+

The wrappers also provide behaviour such as returning 405 Method Not Allowed responses when appropriate, and handling any ParseError exception that occurs when accessing request.DATA with malformed input.

+

Pulling it all together

+

Okay, let's go ahead and start using these new components to write a few views.

+

We don't need our JSONResponse class in views.py anymore, so go ahead and delete that. Once that's done we can start refactoring our views slightly.

+
from rest_framework import status
+from rest_framework.decorators import api_view
+from rest_framework.response import Response
+from snippets.models import Snippet
+from snippets.serializers import SnippetSerializer
+
+
+@api_view(['GET', 'POST'])
+def snippet_list(request):
+    """
+    List all snippets, or create a new snippet.
+    """
+    if request.method == 'GET':
+        snippets = Snippet.objects.all()
+        serializer = SnippetSerializer(snippets, many=True)
+        return Response(serializer.data)
+
+    elif request.method == 'POST':
+        serializer = SnippetSerializer(data=request.DATA)
+        if serializer.is_valid():
+            serializer.save()
+            return Response(serializer.data, status=status.HTTP_201_CREATED)
+        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
+
+

Our instance view is an improvement over the previous example. It's a little more concise, and the code now feels very similar to if we were working with the Forms API. We're also using named status codes, which makes the response meanings more obvious.

+

Here is the view for an individual snippet, in the views.py module.

+
@api_view(['GET', 'PUT', 'DELETE'])
+def snippet_detail(request, pk):
+    """
+    Retrieve, update or delete a snippet instance.
+    """
+    try:
+        snippet = Snippet.objects.get(pk=pk)
+    except Snippet.DoesNotExist:
+        return Response(status=status.HTTP_404_NOT_FOUND)
+
+    if request.method == 'GET':
+        serializer = SnippetSerializer(snippet)
+        return Response(serializer.data)
+
+    elif request.method == 'PUT':
+        serializer = SnippetSerializer(snippet, data=request.DATA)
+        if serializer.is_valid():
+            serializer.save()
+            return Response(serializer.data)
+        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
+
+    elif request.method == 'DELETE':
+        snippet.delete()
+        return Response(status=status.HTTP_204_NO_CONTENT)
+
+

This should all feel very familiar - it is not a lot different from working with regular Django views.

+

Notice that we're no longer explicitly tying our requests or responses to a given content type. request.DATA can handle incoming json requests, but it can also handle yaml and other formats. Similarly we're returning response objects with data, but allowing REST framework to render the response into the correct content type for us.

+

Adding optional format suffixes to our URLs

+

To take advantage of the fact that our responses are no longer hardwired to a single content type let's add support for format suffixes to our API endpoints. Using format suffixes gives us URLs that explicitly refer to a given format, and means our API will be able to handle URLs such as http://example.com/api/items/4.json.

+

Start by adding a format keyword argument to both of the views, like so.

+
def snippet_list(request, format=None):
+
+

and

+
def snippet_detail(request, pk, format=None):
+
+

Now update the urls.py file slightly, to append a set of format_suffix_patterns in addition to the existing URLs.

+
from django.conf.urls import patterns, url
+from rest_framework.urlpatterns import format_suffix_patterns
+from snippets import views
+
+urlpatterns = [
+    url(r'^snippets/$', views.snippet_list),
+    url(r'^snippets/(?P<pk>[0-9]+)$', views.snippet_detail),
+]
+
+urlpatterns = format_suffix_patterns(urlpatterns)
+
+

We don't necessarily need to add these extra url patterns in, but it gives us a simple, clean way of referring to a specific format.

+

How's it looking?

+

Go ahead and test the API from the command line, as we did in tutorial part 1. Everything is working pretty similarly, although we've got some nicer error handling if we send invalid requests.

+

We can get a list of all of the snippets, as before.

+
curl 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"}]
+
+

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
+
+

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
+
+

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"
+
+{"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"
+
+{"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/.

+

Browsability

+

Because the API chooses the content type of the response based on the client request, it will, by default, return an HTML-formatted representation of the resource when that resource is requested by a web browser. This allows for the API to return a fully web-browsable HTML representation.

+

Having a web-browsable API is a huge usability win, and makes developing and using your API much easier. It also dramatically lowers the barrier-to-entry for other developers wanting to inspect and work with your API.

+

See the browsable api topic for more information about the browsable API feature and how to customize it.

+

What's next?

+

In tutorial part 3, we'll start using class based views, and see how generic views reduce the amount of code we need to write.

+ +
+ +
+ +
+ +
+ +
+
+ + + + + + + + + + + + + + \ No newline at end of file diff --git a/tutorial/3-class-based-views.html b/tutorial/3-class-based-views.html deleted file mode 100644 index c8a1d728..00000000 --- a/tutorial/3-class-based-views.html +++ /dev/null @@ -1,370 +0,0 @@ - - - - - Tutorial 3: Class Based Views - Django REST framework - - - - - - - - - - - - - - - - - - - - -
- - - -
-
- - - - -
- - - -
-

Tutorial 3: Class Based Views

-

We can also write our API views using class based views, rather than function based views. As we'll see this is a powerful pattern that allows us to reuse common functionality, and helps us keep our code DRY.

-

Rewriting our API using class based views

-

We'll start by rewriting the root view as a class based view. All this involves is a little bit of refactoring of views.py.

-
from snippets.models import Snippet
-from snippets.serializers import SnippetSerializer
-from django.http import Http404
-from rest_framework.views import APIView
-from rest_framework.response import Response
-from rest_framework import status
-
-
-class SnippetList(APIView):
-    """
-    List all snippets, or create a new snippet.
-    """
-    def get(self, request, format=None):
-        snippets = Snippet.objects.all()
-        serializer = SnippetSerializer(snippets, many=True)
-        return Response(serializer.data)
-
-    def post(self, request, format=None):
-        serializer = SnippetSerializer(data=request.DATA)
-        if serializer.is_valid():
-            serializer.save()
-            return Response(serializer.data, status=status.HTTP_201_CREATED)
-        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
-
-

So far, so good. It looks pretty similar to the previous case, but we've got better separation between the different HTTP methods. We'll also need to update the instance view in views.py.

-
class SnippetDetail(APIView):
-    """
-    Retrieve, update or delete a snippet instance.
-    """
-    def get_object(self, pk):
-        try:
-            return Snippet.objects.get(pk=pk)
-        except Snippet.DoesNotExist:
-            raise Http404
-
-    def get(self, request, pk, format=None):
-        snippet = self.get_object(pk)
-        serializer = SnippetSerializer(snippet)
-        return Response(serializer.data)
-
-    def put(self, request, pk, format=None):
-        snippet = self.get_object(pk)
-        serializer = SnippetSerializer(snippet, data=request.DATA)
-        if serializer.is_valid():
-            serializer.save()
-            return Response(serializer.data)
-        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
-
-    def delete(self, request, pk, format=None):
-        snippet = self.get_object(pk)
-        snippet.delete()
-        return Response(status=status.HTTP_204_NO_CONTENT)
-
-

That's looking good. Again, it's still pretty similar to the function based view right now.

-

We'll also need to refactor our urls.py slightly now we're using class based views.

-
from django.conf.urls import patterns, url
-from rest_framework.urlpatterns import format_suffix_patterns
-from snippets import views
-
-urlpatterns = [
-    url(r'^snippets/$', views.SnippetList.as_view()),
-    url(r'^snippets/(?P<pk>[0-9]+)/$', views.SnippetDetail.as_view()),
-]
-
-urlpatterns = format_suffix_patterns(urlpatterns)
-
-

Okay, we're done. If you run the development server everything should be working just as before.

-

Using mixins

-

One of the big wins of using class based views is that it allows us to easily compose reusable bits of behaviour.

-

The create/retrieve/update/delete operations that we've been using so far are going to be pretty similar for any model-backed API views we create. Those bits of common behaviour are implemented in REST framework's mixin classes.

-

Let's take a look at how we can compose the views by using the mixin classes. Here's our views.py module again.

-
from snippets.models import Snippet
-from snippets.serializers import SnippetSerializer
-from rest_framework import mixins
-from rest_framework import generics
-
-class SnippetList(mixins.ListModelMixin,
-                  mixins.CreateModelMixin,
-                  generics.GenericAPIView):
-    queryset = Snippet.objects.all()
-    serializer_class = SnippetSerializer
-
-    def get(self, request, *args, **kwargs):
-        return self.list(request, *args, **kwargs)
-
-    def post(self, request, *args, **kwargs):
-        return self.create(request, *args, **kwargs)
-
-

We'll take a moment to examine exactly what's happening here. We're building our view using GenericAPIView, and adding in ListModelMixin and CreateModelMixin.

-

The base class provides the core functionality, and the mixin classes provide the .list() and .create() actions. We're then explicitly binding the get and post methods to the appropriate actions. Simple enough stuff so far.

-
class SnippetDetail(mixins.RetrieveModelMixin,
-                    mixins.UpdateModelMixin,
-                    mixins.DestroyModelMixin,
-                    generics.GenericAPIView):
-    queryset = Snippet.objects.all()
-    serializer_class = SnippetSerializer
-
-    def get(self, request, *args, **kwargs):
-        return self.retrieve(request, *args, **kwargs)
-
-    def put(self, request, *args, **kwargs):
-        return self.update(request, *args, **kwargs)
-
-    def delete(self, request, *args, **kwargs):
-        return self.destroy(request, *args, **kwargs)
-
-

Pretty similar. Again we're using the GenericAPIView class to provide the core functionality, and adding in mixins to provide the .retrieve(), .update() and .destroy() actions.

-

Using generic class based views

-

Using the mixin classes we've rewritten the views to use slightly less code than before, but we can go one step further. REST framework provides a set of already mixed-in generic views that we can use to trim down our views.py module even more.

-
from snippets.models import Snippet
-from snippets.serializers import SnippetSerializer
-from rest_framework import generics
-
-
-class SnippetList(generics.ListCreateAPIView):
-    queryset = Snippet.objects.all()
-    serializer_class = SnippetSerializer
-
-
-class SnippetDetail(generics.RetrieveUpdateDestroyAPIView):
-    queryset = Snippet.objects.all()
-    serializer_class = SnippetSerializer
-
-

Wow, that's pretty concise. We've gotten a huge amount for free, and our code looks like good, clean, idiomatic Django.

-

Next we'll move onto part 4 of the tutorial, where we'll take a look at how we can deal with authentication and permissions for our API.

-
-
-
-
- -
-
- - - - - - - - - - - diff --git a/tutorial/3-class-based-views/index.html b/tutorial/3-class-based-views/index.html new file mode 100644 index 00000000..43358478 --- /dev/null +++ b/tutorial/3-class-based-views/index.html @@ -0,0 +1,550 @@ + + + + + + + 3 - Class based views - Django REST framework + + + + + + + + + + + + + + + + + + + + + +
+ + + +
+
+ + + + +
+ + + +
+ + +

Tutorial 3: Class Based Views

+

We can also write our API views using class based views, rather than function based views. As we'll see this is a powerful pattern that allows us to reuse common functionality, and helps us keep our code DRY.

+

Rewriting our API using class based views

+

We'll start by rewriting the root view as a class based view. All this involves is a little bit of refactoring of views.py.

+
from snippets.models import Snippet
+from snippets.serializers import SnippetSerializer
+from django.http import Http404
+from rest_framework.views import APIView
+from rest_framework.response import Response
+from rest_framework import status
+
+
+class SnippetList(APIView):
+    """
+    List all snippets, or create a new snippet.
+    """
+    def get(self, request, format=None):
+        snippets = Snippet.objects.all()
+        serializer = SnippetSerializer(snippets, many=True)
+        return Response(serializer.data)
+
+    def post(self, request, format=None):
+        serializer = SnippetSerializer(data=request.DATA)
+        if serializer.is_valid():
+            serializer.save()
+            return Response(serializer.data, status=status.HTTP_201_CREATED)
+        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
+
+

So far, so good. It looks pretty similar to the previous case, but we've got better separation between the different HTTP methods. We'll also need to update the instance view in views.py.

+
class SnippetDetail(APIView):
+    """
+    Retrieve, update or delete a snippet instance.
+    """
+    def get_object(self, pk):
+        try:
+            return Snippet.objects.get(pk=pk)
+        except Snippet.DoesNotExist:
+            raise Http404
+
+    def get(self, request, pk, format=None):
+        snippet = self.get_object(pk)
+        serializer = SnippetSerializer(snippet)
+        return Response(serializer.data)
+
+    def put(self, request, pk, format=None):
+        snippet = self.get_object(pk)
+        serializer = SnippetSerializer(snippet, data=request.DATA)
+        if serializer.is_valid():
+            serializer.save()
+            return Response(serializer.data)
+        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
+
+    def delete(self, request, pk, format=None):
+        snippet = self.get_object(pk)
+        snippet.delete()
+        return Response(status=status.HTTP_204_NO_CONTENT)
+
+

That's looking good. Again, it's still pretty similar to the function based view right now.

+

We'll also need to refactor our urls.py slightly now we're using class based views.

+
from django.conf.urls import patterns, url
+from rest_framework.urlpatterns import format_suffix_patterns
+from snippets import views
+
+urlpatterns = [
+    url(r'^snippets/$', views.SnippetList.as_view()),
+    url(r'^snippets/(?P<pk>[0-9]+)/$', views.SnippetDetail.as_view()),
+]
+
+urlpatterns = format_suffix_patterns(urlpatterns)
+
+

Okay, we're done. If you run the development server everything should be working just as before.

+

Using mixins

+

One of the big wins of using class based views is that it allows us to easily compose reusable bits of behaviour.

+

The create/retrieve/update/delete operations that we've been using so far are going to be pretty similar for any model-backed API views we create. Those bits of common behaviour are implemented in REST framework's mixin classes.

+

Let's take a look at how we can compose the views by using the mixin classes. Here's our views.py module again.

+
from snippets.models import Snippet
+from snippets.serializers import SnippetSerializer
+from rest_framework import mixins
+from rest_framework import generics
+
+class SnippetList(mixins.ListModelMixin,
+                  mixins.CreateModelMixin,
+                  generics.GenericAPIView):
+    queryset = Snippet.objects.all()
+    serializer_class = SnippetSerializer
+
+    def get(self, request, *args, **kwargs):
+        return self.list(request, *args, **kwargs)
+
+    def post(self, request, *args, **kwargs):
+        return self.create(request, *args, **kwargs)
+
+

We'll take a moment to examine exactly what's happening here. We're building our view using GenericAPIView, and adding in ListModelMixin and CreateModelMixin.

+

The base class provides the core functionality, and the mixin classes provide the .list() and .create() actions. We're then explicitly binding the get and post methods to the appropriate actions. Simple enough stuff so far.

+
class SnippetDetail(mixins.RetrieveModelMixin,
+                    mixins.UpdateModelMixin,
+                    mixins.DestroyModelMixin,
+                    generics.GenericAPIView):
+    queryset = Snippet.objects.all()
+    serializer_class = SnippetSerializer
+
+    def get(self, request, *args, **kwargs):
+        return self.retrieve(request, *args, **kwargs)
+
+    def put(self, request, *args, **kwargs):
+        return self.update(request, *args, **kwargs)
+
+    def delete(self, request, *args, **kwargs):
+        return self.destroy(request, *args, **kwargs)
+
+

Pretty similar. Again we're using the GenericAPIView class to provide the core functionality, and adding in mixins to provide the .retrieve(), .update() and .destroy() actions.

+

Using generic class based views

+

Using the mixin classes we've rewritten the views to use slightly less code than before, but we can go one step further. REST framework provides a set of already mixed-in generic views that we can use to trim down our views.py module even more.

+
from snippets.models import Snippet
+from snippets.serializers import SnippetSerializer
+from rest_framework import generics
+
+
+class SnippetList(generics.ListCreateAPIView):
+    queryset = Snippet.objects.all()
+    serializer_class = SnippetSerializer
+
+
+class SnippetDetail(generics.RetrieveUpdateDestroyAPIView):
+    queryset = Snippet.objects.all()
+    serializer_class = SnippetSerializer
+
+

Wow, that's pretty concise. We've gotten a huge amount for free, and our code looks like good, clean, idiomatic Django.

+

Next we'll move onto part 4 of the tutorial, where we'll take a look at how we can deal with authentication and permissions for our API.

+ +
+ +
+ +
+ +
+ +
+
+ + + + + + + + + + + + + + \ No newline at end of file diff --git a/tutorial/4-authentication-and-permissions.html b/tutorial/4-authentication-and-permissions.html deleted file mode 100644 index f72c8930..00000000 --- a/tutorial/4-authentication-and-permissions.html +++ /dev/null @@ -1,406 +0,0 @@ - - - - - Tutorial 4: Authentication & Permissions - Django REST framework - - - - - - - - - - - - - - - - - - - - -
- - - -
-
- - - - -
- - - -
-

Tutorial 4: Authentication & Permissions

-

Currently our API doesn't have any restrictions on who can edit or delete code snippets. We'd like to have some more advanced behavior in order to make sure that:

-
    -
  • Code snippets are always associated with a creator.
  • -
  • Only authenticated users may create snippets.
  • -
  • Only the creator of a snippet may update or delete it.
  • -
  • Unauthenticated requests should have full read-only access.
  • -
-

Adding information to our model

-

We're going to make a couple of changes to our Snippet model class. -First, let's add a couple of fields. One of those fields will be used to represent the user who created the code snippet. The other field will be used to store the highlighted HTML representation of the code.

-

Add the following two fields to the Snippet model in models.py.

-
owner = models.ForeignKey('auth.User', related_name='snippets')
-highlighted = models.TextField()
-
-

We'd also need to make sure that when the model is saved, that we populate the highlighted field, using the pygments code highlighting library.

-

We'll need some extra imports:

-
from pygments.lexers import get_lexer_by_name
-from pygments.formatters.html import HtmlFormatter
-from pygments import highlight
-
-

And now we can add a .save() method to our model class:

-
def save(self, *args, **kwargs):
-    """
-    Use the `pygments` library to create a highlighted HTML
-    representation of the code snippet.
-    """
-    lexer = get_lexer_by_name(self.language)
-    linenos = self.linenos and 'table' or False
-    options = self.title and {'title': self.title} or {}
-    formatter = HtmlFormatter(style=self.style, linenos=linenos,
-                              full=True, **options)
-    self.highlighted = highlight(self.code, lexer, formatter)
-    super(Snippet, self).save(*args, **kwargs)
-
-

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
-python manage.py syncdb
-
-

You might also want to create a few different users, to use for testing the API. The quickest way to do this will be with the createsuperuser command.

-
python manage.py createsuperuser
-
-

Adding endpoints for our User models

-

Now that we've got some users to work with, we'd better add representations of those users to our API. Creating a new serializer is easy. In serializers.py add:

-
from django.contrib.auth.models import User
-
-class UserSerializer(serializers.ModelSerializer):
-    snippets = serializers.PrimaryKeyRelatedField(many=True)
-
-    class Meta:
-        model = User
-        fields = ('id', 'username', 'snippets')
-
-

Because 'snippets' is a reverse relationship on the User model, it will not be included by default when using the ModelSerializer class, so we needed to add an explicit field for it.

-

We'll also add a couple of views to views.py. We'd like to just use read-only views for the user representations, so we'll use the ListAPIView and RetrieveAPIView generic class based views.

-
from django.contrib.auth.models import User
-
-
-class UserList(generics.ListAPIView):
-    queryset = User.objects.all()
-    serializer_class = UserSerializer
-
-
-class UserDetail(generics.RetrieveAPIView):
-    queryset = User.objects.all()
-    serializer_class = UserSerializer
-
-

Make sure to also import the UserSerializer class

-
from snippets.serializers import UserSerializer
-
-

Finally we need to add those views into the API, by referencing them from the URL conf. Add the following to the patterns in urls.py.

-
url(r'^users/$', views.UserList.as_view()),
-url(r'^users/(?P<pk>[0-9]+)/$', views.UserDetail.as_view()),
-
-

Associating Snippets with Users

-

Right now, if we created a code snippet, there'd be no way of associating the user that created the snippet, with the snippet instance. The user isn't sent as part of the serialized representation, but is instead a property of the incoming request.

-

The way we deal with that is by overriding a .pre_save() method on our snippet views, that allows us to handle any information that is implicit in the incoming request or requested URL.

-

On both the SnippetList and SnippetDetail view classes, add the following method:

-
def pre_save(self, obj):
-    obj.owner = self.request.user
-
-

Updating our serializer

-

Now that snippets are associated with the user that created them, let's update our SnippetSerializer to reflect that. Add the following field to the serializer definition in serializers.py:

-
owner = serializers.Field(source='owner.username')
-
-

Note: Make sure you also add 'owner', to the list of fields in the inner Meta class.

-

This field is doing something quite interesting. The source argument controls which attribute is used to populate a field, and can point at any attribute on the serialized instance. It can also take the dotted notation shown above, in which case it will traverse the given attributes, in a similar way as it is used with Django's template language.

-

The field we've added is the untyped Field class, in contrast to the other typed fields, such as CharField, BooleanField etc... The untyped Field is always read-only, and will be used for serialized representations, but will not be used for updating model instances when they are deserialized.

-

Adding required permissions to views

-

Now that code snippets are associated with users, we want to make sure that only authenticated users are able to create, update and delete code snippets.

-

REST framework includes a number of permission classes that we can use to restrict who can access a given view. In this case the one we're looking for is IsAuthenticatedOrReadOnly, which will ensure that authenticated requests get read-write access, and unauthenticated requests get read-only access.

-

First add the following import in the views module

-
from rest_framework import permissions
-
-

Then, add the following property to both the SnippetList and SnippetDetail view classes.

-
permission_classes = (permissions.IsAuthenticatedOrReadOnly,)
-
-

Adding login to the Browsable API

-

If you open a browser and navigate to the browsable API at the moment, you'll find that you're no longer able to create new code snippets. In order to do so we'd need to be able to login as a user.

-

We can add a login view for use with the browsable API, by editing the URLconf in our project-level urls.py file.

-

Add the following import at the top of the file:

-
from django.conf.urls import include
-
-

And, at the end of the file, add a pattern to include the login and logout views for the browsable API.

-
urlpatterns += [
-    url(r'^api-auth/', include('rest_framework.urls',
-                               namespace='rest_framework')),
-]
-
-

The r'^api-auth/' part of pattern can actually be whatever URL you want to use. The only restriction is that the included urls must use the 'rest_framework' namespace.

-

Now if you open up the browser again and refresh the page you'll see a 'Login' link in the top right of the page. If you log in as one of the users you created earlier, you'll be able to create code snippets again.

-

Once you've created a few code snippets, navigate to the '/users/' endpoint, and notice that the representation includes a list of the snippet pks that are associated with each user, in each user's 'snippets' field.

-

Object level permissions

-

Really we'd like all code snippets to be visible to anyone, but also make sure that only the user that created a code snippet is able to update or delete it.

-

To do that we're going to need to create a custom permission.

-

In the snippets app, create a new file, permissions.py

-
from rest_framework import permissions
-
-
-class IsOwnerOrReadOnly(permissions.BasePermission):
-    """
-    Custom permission to only allow owners of an object to edit it.
-    """
-
-    def has_object_permission(self, request, view, obj):
-        # Read permissions are allowed to any request,
-        # so we'll always allow GET, HEAD or OPTIONS requests.
-        if request.method in permissions.SAFE_METHODS:
-            return True
-
-        # Write permissions are only allowed to the owner of the snippet.
-        return obj.owner == request.user
-
-

Now we can add that custom permission to our snippet instance endpoint, by editing the permission_classes property on the SnippetDetail class:

-
permission_classes = (permissions.IsAuthenticatedOrReadOnly,
-                      IsOwnerOrReadOnly,)
-
-

Make sure to also import the IsOwnerOrReadOnly class.

-
from snippets.permissions import IsOwnerOrReadOnly
-
-

Now, if you open a browser again, you find that the 'DELETE' and 'PUT' actions only appear on a snippet instance endpoint if you're logged in as the same user that created the code snippet.

-

Authenticating with the API

-

Because we now have a set of permissions on the API, we need to authenticate our requests to it if we want to edit any snippets. We haven't set up any authentication classes, so the defaults are currently applied, which are SessionAuthentication and BasicAuthentication.

-

When we interact with the API through the web browser, we can login, and the browser session will then provide the required authentication for the requests.

-

If we're interacting with the API programmatically we need to explicitly provide the authentication credentials on each request.

-

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"
-
-{"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
-
-{"id": 5, "owner": "tom", "title": "foo", "code": "print 789", "linenos": false, "language": "python", "style": "friendly"}
-
-

Summary

-

We've now got a fairly fine-grained set of permissions on our Web API, and end points for users of the system and for the code snippets that they have created.

-

In part 5 of the tutorial we'll look at how we can tie everything together by creating an HTML endpoint for our highlighted snippets, and improve the cohesion of our API by using hyperlinking for the relationships within the system.

-
-
-
-
- -
-
- - - - - - - - - - - diff --git a/tutorial/4-authentication-and-permissions/index.html b/tutorial/4-authentication-and-permissions/index.html new file mode 100644 index 00000000..90e2d921 --- /dev/null +++ b/tutorial/4-authentication-and-permissions/index.html @@ -0,0 +1,607 @@ + + + + + + + 4 - Authentication and permissions - Django REST framework + + + + + + + + + + + + + + + + + + + + + +
+ + + +
+
+ + + + +
+ + + +
+ + +

Tutorial 4: Authentication & Permissions

+

Currently our API doesn't have any restrictions on who can edit or delete code snippets. We'd like to have some more advanced behavior in order to make sure that:

+
    +
  • Code snippets are always associated with a creator.
  • +
  • Only authenticated users may create snippets.
  • +
  • Only the creator of a snippet may update or delete it.
  • +
  • Unauthenticated requests should have full read-only access.
  • +
+

Adding information to our model

+

We're going to make a couple of changes to our Snippet model class. +First, let's add a couple of fields. One of those fields will be used to represent the user who created the code snippet. The other field will be used to store the highlighted HTML representation of the code.

+

Add the following two fields to the Snippet model in models.py.

+
owner = models.ForeignKey('auth.User', related_name='snippets')
+highlighted = models.TextField()
+
+

We'd also need to make sure that when the model is saved, that we populate the highlighted field, using the pygments code highlighting library.

+

We'll need some extra imports:

+
from pygments.lexers import get_lexer_by_name
+from pygments.formatters.html import HtmlFormatter
+from pygments import highlight
+
+

And now we can add a .save() method to our model class:

+
def save(self, *args, **kwargs):
+    """
+    Use the `pygments` library to create a highlighted HTML
+    representation of the code snippet.
+    """
+    lexer = get_lexer_by_name(self.language)
+    linenos = self.linenos and 'table' or False
+    options = self.title and {'title': self.title} or {}
+    formatter = HtmlFormatter(style=self.style, linenos=linenos,
+                              full=True, **options)
+    self.highlighted = highlight(self.code, lexer, formatter)
+    super(Snippet, self).save(*args, **kwargs)
+
+

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 -r snippets/migrations
+python manage.py makemigrations snippets
+python manage.py migrate
+
+

You might also want to create a few different users, to use for testing the API. The quickest way to do this will be with the createsuperuser command.

+
python manage.py createsuperuser
+
+

Adding endpoints for our User models

+

Now that we've got some users to work with, we'd better add representations of those users to our API. Creating a new serializer is easy. In serializers.py add:

+
from django.contrib.auth.models import User
+
+class UserSerializer(serializers.ModelSerializer):
+    snippets = serializers.PrimaryKeyRelatedField(many=True)
+
+    class Meta:
+        model = User
+        fields = ('id', 'username', 'snippets')
+
+

Because 'snippets' is a reverse relationship on the User model, it will not be included by default when using the ModelSerializer class, so we needed to add an explicit field for it.

+

We'll also add a couple of views to views.py. We'd like to just use read-only views for the user representations, so we'll use the ListAPIView and RetrieveAPIView generic class based views.

+
from django.contrib.auth.models import User
+
+
+class UserList(generics.ListAPIView):
+    queryset = User.objects.all()
+    serializer_class = UserSerializer
+
+
+class UserDetail(generics.RetrieveAPIView):
+    queryset = User.objects.all()
+    serializer_class = UserSerializer
+
+

Make sure to also import the UserSerializer class

+
from snippets.serializers import UserSerializer
+
+

Finally we need to add those views into the API, by referencing them from the URL conf. Add the following to the patterns in urls.py.

+
url(r'^users/$', views.UserList.as_view()),
+url(r'^users/(?P<pk>[0-9]+)/$', views.UserDetail.as_view()),
+
+

Associating Snippets with Users

+

Right now, if we created a code snippet, there'd be no way of associating the user that created the snippet, with the snippet instance. The user isn't sent as part of the serialized representation, but is instead a property of the incoming request.

+

The way we deal with that is by overriding a .perform_create() method on our snippet views, that allows us to modify how the instance save is managed, and handle any information that is implicit in the incoming request or requested URL.

+

On the SnippetList view class, add the following method:

+
def perform_create(self, serializer):
+    serializer.save(owner=self.request.user)
+
+

The create() method of our serializer will now be passed an additional 'owner' field, along with the validated data from the request.

+

Updating our serializer

+

Now that snippets are associated with the user that created them, let's update our SnippetSerializer to reflect that. Add the following field to the serializer definition in serializers.py:

+
owner = serializers.ReadOnlyField(source='owner.username')
+
+

Note: Make sure you also add 'owner', to the list of fields in the inner Meta class.

+

This field is doing something quite interesting. The source argument controls which attribute is used to populate a field, and can point at any attribute on the serialized instance. It can also take the dotted notation shown above, in which case it will traverse the given attributes, in a similar way as it is used with Django's template language.

+

The field we've added is the untyped ReadOnlyField class, in contrast to the other typed fields, such as CharField, BooleanField etc... The untyped ReadOnlyField is always read-only, and will be used for serialized representations, but will not be used for updating model instances when they are deserialized. We could have also used CharField(read_only=True) here.

+

Adding required permissions to views

+

Now that code snippets are associated with users, we want to make sure that only authenticated users are able to create, update and delete code snippets.

+

REST framework includes a number of permission classes that we can use to restrict who can access a given view. In this case the one we're looking for is IsAuthenticatedOrReadOnly, which will ensure that authenticated requests get read-write access, and unauthenticated requests get read-only access.

+

First add the following import in the views module

+
from rest_framework import permissions
+
+

Then, add the following property to both the SnippetList and SnippetDetail view classes.

+
permission_classes = (permissions.IsAuthenticatedOrReadOnly,)
+
+

Adding login to the Browsable API

+

If you open a browser and navigate to the browsable API at the moment, you'll find that you're no longer able to create new code snippets. In order to do so we'd need to be able to login as a user.

+

We can add a login view for use with the browsable API, by editing the URLconf in our project-level urls.py file.

+

Add the following import at the top of the file:

+
from django.conf.urls import include
+
+

And, at the end of the file, add a pattern to include the login and logout views for the browsable API.

+
urlpatterns += [
+    url(r'^api-auth/', include('rest_framework.urls',
+                               namespace='rest_framework')),
+]
+
+

The r'^api-auth/' part of pattern can actually be whatever URL you want to use. The only restriction is that the included urls must use the 'rest_framework' namespace.

+

Now if you open up the browser again and refresh the page you'll see a 'Login' link in the top right of the page. If you log in as one of the users you created earlier, you'll be able to create code snippets again.

+

Once you've created a few code snippets, navigate to the '/users/' endpoint, and notice that the representation includes a list of the snippet pks that are associated with each user, in each user's 'snippets' field.

+

Object level permissions

+

Really we'd like all code snippets to be visible to anyone, but also make sure that only the user that created a code snippet is able to update or delete it.

+

To do that we're going to need to create a custom permission.

+

In the snippets app, create a new file, permissions.py

+
from rest_framework import permissions
+
+
+class IsOwnerOrReadOnly(permissions.BasePermission):
+    """
+    Custom permission to only allow owners of an object to edit it.
+    """
+
+    def has_object_permission(self, request, view, obj):
+        # Read permissions are allowed to any request,
+        # so we'll always allow GET, HEAD or OPTIONS requests.
+        if request.method in permissions.SAFE_METHODS:
+            return True
+
+        # Write permissions are only allowed to the owner of the snippet.
+        return obj.owner == request.user
+
+

Now we can add that custom permission to our snippet instance endpoint, by editing the permission_classes property on the SnippetDetail class:

+
permission_classes = (permissions.IsAuthenticatedOrReadOnly,
+                      IsOwnerOrReadOnly,)
+
+

Make sure to also import the IsOwnerOrReadOnly class.

+
from snippets.permissions import IsOwnerOrReadOnly
+
+

Now, if you open a browser again, you find that the 'DELETE' and 'PUT' actions only appear on a snippet instance endpoint if you're logged in as the same user that created the code snippet.

+

Authenticating with the API

+

Because we now have a set of permissions on the API, we need to authenticate our requests to it if we want to edit any snippets. We haven't set up any authentication classes, so the defaults are currently applied, which are SessionAuthentication and BasicAuthentication.

+

When we interact with the API through the web browser, we can login, and the browser session will then provide the required authentication for the requests.

+

If we're interacting with the API programmatically we need to explicitly provide the authentication credentials on each request.

+

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"
+
+{"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
+
+{"id": 5, "owner": "tom", "title": "foo", "code": "print 789", "linenos": false, "language": "python", "style": "friendly"}
+
+

Summary

+

We've now got a fairly fine-grained set of permissions on our Web API, and end points for users of the system and for the code snippets that they have created.

+

In part 5 of the tutorial we'll look at how we can tie everything together by creating an HTML endpoint for our highlighted snippets, and improve the cohesion of our API by using hyperlinking for the relationships within the system.

+ +
+ +
+ +
+ +
+ +
+
+ + + + + + + + + + + + + + \ No newline at end of file diff --git a/tutorial/5-relationships-and-hyperlinked-apis.html b/tutorial/5-relationships-and-hyperlinked-apis.html deleted file mode 100644 index 250a3d52..00000000 --- a/tutorial/5-relationships-and-hyperlinked-apis.html +++ /dev/null @@ -1,372 +0,0 @@ - - - - - Tutorial 5: Relationships & Hyperlinked APIs - Django REST framework - - - - - - - - - - - - - - - - - - - - -
- - - -
-
- - - - -
- - - -
-

Tutorial 5: Relationships & Hyperlinked APIs

-

At the moment relationships within our API are represented by using primary keys. In this part of the tutorial we'll improve the cohesion and discoverability of our API, by instead using hyperlinking for relationships.

-

Creating an endpoint for the root of our API

-

Right now we have endpoints for 'snippets' and 'users', but we don't have a single entry point to our API. To create one, we'll use a regular function-based view and the @api_view decorator we introduced earlier. In your snippets/views.py add:

-
from rest_framework import renderers
-from rest_framework.decorators import api_view
-from rest_framework.response import Response
-from rest_framework.reverse import reverse
-
-
-@api_view(('GET',))
-def api_root(request, format=None):
-    return Response({
-        'users': reverse('user-list', request=request, format=format),
-        'snippets': reverse('snippet-list', request=request, format=format)
-    })
-
-

Notice that we're using REST framework's reverse function in order to return fully-qualified URLs.

-

Creating an endpoint for the highlighted snippets

-

The other obvious thing that's still missing from our pastebin API is the code highlighting endpoints.

-

Unlike all our other API endpoints, we don't want to use JSON, but instead just present an HTML representation. There are two styles of HTML renderer provided by REST framework, one for dealing with HTML rendered using templates, the other for dealing with pre-rendered HTML. The second renderer is the one we'd like to use for this endpoint.

-

The other thing we need to consider when creating the code highlight view is that there's no existing concrete generic view that we can use. We're not returning an object instance, but instead a property of an object instance.

-

Instead of using a concrete generic view, we'll use the base class for representing instances, and create our own .get() method. In your snippets/views.py add:

-
from rest_framework import renderers
-from rest_framework.response import Response
-
-class SnippetHighlight(generics.GenericAPIView):
-    queryset = Snippet.objects.all()
-    renderer_classes = (renderers.StaticHTMLRenderer,)
-
-    def get(self, request, *args, **kwargs):
-        snippet = self.get_object()
-        return Response(snippet.highlighted)
-
-

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'),
-
-

And then add a url pattern for the snippet highlights:

-
url(r'^snippets/(?P<pk>[0-9]+)/highlight/$', views.SnippetHighlight.as_view()),
-
-

Hyperlinking our API

-

Dealing with relationships between entities is one of the more challenging aspects of Web API design. There are a number of different ways that we might choose to represent a relationship:

-
    -
  • Using primary keys.
  • -
  • Using hyperlinking between entities.
  • -
  • Using a unique identifying slug field on the related entity.
  • -
  • Using the default string representation of the related entity.
  • -
  • Nesting the related entity inside the parent representation.
  • -
  • Some other custom representation.
  • -
-

REST framework supports all of these styles, and can apply them across forward or reverse relationships, or apply them across custom managers such as generic foreign keys.

-

In this case we'd like to use a hyperlinked style between entities. In order to do so, we'll modify our serializers to extend HyperlinkedModelSerializer instead of the existing ModelSerializer.

-

The HyperlinkedModelSerializer has the following differences from ModelSerializer:

-
    -
  • It does not include the pk field by default.
  • -
  • It includes a url field, using HyperlinkedIdentityField.
  • -
  • Relationships use HyperlinkedRelatedField, - instead of PrimaryKeyRelatedField.
  • -
-

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')
-    highlight = serializers.HyperlinkedIdentityField(view_name='snippet-highlight', format='html')
-
-    class Meta:
-        model = Snippet
-        fields = ('url', 'highlight', 'owner',
-                  'title', 'code', 'linenos', 'language', 'style')
-
-
-class UserSerializer(serializers.HyperlinkedModelSerializer):
-    snippets = serializers.HyperlinkedRelatedField(many=True, view_name='snippet-detail')
-
-    class Meta:
-        model = User
-        fields = ('url', 'username', 'snippets')
-
-

Notice that we've also added a new 'highlight' field. This field is of the same type as the url field, except that it points to the 'snippet-highlight' url pattern, instead of the 'snippet-detail' url pattern.

-

Because we've included format suffixed URLs such as '.json', we also need to indicate on the highlight field that any format suffixed hyperlinks it returns should use the '.html' suffix.

-

Making sure our URL patterns are named

-

If we're going to have a hyperlinked API, we need to make sure we name our URL patterns. Let's take a look at which URL patterns we need to name.

-
    -
  • The root of our API refers to 'user-list' and 'snippet-list'.
  • -
  • Our snippet serializer includes a field that refers to 'snippet-highlight'.
  • -
  • Our user serializer includes a field that refers to 'snippet-detail'.
  • -
  • Our snippet and user serializers include 'url' fields that by default will refer to '{model_name}-detail', which in this case will be 'snippet-detail' and 'user-detail'.
  • -
-

After adding all those names into our URLconf, our final snippets/urls.py file should look something like this:

-
# API endpoints
-urlpatterns = format_suffix_patterns([
-    url(r'^$', views.api_root),
-    url(r'^snippets/$',
-        views.SnippetList.as_view(),
-        name='snippet-list'),
-    url(r'^snippets/(?P<pk>[0-9]+)/$',
-        views.SnippetDetail.as_view(),
-        name='snippet-detail'),
-    url(r'^snippets/(?P<pk>[0-9]+)/highlight/$',
-        views.SnippetHighlight.as_view(),
-        name='snippet-highlight'),
-    url(r'^users/$',
-        views.UserList.as_view(),
-        name='user-list'),
-    url(r'^users/(?P<pk>[0-9]+)/$',
-        views.UserDetail.as_view(),
-        name='user-detail')
-])
-
-# Login and logout views for the browsable API
-urlpatterns += [
-    url(r'^api-auth/', include('rest_framework.urls',
-                               namespace='rest_framework')),
-]
-
-

Adding pagination

-

The list views for users and code snippets could end up returning quite a lot of instances, so really we'd like to make sure we paginate the results, and allow the API client to step through each of the individual pages.

-

We can change the default list style to use pagination, by modifying our settings.py file slightly. Add the following setting:

-
REST_FRAMEWORK = {
-    'PAGINATE_BY': 10
-}
-
-

Note that settings in REST framework are all namespaced into a single dictionary setting, named 'REST_FRAMEWORK', which helps keep them well separated from your other project settings.

-

We could also customize the pagination style if we needed too, but in this case we'll just stick with the default.

-

Browsing the API

-

If we open a browser and navigate to the browsable API, you'll find that you can now work your way around the API simply by following links.

-

You'll also be able to see the 'highlight' links on the snippet instances, that will take you to the highlighted code HTML representations.

-

In part 6 of the tutorial we'll look at how we can use ViewSets and Routers to reduce the amount of code we need to build our API.

-
-
-
-
- -
-
- - - - - - - - - - - diff --git a/tutorial/5-relationships-and-hyperlinked-apis/index.html b/tutorial/5-relationships-and-hyperlinked-apis/index.html new file mode 100644 index 00000000..dd39c431 --- /dev/null +++ b/tutorial/5-relationships-and-hyperlinked-apis/index.html @@ -0,0 +1,560 @@ + + + + + + + 5 - Relationships and hyperlinked APIs - Django REST framework + + + + + + + + + + + + + + + + + + + + + +
+ + + +
+
+ + + + +
+ + + +
+ + +

Tutorial 5: Relationships & Hyperlinked APIs

+

At the moment relationships within our API are represented by using primary keys. In this part of the tutorial we'll improve the cohesion and discoverability of our API, by instead using hyperlinking for relationships.

+

Creating an endpoint for the root of our API

+

Right now we have endpoints for 'snippets' and 'users', but we don't have a single entry point to our API. To create one, we'll use a regular function-based view and the @api_view decorator we introduced earlier. In your snippets/views.py add:

+
from rest_framework.decorators import api_view
+from rest_framework.response import Response
+from rest_framework.reverse import reverse
+
+
+@api_view(('GET',))
+def api_root(request, format=None):
+    return Response({
+        'users': reverse('user-list', request=request, format=format),
+        'snippets': reverse('snippet-list', request=request, format=format)
+    })
+
+

Notice that we're using REST framework's reverse function in order to return fully-qualified URLs.

+

Creating an endpoint for the highlighted snippets

+

The other obvious thing that's still missing from our pastebin API is the code highlighting endpoints.

+

Unlike all our other API endpoints, we don't want to use JSON, but instead just present an HTML representation. There are two styles of HTML renderer provided by REST framework, one for dealing with HTML rendered using templates, the other for dealing with pre-rendered HTML. The second renderer is the one we'd like to use for this endpoint.

+

The other thing we need to consider when creating the code highlight view is that there's no existing concrete generic view that we can use. We're not returning an object instance, but instead a property of an object instance.

+

Instead of using a concrete generic view, we'll use the base class for representing instances, and create our own .get() method. In your snippets/views.py add:

+
from rest_framework import renderers
+from rest_framework.response import Response
+
+class SnippetHighlight(generics.GenericAPIView):
+    queryset = Snippet.objects.all()
+    renderer_classes = (renderers.StaticHTMLRenderer,)
+
+    def get(self, request, *args, **kwargs):
+        snippet = self.get_object()
+        return Response(snippet.highlighted)
+
+

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'),
+
+

And then add a url pattern for the snippet highlights:

+
url(r'^snippets/(?P<pk>[0-9]+)/highlight/$', views.SnippetHighlight.as_view()),
+
+

Hyperlinking our API

+

Dealing with relationships between entities is one of the more challenging aspects of Web API design. There are a number of different ways that we might choose to represent a relationship:

+
    +
  • Using primary keys.
  • +
  • Using hyperlinking between entities.
  • +
  • Using a unique identifying slug field on the related entity.
  • +
  • Using the default string representation of the related entity.
  • +
  • Nesting the related entity inside the parent representation.
  • +
  • Some other custom representation.
  • +
+

REST framework supports all of these styles, and can apply them across forward or reverse relationships, or apply them across custom managers such as generic foreign keys.

+

In this case we'd like to use a hyperlinked style between entities. In order to do so, we'll modify our serializers to extend HyperlinkedModelSerializer instead of the existing ModelSerializer.

+

The HyperlinkedModelSerializer has the following differences from ModelSerializer:

+
    +
  • It does not include the pk field by default.
  • +
  • It includes a url field, using HyperlinkedIdentityField.
  • +
  • Relationships use HyperlinkedRelatedField, + instead of PrimaryKeyRelatedField.
  • +
+

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')
+    highlight = serializers.HyperlinkedIdentityField(view_name='snippet-highlight', format='html')
+
+    class Meta:
+        model = Snippet
+        fields = ('url', 'highlight', 'owner',
+                  'title', 'code', 'linenos', 'language', 'style')
+
+
+class UserSerializer(serializers.HyperlinkedModelSerializer):
+    snippets = serializers.HyperlinkedRelatedField(many=True, view_name='snippet-detail')
+
+    class Meta:
+        model = User
+        fields = ('url', 'username', 'snippets')
+
+

Notice that we've also added a new 'highlight' field. This field is of the same type as the url field, except that it points to the 'snippet-highlight' url pattern, instead of the 'snippet-detail' url pattern.

+

Because we've included format suffixed URLs such as '.json', we also need to indicate on the highlight field that any format suffixed hyperlinks it returns should use the '.html' suffix.

+

Making sure our URL patterns are named

+

If we're going to have a hyperlinked API, we need to make sure we name our URL patterns. Let's take a look at which URL patterns we need to name.

+
    +
  • The root of our API refers to 'user-list' and 'snippet-list'.
  • +
  • Our snippet serializer includes a field that refers to 'snippet-highlight'.
  • +
  • Our user serializer includes a field that refers to 'snippet-detail'.
  • +
  • Our snippet and user serializers include 'url' fields that by default will refer to '{model_name}-detail', which in this case will be 'snippet-detail' and 'user-detail'.
  • +
+

After adding all those names into our URLconf, our final snippets/urls.py file should look something like this:

+
# API endpoints
+urlpatterns = format_suffix_patterns([
+    url(r'^$', views.api_root),
+    url(r'^snippets/$',
+        views.SnippetList.as_view(),
+        name='snippet-list'),
+    url(r'^snippets/(?P<pk>[0-9]+)/$',
+        views.SnippetDetail.as_view(),
+        name='snippet-detail'),
+    url(r'^snippets/(?P<pk>[0-9]+)/highlight/$',
+        views.SnippetHighlight.as_view(),
+        name='snippet-highlight'),
+    url(r'^users/$',
+        views.UserList.as_view(),
+        name='user-list'),
+    url(r'^users/(?P<pk>[0-9]+)/$',
+        views.UserDetail.as_view(),
+        name='user-detail')
+])
+
+# Login and logout views for the browsable API
+urlpatterns += [
+    url(r'^api-auth/', include('rest_framework.urls',
+                               namespace='rest_framework')),
+]
+
+

Adding pagination

+

The list views for users and code snippets could end up returning quite a lot of instances, so really we'd like to make sure we paginate the results, and allow the API client to step through each of the individual pages.

+

We can change the default list style to use pagination, by modifying our settings.py file slightly. Add the following setting:

+
REST_FRAMEWORK = {
+    'PAGINATE_BY': 10
+}
+
+

Note that settings in REST framework are all namespaced into a single dictionary setting, named 'REST_FRAMEWORK', which helps keep them well separated from your other project settings.

+

We could also customize the pagination style if we needed too, but in this case we'll just stick with the default.

+

Browsing the API

+

If we open a browser and navigate to the browsable API, you'll find that you can now work your way around the API simply by following links.

+

You'll also be able to see the 'highlight' links on the snippet instances, that will take you to the highlighted code HTML representations.

+

In part 6 of the tutorial we'll look at how we can use ViewSets and Routers to reduce the amount of code we need to build our API.

+ +
+ +
+ +
+ +
+ +
+
+ + + + + + + + + + + + + + \ No newline at end of file diff --git a/tutorial/6-viewsets-and-routers.html b/tutorial/6-viewsets-and-routers.html deleted file mode 100644 index da4c6383..00000000 --- a/tutorial/6-viewsets-and-routers.html +++ /dev/null @@ -1,361 +0,0 @@ - - - - - Tutorial 6: ViewSets & Routers - Django REST framework - - - - - - - - - - - - - - - - - - - - -
- - - -
-
- - - - -
- - - -
-

Tutorial 6: ViewSets & Routers

-

REST framework includes an abstraction for dealing with ViewSets, that allows the developer to concentrate on modeling the state and interactions of the API, and leave the URL construction to be handled automatically, based on common conventions.

-

ViewSet classes are almost the same thing as View classes, except that they provide operations such as read, or update, and not method handlers such as get or put.

-

A ViewSet class is only bound to a set of method handlers at the last moment, when it is instantiated into a set of views, typically by using a Router class which handles the complexities of defining the URL conf for you.

-

Refactoring to use ViewSets

-

Let's take our current set of views, and refactor them into view sets.

-

First of all let's refactor our UserList and UserDetail views into a single UserViewSet. We can remove the two views, and replace them with a single class:

-
from rest_framework import viewsets
-
-class UserViewSet(viewsets.ReadOnlyModelViewSet):
-    """
-    This viewset automatically provides `list` and `detail` actions.
-    """
-    queryset = User.objects.all()
-    serializer_class = UserSerializer
-
-

Here we've used the ReadOnlyModelViewSet class to automatically provide the default 'read-only' operations. We're still setting the queryset and serializer_class attributes exactly as we did when we were using regular views, but we no longer need to provide the same information to two separate classes.

-

Next we're going to replace the SnippetList, SnippetDetail and SnippetHighlight view classes. We can remove the three views, and again replace them with a single class.

-
from rest_framework.decorators import detail_route
-
-class SnippetViewSet(viewsets.ModelViewSet):
-    """
-    This viewset automatically provides `list`, `create`, `retrieve`,
-    `update` and `destroy` actions.
-
-    Additionally we also provide an extra `highlight` action.
-    """
-    queryset = Snippet.objects.all()
-    serializer_class = SnippetSerializer
-    permission_classes = (permissions.IsAuthenticatedOrReadOnly,
-                          IsOwnerOrReadOnly,)
-
-    @detail_route(renderer_classes=[renderers.StaticHTMLRenderer])
-    def highlight(self, request, *args, **kwargs):
-        snippet = self.get_object()
-        return Response(snippet.highlighted)
-
-    def pre_save(self, obj):
-        obj.owner = self.request.user
-
-

This time we've used the ModelViewSet class in order to get the complete set of default read and write operations.

-

Notice that we've also used the @detail_route decorator to create a custom action, named highlight. This decorator can be used to add any custom endpoints that don't fit into the standard create/update/delete style.

-

Custom actions which use the @detail_route decorator will respond to GET requests. We can use the methods argument if we wanted an action that responded to POST requests.

-

Binding ViewSets to URLs explicitly

-

The handler methods only get bound to the actions when we define the URLConf. -To see what's going on under the hood let's first explicitly create a set of views from our ViewSets.

-

In the urls.py file we bind our ViewSet classes into a set of concrete views.

-
from snippets.views import SnippetViewSet, UserViewSet
-from rest_framework import renderers
-
-snippet_list = SnippetViewSet.as_view({
-    'get': 'list',
-    'post': 'create'
-})
-snippet_detail = SnippetViewSet.as_view({
-    'get': 'retrieve',
-    'put': 'update',
-    'patch': 'partial_update',
-    'delete': 'destroy'
-})
-snippet_highlight = SnippetViewSet.as_view({
-    'get': 'highlight'
-}, renderer_classes=[renderers.StaticHTMLRenderer])
-user_list = UserViewSet.as_view({
-    'get': 'list'
-})
-user_detail = UserViewSet.as_view({
-    'get': 'retrieve'
-})
-
-

Notice how we're creating multiple views from each ViewSet class, by binding the http methods to the required action for each view.

-

Now that we've bound our resources into concrete views, we can register the views with the URL conf as usual.

-
urlpatterns = format_suffix_patterns([
-    url(r'^$', api_root),
-    url(r'^snippets/$', snippet_list, name='snippet-list'),
-    url(r'^snippets/(?P<pk>[0-9]+)/$', snippet_detail, name='snippet-detail'),
-    url(r'^snippets/(?P<pk>[0-9]+)/highlight/$', snippet_highlight, name='snippet-highlight'),
-    url(r'^users/$', user_list, name='user-list'),
-    url(r'^users/(?P<pk>[0-9]+)/$', user_detail, name='user-detail')
-])
-
-

Using Routers

-

Because we're using ViewSet classes rather than View classes, we actually don't need to design the URL conf ourselves. The conventions for wiring up resources into views and urls can be handled automatically, using a Router class. All we need to do is register the appropriate view sets with a router, and let it do the rest.

-

Here's our re-wired urls.py file.

-
from django.conf.urls import url, include
-from snippets import views
-from rest_framework.routers import DefaultRouter
-
-# Create a router and register our viewsets with it.
-router = DefaultRouter()
-router.register(r'snippets', views.SnippetViewSet)
-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.
-urlpatterns = [
-    url(r'^', include(router.urls)),
-    url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework'))
-]
-
-

Registering the viewsets with the router is similar to providing a urlpattern. We include two arguments - the URL prefix for the views, and the viewset itself.

-

The DefaultRouter class we're using also automatically creates the API root view for us, so we can now delete the api_root method from our views module.

-

Trade-offs between views vs viewsets

-

Using viewsets can be a really useful abstraction. It helps ensure that URL conventions will be consistent across your API, minimizes the amount of code you need to write, and allows you to concentrate on the interactions and representations your API provides rather than the specifics of the URL conf.

-

That doesn't mean it's always the right approach to take. There's a similar set of trade-offs to consider as when using class-based views instead of function based views. Using viewsets is less explicit than building your views individually.

-

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.

-

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.

-

You can review the final tutorial code on GitHub, or try out a live example in the sandbox.

-

Onwards and upwards

-

We've reached the end of our tutorial. If you want to get more involved in the REST framework project, here are a few places you can start:

- -

Now go build awesome things.

-
-
-
-
- -
-
- - - - - - - - - - - diff --git a/tutorial/6-viewsets-and-routers/index.html b/tutorial/6-viewsets-and-routers/index.html new file mode 100644 index 00000000..d299743f --- /dev/null +++ b/tutorial/6-viewsets-and-routers/index.html @@ -0,0 +1,550 @@ + + + + + + + 6- Viewsets and routers - Django REST framework + + + + + + + + + + + + + + + + + + + + + +
+ + + +
+
+ + + + +
+ + + +
+ + +

Tutorial 6: ViewSets & Routers

+

REST framework includes an abstraction for dealing with ViewSets, that allows the developer to concentrate on modeling the state and interactions of the API, and leave the URL construction to be handled automatically, based on common conventions.

+

ViewSet classes are almost the same thing as View classes, except that they provide operations such as read, or update, and not method handlers such as get or put.

+

A ViewSet class is only bound to a set of method handlers at the last moment, when it is instantiated into a set of views, typically by using a Router class which handles the complexities of defining the URL conf for you.

+

Refactoring to use ViewSets

+

Let's take our current set of views, and refactor them into view sets.

+

First of all let's refactor our UserList and UserDetail views into a single UserViewSet. We can remove the two views, and replace them with a single class:

+
from rest_framework import viewsets
+
+class UserViewSet(viewsets.ReadOnlyModelViewSet):
+    """
+    This viewset automatically provides `list` and `detail` actions.
+    """
+    queryset = User.objects.all()
+    serializer_class = UserSerializer
+
+

Here we've used the ReadOnlyModelViewSet class to automatically provide the default 'read-only' operations. We're still setting the queryset and serializer_class attributes exactly as we did when we were using regular views, but we no longer need to provide the same information to two separate classes.

+

Next we're going to replace the SnippetList, SnippetDetail and SnippetHighlight view classes. We can remove the three views, and again replace them with a single class.

+
from rest_framework.decorators import detail_route
+
+class SnippetViewSet(viewsets.ModelViewSet):
+    """
+    This viewset automatically provides `list`, `create`, `retrieve`,
+    `update` and `destroy` actions.
+
+    Additionally we also provide an extra `highlight` action.
+    """
+    queryset = Snippet.objects.all()
+    serializer_class = SnippetSerializer
+    permission_classes = (permissions.IsAuthenticatedOrReadOnly,
+                          IsOwnerOrReadOnly,)
+
+    @detail_route(renderer_classes=[renderers.StaticHTMLRenderer])
+    def highlight(self, request, *args, **kwargs):
+        snippet = self.get_object()
+        return Response(snippet.highlighted)
+
+    def pre_save(self, obj):
+        obj.owner = self.request.user
+
+

This time we've used the ModelViewSet class in order to get the complete set of default read and write operations.

+

Notice that we've also used the @detail_route decorator to create a custom action, named highlight. This decorator can be used to add any custom endpoints that don't fit into the standard create/update/delete style.

+

Custom actions which use the @detail_route decorator will respond to GET requests. We can use the methods argument if we wanted an action that responded to POST requests.

+

Binding ViewSets to URLs explicitly

+

The handler methods only get bound to the actions when we define the URLConf. +To see what's going on under the hood let's first explicitly create a set of views from our ViewSets.

+

In the urls.py file we bind our ViewSet classes into a set of concrete views.

+
from snippets.views import SnippetViewSet, UserViewSet, api_root
+from rest_framework import renderers
+
+snippet_list = SnippetViewSet.as_view({
+    'get': 'list',
+    'post': 'create'
+})
+snippet_detail = SnippetViewSet.as_view({
+    'get': 'retrieve',
+    'put': 'update',
+    'patch': 'partial_update',
+    'delete': 'destroy'
+})
+snippet_highlight = SnippetViewSet.as_view({
+    'get': 'highlight'
+}, renderer_classes=[renderers.StaticHTMLRenderer])
+user_list = UserViewSet.as_view({
+    'get': 'list'
+})
+user_detail = UserViewSet.as_view({
+    'get': 'retrieve'
+})
+
+

Notice how we're creating multiple views from each ViewSet class, by binding the http methods to the required action for each view.

+

Now that we've bound our resources into concrete views, we can register the views with the URL conf as usual.

+
urlpatterns = format_suffix_patterns([
+    url(r'^$', api_root),
+    url(r'^snippets/$', snippet_list, name='snippet-list'),
+    url(r'^snippets/(?P<pk>[0-9]+)/$', snippet_detail, name='snippet-detail'),
+    url(r'^snippets/(?P<pk>[0-9]+)/highlight/$', snippet_highlight, name='snippet-highlight'),
+    url(r'^users/$', user_list, name='user-list'),
+    url(r'^users/(?P<pk>[0-9]+)/$', user_detail, name='user-detail')
+])
+
+

Using Routers

+

Because we're using ViewSet classes rather than View classes, we actually don't need to design the URL conf ourselves. The conventions for wiring up resources into views and urls can be handled automatically, using a Router class. All we need to do is register the appropriate view sets with a router, and let it do the rest.

+

Here's our re-wired urls.py file.

+
from django.conf.urls import url, include
+from snippets import views
+from rest_framework.routers import DefaultRouter
+
+# Create a router and register our viewsets with it.
+router = DefaultRouter()
+router.register(r'snippets', views.SnippetViewSet)
+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.
+urlpatterns = [
+    url(r'^', include(router.urls)),
+    url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework'))
+]
+
+

Registering the viewsets with the router is similar to providing a urlpattern. We include two arguments - the URL prefix for the views, and the viewset itself.

+

The DefaultRouter class we're using also automatically creates the API root view for us, so we can now delete the api_root method from our views module.

+

Trade-offs between views vs viewsets

+

Using viewsets can be a really useful abstraction. It helps ensure that URL conventions will be consistent across your API, minimizes the amount of code you need to write, and allows you to concentrate on the interactions and representations your API provides rather than the specifics of the URL conf.

+

That doesn't mean it's always the right approach to take. There's a similar set of trade-offs to consider as when using class-based views instead of function based views. Using viewsets is less explicit than building your views individually.

+

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.

+

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.

+

You can review the final tutorial code on GitHub, or try out a live example in the sandbox.

+

Onwards and upwards

+

We've reached the end of our tutorial. If you want to get more involved in the REST framework project, here are a few places you can start:

+ +

Now go build awesome things.

+ +
+ +
+ +
+ +
+ +
+
+ + + + + + + + + + + + + + \ No newline at end of file diff --git a/tutorial/quickstart.html b/tutorial/quickstart.html deleted file mode 100644 index 07d38da8..00000000 --- a/tutorial/quickstart.html +++ /dev/null @@ -1,380 +0,0 @@ - - - - - Quickstart - Django REST framework - - - - - - - - - - - - - - - - - - - - -
- - - -
-
- - - - -
- - - -
-

Quickstart

-

We're going to create a simple API to allow admin users to view and edit the users and groups in the system.

-

Project setup

-

Create a new Django project named tutorial, then start a new app called quickstart.

-
# Create the project directory
-mkdir tutorial
-cd tutorial
-
-# Create a virtualenv to isolate our package dependencies locally
-virtualenv env
-source env/bin/activate  # On Windows use `env\Scripts\activate`
-
-# Install Django and Django REST framework into the virtualenv
-pip install django
-pip install djangorestframework
-
-# Set up a new project with a single application
-django-admin.py startproject tutorial .
-cd tutorial
-django-admin.py startapp quickstart
-cd ..
-
-

Now sync your database for the first time:

-
python manage.py syncdb
-
-

Make sure to create an initial user named admin with a password of password. We'll authenticate as that user later in our example.

-

Once you've set up a database and got everything synced and ready to go, open up the app's directory and we'll get coding...

-

Serializers

-

First up we're going to define some serializers. Let's create a new module named tutorial/quickstart/serializers.py that we'll use for our data representations.

-
from django.contrib.auth.models import User, Group
-from rest_framework import serializers
-
-
-class UserSerializer(serializers.HyperlinkedModelSerializer):
-    class Meta:
-        model = User
-        fields = ('url', 'username', 'email', 'groups')
-
-
-class GroupSerializer(serializers.HyperlinkedModelSerializer):
-    class Meta:
-        model = Group
-        fields = ('url', 'name')
-
-

Notice that we're using hyperlinked relations in this case, with HyperlinkedModelSerializer. You can also use primary key and various other relationships, but hyperlinking is good RESTful design.

-

Views

-

Right, we'd better write some views then. Open tutorial/quickstart/views.py and get typing.

-
from django.contrib.auth.models import User, Group
-from rest_framework import viewsets
-from tutorial.quickstart.serializers import UserSerializer, GroupSerializer
-
-
-class UserViewSet(viewsets.ModelViewSet):
-    """
-    API endpoint that allows users to be viewed or edited.
-    """
-    queryset = User.objects.all()
-    serializer_class = UserSerializer
-
-
-class GroupViewSet(viewsets.ModelViewSet):
-    """
-    API endpoint that allows groups to be viewed or edited.
-    """
-    queryset = Group.objects.all()
-    serializer_class = GroupSerializer
-
-

Rather than write multiple views we're grouping together all the common behavior into classes called ViewSets.

-

We can easily break these down into individual views if we need to, but using viewsets keeps the view logic nicely organized as well as being very concise.

-

Notice that our viewset classes here are a little different from those in the frontpage example, as they include queryset and serializer_class attributes, instead of a model attribute.

-

For trivial cases you can simply set a model attribute on the ViewSet class and the serializer and queryset will be automatically generated for you. Setting the queryset and/or serializer_class attributes gives you more explicit control of the API behaviour, and is the recommended style for most applications.

-

URLs

-

Okay, now let's wire up the API URLs. On to tutorial/urls.py...

-
from django.conf.urls import url, include
-from rest_framework import routers
-from tutorial.quickstart import views
-
-router = routers.DefaultRouter()
-router.register(r'users', views.UserViewSet)
-router.register(r'groups', views.GroupViewSet)
-
-# Wire up our API using automatic URL routing.
-# Additionally, we include login URLs for the browseable API.
-urlpatterns = [
-    url(r'^', include(router.urls)),
-    url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework'))
-]
-
-

Because we're using viewsets instead of views, we can automatically generate the URL conf for our API, by simply registering the viewsets with a router class.

-

Again, if we need more control over the API URLs we can simply drop down to using regular class based views, and writing the URL conf explicitly.

-

Finally, we're including default login and logout views for use with the browsable API. That's optional, but useful if your API requires authentication and you want to use the browsable API.

-

Settings

-

We'd also like to set a few global settings. We'd like to turn on pagination, and we want our API to only be accessible to admin users. The settings module will be in tutorial/settings.py

-
INSTALLED_APPS = (
-    ...
-    'rest_framework',
-)
-
-REST_FRAMEWORK = {
-    'DEFAULT_PERMISSION_CLASSES': ('rest_framework.permissions.IsAdminUser',),
-    'PAGINATE_BY': 10
-}
-
-

Okay, we're done.

-
-

Testing our API

-

We're now ready to test the API we've built. Let's fire up the server from the command line.

-
python ./manage.py runserver
-
-

We can now access our API, both from the command-line, using tools like curl...

-
bash: curl -H 'Accept: application/json; indent=4' -u admin:password http://127.0.0.1:8000/users/
-{
-    "count": 2,
-    "next": null,
-    "previous": null,
-    "results": [
-        {
-            "email": "admin@example.com",
-            "groups": [],
-            "url": "http://127.0.0.1:8000/users/1/",
-            "username": "admin"
-        },
-        {
-            "email": "tom@example.com",
-            "groups": [                ],
-            "url": "http://127.0.0.1:8000/users/2/",
-            "username": "tom"
-        }
-    ]
-}
-
-

Or directly through the browser...

-

Quick start image

-

If you're working through the browser, make sure to login using the control in the top right corner.

-

Great, that was easy!

-

If you want to get a more in depth understanding of how REST framework fits together head on over to the tutorial, or start browsing the API guide.

-
-
-
-
- -
-
- - - - - - - - - - - diff --git a/tutorial/quickstart/index.html b/tutorial/quickstart/index.html new file mode 100644 index 00000000..0aad281b --- /dev/null +++ b/tutorial/quickstart/index.html @@ -0,0 +1,571 @@ + + + + + + + Quickstart - Django REST framework + + + + + + + + + + + + + + + + + + + + + +
+ + + +
+
+ + + + +
+ +
+ +
+ + +
+
+ +
+ + +

Quickstart

+

We're going to create a simple API to allow admin users to view and edit the users and groups in the system.

+

Project setup

+

Create a new Django project named tutorial, then start a new app called quickstart.

+
# Create the project directory
+mkdir tutorial
+cd tutorial
+
+# Create a virtualenv to isolate our package dependencies locally
+virtualenv env
+source env/bin/activate  # On Windows use `env\Scripts\activate`
+
+# Install Django and Django REST framework into the virtualenv
+pip install django
+pip install djangorestframework
+
+# Set up a new project with a single application
+django-admin.py startproject tutorial
+cd tutorial
+django-admin.py startapp quickstart
+cd ..
+
+

Now sync your database for the first time:

+
python manage.py migrate
+
+

We'll also create an initial user named admin with a password of password. We'll authenticate as that user later in our example.

+
python manage.py createsuperuser
+
+

Once you've set up a database and initial user created and ready to go, open up the app's directory and we'll get coding...

+

Serializers

+

First up we're going to define some serializers. Let's create a new module named tutorial/quickstart/serializers.py that we'll use for our data representations.

+
from django.contrib.auth.models import User, Group
+from rest_framework import serializers
+
+
+class UserSerializer(serializers.HyperlinkedModelSerializer):
+    class Meta:
+        model = User
+        fields = ('url', 'username', 'email', 'groups')
+
+
+class GroupSerializer(serializers.HyperlinkedModelSerializer):
+    class Meta:
+        model = Group
+        fields = ('url', 'name')
+
+

Notice that we're using hyperlinked relations in this case, with HyperlinkedModelSerializer. You can also use primary key and various other relationships, but hyperlinking is good RESTful design.

+

Views

+

Right, we'd better write some views then. Open tutorial/quickstart/views.py and get typing.

+
from django.contrib.auth.models import User, Group
+from rest_framework import viewsets
+from tutorial.quickstart.serializers import UserSerializer, GroupSerializer
+
+
+class UserViewSet(viewsets.ModelViewSet):
+    """
+    API endpoint that allows users to be viewed or edited.
+    """
+    queryset = User.objects.all()
+    serializer_class = UserSerializer
+
+
+class GroupViewSet(viewsets.ModelViewSet):
+    """
+    API endpoint that allows groups to be viewed or edited.
+    """
+    queryset = Group.objects.all()
+    serializer_class = GroupSerializer
+
+

Rather than write multiple views we're grouping together all the common behavior into classes called ViewSets.

+

We can easily break these down into individual views if we need to, but using viewsets keeps the view logic nicely organized as well as being very concise.

+

Notice that our viewset classes here are a little different from those in the frontpage example, as they include queryset and serializer_class attributes, instead of a model attribute.

+

For trivial cases you can simply set a model attribute on the ViewSet class and the serializer and queryset will be automatically generated for you. Setting the queryset and/or serializer_class attributes gives you more explicit control of the API behaviour, and is the recommended style for most applications.

+

URLs

+

Okay, now let's wire up the API URLs. On to tutorial/urls.py...

+
from django.conf.urls import url, include
+from rest_framework import routers
+from tutorial.quickstart import views
+
+router = routers.DefaultRouter()
+router.register(r'users', views.UserViewSet)
+router.register(r'groups', views.GroupViewSet)
+
+# Wire up our API using automatic URL routing.
+# Additionally, we include login URLs for the browseable API.
+urlpatterns = [
+    url(r'^', include(router.urls)),
+    url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework'))
+]
+
+

Because we're using viewsets instead of views, we can automatically generate the URL conf for our API, by simply registering the viewsets with a router class.

+

Again, if we need more control over the API URLs we can simply drop down to using regular class based views, and writing the URL conf explicitly.

+

Finally, we're including default login and logout views for use with the browsable API. That's optional, but useful if your API requires authentication and you want to use the browsable API.

+

Settings

+

We'd also like to set a few global settings. We'd like to turn on pagination, and we want our API to only be accessible to admin users. The settings module will be in tutorial/settings.py

+
INSTALLED_APPS = (
+    ...
+    'rest_framework',
+)
+
+REST_FRAMEWORK = {
+    'DEFAULT_PERMISSION_CLASSES': ('rest_framework.permissions.IsAdminUser',),
+    'PAGINATE_BY': 10
+}
+
+

Okay, we're done.

+
+

Testing our API

+

We're now ready to test the API we've built. Let's fire up the server from the command line.

+
python ./manage.py runserver
+
+

We can now access our API, both from the command-line, using tools like curl...

+
bash: curl -H 'Accept: application/json; indent=4' -u admin:password http://127.0.0.1:8000/users/
+{
+    "count": 2,
+    "next": null,
+    "previous": null,
+    "results": [
+        {
+            "email": "admin@example.com",
+            "groups": [],
+            "url": "http://127.0.0.1:8000/users/1/",
+            "username": "admin"
+        },
+        {
+            "email": "tom@example.com",
+            "groups": [                ],
+            "url": "http://127.0.0.1:8000/users/2/",
+            "username": "tom"
+        }
+    ]
+}
+
+

Or directly through the browser...

+

Quick start image

+

If you're working through the browser, make sure to login using the control in the top right corner.

+

Great, that was easy!

+

If you want to get a more in depth understanding of how REST framework fits together head on over to the tutorial, or start browsing the API guide.

+ +
+ +
+ +
+ +
+ +
+
+ + + + + + + + + + + + + + \ No newline at end of file -- cgit v1.2.3