diff --git a/api-guide/contentnegotiation.html b/api-guide/contentnegotiation.html new file mode 100644 index 000000000..09171be09 --- /dev/null +++ b/api-guide/contentnegotiation.html @@ -0,0 +1,152 @@ + +
+ +++HTTP has provisions for several mechanisms for "content negotiation" -- the process of selecting the best representation for a given response when there are multiple representations available. -- RFC 2616, Fielding et al.
+
++If you're doing REST-based web service stuff ... you should ignore request.POST.
+— Malcom Tredinnick, Django developers group
+
REST framework's Request
class extends the standard HttpRequest
, adding support for parsing multiple content types, allowing browser-based PUT
, DELETE
and other methods, and adding flexible per-request authentication.
request.method
returns the uppercased string representation of the request's HTTP method.
Browser-based PUT
, DELETE
and other requests are supported, and can be made by using a hidden form field named _method
in a regular POST
form.
request.content
, returns a string object representing the mimetype of the HTTP request's body, if one exists.
request.DATA
returns the parsed content of the request body. This is similar to the standard HttpRequest.POST
attribute except that:
POST
, meaning that you can access the content of PUT
and PATCH
requests.request.FILES
returns any uploaded files that may be present in the content of the request body. This is the same as the standard HttpRequest
behavior, except that the same flexible request parsing that is used for request.DATA
.
This allows you to support file uploads from multiple content-types. For example you can write a parser that supports POST
ing the raw content of a file, instead of using form-encoded file uploads.
request.user
returns a django.contrib.auth.models.User
instance.
request.auth
returns any additional authentication context that may not be contained in request.user
. The exact behavior of request.auth
depends on what authentication has been set in request.authentication
. For many types of authentication this will simply be None
, but it may also be an object representing a permission scope, an expiry time, or any other information that might be contained in a token-based authentication scheme.
request.parsers
should be set to a list of Parser
instances that can be used to parse the content of the request body.
request.parsers
may no longer be altered once request.DATA
, request.FILES
or request.POST
have been accessed.
If you're using the djangorestframework.views.View
class... [TODO]
request.stream
returns a stream representing the content of the request body.
You will not typically need to access request.stream
, unless you're writing a Parser
class.
request.authentication
should be set to a list of Authentication
instances that can be used to authenticate the request.
request.authentication
may no longer be altered once request.user
or request.auth
have been accessed.
If you're using the djangorestframework.views.View
class... [TODO]
++Unlike basic HttpResponse objects, TemplateResponse objects retain the details of the context that was provided by the view to compute the response. The final output of the response is not computed until it is needed, later in the response process.
+ +
REST framework supports HTTP content negotiation by providing a Response
class which allows you to return content that can be rendered into multiple content types, depending on the client request.
The Response
class subclasses Django's TemplateResponse
. Response
objects are initialised with content, which should consist of native python primatives. REST framework then uses standard HTTP content negotiation to determine how it should render the final response content.
There's no requirement for you to use the Response
class, you can also return regular HttpResponse
objects from your views if you want, but it does provide a better interface for returning Web API responses.
++Expanding the usefulness of the serializers is something that we would +like to address. However, it's not a trivial problem, and it +will take some serious design work. Any offers to help out in this +area would be gratefully accepted.
+— Russell Keith-Magee, Django users group
+
Serializers allow complex data such as querysets and model instances to be converted to native python datatypes that can then be easily rendered into JSON
, XML
or other content types. Serializers also provide deserialization, allowing parsed data to be converted back into complex types, after first validating the incoming data.
REST framework's serializers work very similarly to Django's Form
and ModelForm
classes. It provides a Serializer
class which gives you a powerful, generic way to control the output of your responses, as well as a ModelSerializer
class which provides a useful shortcut for creating serializers that deal with model instances and querysets.
Let's start by creating a simple object we can use for example purposes:
+class Comment(object):
+ def __init__(self, email, content, created=None):
+ self.email = email
+ self.content = content
+ self.created = created or datetime.datetime.now()
+
+comment = Comment(email='leila@example.com', content='foo bar')
+
+We'll declare a serializer that we can use to serialize and deserialize Comment
objects.
+Declaring a serializer looks very similar to declaring a form:
class CommentSerializer(serializers.Serializer):
+ email = serializers.EmailField()
+ content = serializers.CharField(max_length=200)
+ created = serializers.DateTimeField()
+
+ def restore_object(self, attrs, instance=None):
+ if instance:
+ instance.title = attrs['title']
+ instance.content = attrs['content']
+ instance.created = attrs['created']
+ return instance
+ return Comment(**attrs)
+
+The first part of serializer class defines the fields that get serialized/deserialized. The restore_object
method defines how fully fledged instances get created when deserializing data. The restore_object
method is optional, and is only required if we want our serializer to support deserialization.
We can now use CommentSerializer
to serialize a comment, or list of comments. Again, using the Serializer
class looks a lot like using a Form
class.
serializer = CommentSerializer(instance=comment)
+serializer.data
+# {'email': u'leila@example.com', 'content': u'foo bar', 'created': datetime.datetime(2012, 8, 22, 16, 20, 9, 822774)}
+
+At this point we've translated the model instance into python native datatypes. To finalise the serialization process we render the data into json
.
stream = JSONRenderer().render(data)
+stream
+# '{"email": "leila@example.com", "content": "foo bar", "created": "2012-08-22T16:20:09.822"}'
+
+Deserialization is similar. First we parse a stream into python native datatypes...
+data = JSONParser().parse(stream)
+
+...then we restore those native datatypes into a fully populated object instance.
+serializer = CommentSerializer(data)
+serializer.is_valid()
+# True
+serializer.object
+# <Comment object at 0x10633b2d0>
+>>> serializer.deserialize('json', stream)
+
+When deserializing data, you always need to call is_valid()
before attempting to access the deserialized object. If any validation errors occur, the .errors
and .non_field_errors
properties will contain the resulting error messages.
TODO: Describe validation in more depth
+The previous example is fine for dealing with objects that only have simple datatypes, but sometimes we also need to be able to represent more complex objects, +where some of the attributes of an object might not be simple datatypes such as strings, dates or integers.
+The Serializer
class is itself a type of Field
, and can be used to represent relationships where one object type is nested inside another.
class UserSerializer(serializers.Serializer):
+ email = serializers.EmailField()
+ username = serializers.CharField()
+
+ def restore_object(self, attrs, instance=None):
+ return User(**attrs)
+
+class CommentSerializer(serializers.Serializer):
+ user = serializers.UserSerializer()
+ title = serializers.CharField()
+ content = serializers.CharField(max_length=200)
+ created = serializers.DateTimeField()
+
+ def restore_object(self, attrs, instance=None):
+ return Comment(**attrs)
+
+If you want to create a custom field, you'll probably want to override either one or both of the .to_native()
and .from_native()
methods. These two methods are used to convert between the intial datatype, and a primative, serializable datatype. Primative datatypes may be any of a number, string, date/time/datetime or None. They may also be any list or dictionary like object that only contains other primative objects.
The .to_native()
method is called to convert the initial datatype into a primative, serializable datatype. The from_native()
method is called to restore a primative datatype into it's initial representation.
Let's look at an example of serializing a class that represents an RGB color value:
+class Color(object):
+ """
+ A color represented in the RGB colorspace.
+ """
+
+ def __init__(self, red, green, blue):
+ assert(red >= 0 and green >= 0 and blue >= 0)
+ assert(red < 256 and green < 256 and blue < 256)
+ self.red, self.green, self.blue = red, green, blue
+
+class ColourField(Field):
+ """
+ Color objects are serialized into "rgb(#, #, #)" notation.
+ """
+
+ def to_native(self, obj):
+ return "rgb(%d, %d, %d)" % (obj.red, obj.green, obj.blue)
+
+ def from_native(self, data):
+ data = data.strip('rgb(').rstrip(')')
+ red, green, blue = [int(col) for col in data.split(',')]
+ return Color(red, green, blue)
+
+By default field values are treated as mapping to an attribute on the object. If you need to customize how the field value is accessed and set you need to override .field_to_native()
and/or .field_from_native()
.
As an example, let's create a field that can be used represent the class name of the object being serialized:
+class ClassNameField(Field):
+ def field_to_native(self, obj, field_name):
+ """
+ Serialize the object's class name, not an attribute of the object.
+ """
+ return obj.__class__.__name__
+
+ def field_from_native(self, data, field_name, into):
+ """
+ We don't want to set anything when we revert this field.
+ """
+ pass
+
+Often you'll want serializer classes that map closely to model definitions.
+The ModelSerializer
class lets you automatically create a Serializer class with fields that corrospond to the Model fields.
class AccountSerializer(ModelSerializer):
+ class Meta:
+ model = Account
+
+[TODO: Explain model field to serializer field mapping in more detail]
+You can add extra fields to a ModelSerializer
or override the default fields by declaring fields on the class, just as you would for a Serializer
class.
class AccountSerializer(ModelSerializer):
+ url = CharField(source='get_absolute_url', readonly=True)
+ group = NaturalKeyField()
+
+ class Meta:
+ model = Account
+
+Extra fields can corrospond to any property or callable on the model.
+When serializing model instances, there are a number of different ways you might choose to represent relationships. The default representation is to use the primary keys of the related instances.
+Alternative representations include serializing using natural keys, serializing complete nested representations, or serializing using a custom representation, such as a URL that uniquely identifies the model instances.
+The PrimaryKeyField
and NaturalKeyField
fields provide alternative flat representations.
The ModelSerializer
class can itself be used as a field, in order to serialize relationships using nested representations.
The RelatedField
class may be subclassed to create a custom represenation of a relationship. The subclass should override .to_native()
, and optionally .from_native()
if deserialization is supported.
All the relational fields may be used for any relationship or reverse relationship on a model.
+If you only want a subset of the default fields to be used in a model serializer, you can do so using fields
or exclude
options, just as you would with a ModelForm
.
For example:
+class AccountSerializer(ModelSerializer):
+ class Meta:
+ model = Account
+ exclude = ('id',)
+
+The fields
and exclude
options may also be set by passing them to the serialize()
method.
[TODO: Possibly only allow .serialize(fields=…) in FixtureSerializer for backwards compatability, but remove for ModelSerializer]
+The default ModelSerializer
uses primary keys for relationships, but you can also easily generate nested representations using the nested
option:
class AccountSerializer(ModelSerializer):
+ class Meta:
+ model = Account
+ exclude = ('id',)
+ nested = True
+
+The nested
option may be set to either True
, False
, or an integer value. If given an integer value it indicates the depth of relationships that should be traversed before reverting to a flat representation.
When serializing objects using a nested representation any occurances of recursion will be recognised, and will fall back to using a flat representation.
+The nested
option may also be set by passing it to the serialize()
method.
[TODO: Possibly only allow .serialize(nested=…) in FixtureSerializer]
+class AccountSerializer(ModelSerializer):
+ class Meta:
+ model = Account
+
+ def get_nested_field(self, model_field):
+ return ModelSerializer()
+
+ def get_related_field(self, model_field):
+ return NaturalKeyField()
+
+ def get_field(self, model_field):
+ return Field()
+
+ ++418 I'm a teapot - Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout.
+— RFC 2324, Hyper Text Coffee Pot Control Protocol
+
Using bare status codes in your responses isn't recommended. REST framework includes a set of named constants that you can use to make more code more obvious and readable.
+from djangorestframework import status
+
+def empty_view(self):
+ content = {'please move along': 'nothing to see here'}
+ return Response(content, status=status.HTTP_404_NOT_FOUND)
+
+The full set of HTTP status codes included in the status
module is listed below.
For more information on proper usage of HTTP status codes see RFC 2616 +and RFC 6585.
+This class of status code indicates a provisional response. There are no 1xx status codes used in REST framework by default.
+HTTP_100_CONTINUE
+HTTP_101_SWITCHING_PROTOCOLS
+
+This class of status code indicates that the client's request was successfully received, understood, and accepted.
+HTTP_200_OK
+HTTP_201_CREATED
+HTTP_202_ACCEPTED
+HTTP_203_NON_AUTHORITATIVE_INFORMATION
+HTTP_204_NO_CONTENT
+HTTP_205_RESET_CONTENT
+HTTP_206_PARTIAL_CONTENT
+
+This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request.
+HTTP_300_MULTIPLE_CHOICES
+HTTP_301_MOVED_PERMANENTLY
+HTTP_302_FOUND
+HTTP_303_SEE_OTHER
+HTTP_304_NOT_MODIFIED
+HTTP_305_USE_PROXY
+HTTP_306_RESERVED
+HTTP_307_TEMPORARY_REDIRECT
+
+The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
+HTTP_400_BAD_REQUEST
+HTTP_401_UNAUTHORIZED
+HTTP_402_PAYMENT_REQUIRED
+HTTP_403_FORBIDDEN
+HTTP_404_NOT_FOUND
+HTTP_405_METHOD_NOT_ALLOWED
+HTTP_406_NOT_ACCEPTABLE
+HTTP_407_PROXY_AUTHENTICATION_REQUIRED
+HTTP_408_REQUEST_TIMEOUT
+HTTP_409_CONFLICT
+HTTP_410_GONE
+HTTP_411_LENGTH_REQUIRED
+HTTP_412_PRECONDITION_FAILED
+HTTP_413_REQUEST_ENTITY_TOO_LARGE
+HTTP_414_REQUEST_URI_TOO_LONG
+HTTP_415_UNSUPPORTED_MEDIA_TYPE
+HTTP_416_REQUESTED_RANGE_NOT_SATISFIABLE
+HTTP_417_EXPECTATION_FAILED
+HTTP_428_PRECONDITION_REQUIRED
+HTTP_429_TOO_MANY_REQUESTS
+HTTP_431_REQUEST_HEADER_FIELDS_TOO_LARGE
+
+Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
+HTTP_500_INTERNAL_SERVER_ERROR
+HTTP_501_NOT_IMPLEMENTED
+HTTP_502_BAD_GATEWAY
+HTTP_503_SERVICE_UNAVAILABLE
+HTTP_504_GATEWAY_TIMEOUT
+HTTP_505_HTTP_VERSION_NOT_SUPPORTED
+HTTP_511_NETWORD_AUTHENTICATION_REQUIRED
+
+ ++The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components.
+— Roy Fielding, Architectural Styles and the Design of Network-based Software Architectures
+
As a rule, it's probably better practice to return absolute URIs from you web APIs, such as http://example.com/foobar
, rather than returning relative URIs, such as /foobar
.
The advantages of doing so are:
+REST framework provides two utility functions to make it more simple to return absolute URIs from your Web API.
+There's no requirement for you to use them, but if you do then the self-describing API will be able to automatically hyperlink it's output for you, which makes browsing the API much easier.
+Has the same behavior as django.core.urlresolvers.reverse
, except that it returns a fully qualified URL, using the request to determine the host and port.
from djangorestframework.utils import reverse
+from djangorestframework.views import APIView
+
+class MyView(APIView):
+ def get(self, request):
+ content = {
+ ...
+ 'url': reverse('year-summary', request, args=[1945])
+ }
+ return Response(content)
+
+Has the same behavior as django.core.urlresolvers.reverse_lazy
, except that it returns a fully qualified URL, using the request to determine the host and port.
++Django's class based views are a welcome departure from the old-style views.
+ +
REST framework provides a simple APIView
class, built on Django's django.generics.views.View
. The APIView
class ensures five main things:
Request
instances.Request
instances will have their renderers
and authentication
attributes automatically set. Response
instances will have their parsers
and serializer
attributes automatically set.APIException
exceptions will be caught and return appropriate responses.Additionally there are a some minor extras, such as providing a default options
handler, setting some common headers on the response prior to return, and providing the useful initial()
and final()
hooks.
Describe that APIView handles regular .get(), .post(), .put(), .delete() etc...
+A toolkit for building well-connected, self-describing Web APIs.
+WARNING: This documentation is for the 2.0 redesign of REST framework. It is a work in progress.
+Django REST framework is a lightweight library that makes it easy to build Web APIs. It is designed as a modular and easy to customize architecture, based on Django's class based views.
+Web APIs built using REST framework are fully self-describing and web browseable - a huge useability win for your developers. It also supports a wide range of media types, authentication and permission policies out of the box.
+REST framework requires the following:
+The following packages are optional:
+If you're installing using pip
, all requirements and optional packages will be installed by default.
WARNING: These instructions will only become valid once this becomes the master version
+Install using pip
...
pip install djangorestframework
+
+...or clone the project from github.
+git clone git@github.com:tomchristie/django-rest-framework.git
+pip install -r requirements.txt
+
+Add djangorestframework
to your INSTALLED_APPS
.
INSTALLED_APPS = (
+ ...
+ 'djangorestframework',
+)
+
+If you're intending to use the browserable API you'll want to add REST framework's login and logout views. Add the following to your root urls.py
file.
urlpatterns = patterns('',
+ ...
+ url(r'^auth', include('djangorestframework.urls', namespace='djangorestframework'))
+)
+
+TODO
+The tutorial will walk you through the building blocks that make up REST framework. It'll take a little while to get through, but it'll give you a comprehensive understanding of how everything fits together, and is highly recommended reading.
+The API guide is your complete reference manual to all the functionality provided by REST framework.
+General guides to using REST framework.
+Copyright (c) 2011-2012, Tom Christie +All rights reserved.
+Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions are met:
+Redistributions of source code must retain the above copyright notice, this +list of conditions and the following disclaimer. +Redistributions in binary form must reproduce the above copyright notice, this +list of conditions and the following disclaimer in the documentation and/or +other materials provided with the distribution.
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE +DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE +FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR +SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER +CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, +OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+t |