diff options
Diffstat (limited to 'docs/api-guide')
| -rw-r--r-- | docs/api-guide/authentication.md | 126 | ||||
| -rw-r--r-- | docs/api-guide/content-negotiation.md | 66 | ||||
| -rw-r--r-- | docs/api-guide/exceptions.md | 88 | ||||
| -rw-r--r-- | docs/api-guide/fields.md | 278 | ||||
| -rw-r--r-- | docs/api-guide/format-suffixes.md | 61 | ||||
| -rw-r--r-- | docs/api-guide/generic-views.md | 187 | ||||
| -rw-r--r-- | docs/api-guide/pagination.md | 125 | ||||
| -rw-r--r-- | docs/api-guide/parsers.md | 161 | ||||
| -rw-r--r-- | docs/api-guide/permissions.md | 118 | ||||
| -rw-r--r-- | docs/api-guide/renderers.md | 267 | ||||
| -rw-r--r-- | docs/api-guide/requests.md | 128 | ||||
| -rw-r--r-- | docs/api-guide/responses.md | 94 | ||||
| -rw-r--r-- | docs/api-guide/reverse.md | 55 | ||||
| -rw-r--r-- | docs/api-guide/serializers.md | 276 | ||||
| -rw-r--r-- | docs/api-guide/settings.md | 153 | ||||
| -rw-r--r-- | docs/api-guide/status-codes.md | 95 | ||||
| -rw-r--r-- | docs/api-guide/throttling.md | 157 | ||||
| -rw-r--r-- | docs/api-guide/views.md | 168 |
18 files changed, 2603 insertions, 0 deletions
diff --git a/docs/api-guide/authentication.md b/docs/api-guide/authentication.md new file mode 100644 index 00000000..889d16c0 --- /dev/null +++ b/docs/api-guide/authentication.md @@ -0,0 +1,126 @@ +<a class="github" href="authentication.py"></a> + +# Authentication + +> Auth needs to be pluggable. +> +> — Jacob Kaplan-Moss, ["REST worst practices"][cite] + +Authentication is the mechanism of associating an incoming request with a set of identifying credentials, such as the user the request came from, or the token that it was signed with. The [permission] and [throttling] policies can then use those credentials to determine if the request should be permitted. + +REST framework provides a number of authentication policies out of the box, and also allows you to implement custom policies. + +Authentication will run the first time either the `request.user` or `request.auth` properties are accessed, and determines how those properties are initialized. + +The `request.user` property will typically be set to an instance of the `contrib.auth` package's `User` class. + +The `request.auth` property is used for any additional authentication information, for example, it may be used to represent an authentication token that the request was signed with. + +## How authentication is determined + +The authentication policy is always defined as a list of classes. REST framework will attempt to authenticate with each class in the list, and will set `request.user` and `request.auth` using the return value of the first class that successfully authenticates. + +If no class authenticates, `request.user` will be set to an instance of `django.contrib.auth.models.AnonymousUser`, and `request.auth` will be set to `None`. + +The value of `request.user` and `request.auth` for unauthenticated requests can be modified using the `UNAUTHENTICATED_USER` and `UNAUTHENTICATED_TOKEN` settings. + +## Setting the authentication policy + +The default authentication policy may be set globally, using the `DEFAULT_AUTHENTICATION_CLASSES` setting. For example. + + REST_FRAMEWORK = { + 'DEFAULT_AUTHENTICATION_CLASSES': ( + 'rest_framework.authentication.UserBasicAuthentication', + 'rest_framework.authentication.SessionAuthentication', + ) + } + +You can also set the authentication policy on a per-view basis, using the `APIView` class based views. + + class ExampleView(APIView): + authentication_classes = (SessionAuthentication, UserBasicAuthentication) + permission_classes = (IsAuthenticated,) + + def get(self, request, format=None): + content = { + 'user': unicode(request.user), # `django.contrib.auth.User` instance. + 'auth': unicode(request.auth), # None + } + return Response(content) + +Or, if you're using the `@api_view` decorator with function based views. + + @api_view(['GET']) + @authentication_classes((SessionAuthentication, UserBasicAuthentication)) + @permissions_classes((IsAuthenticated,)) + def example_view(request, format=None): + content = { + 'user': unicode(request.user), # `django.contrib.auth.User` instance. + 'auth': unicode(request.auth), # None + } + return Response(content) + +# API Reference + +## BasicAuthentication + +This policy uses [HTTP Basic Authentication][basicauth], signed against a user's username and password. Basic authentication is generally only appropriate for testing. + +If successfully authenticated, `BasicAuthentication` provides the following credentials. + +* `request.user` will be a `django.contrib.auth.models.User` instance. +* `request.auth` will be `None`. + +**Note:** If you use `BasicAuthentication` in production you must ensure that your API is only available over `https` only. You should also ensure that your API clients will always re-request the username and password at login, and will never store those details to persistent storage. + +## TokenAuthentication + +This policy uses a simple token-based HTTP Authentication scheme. Token authentication is appropriate for client-server setups, such as native desktop and mobile clients. + +To use the `TokenAuthentication` policy, include `rest_framework.authtoken` in your `INSTALLED_APPS` setting. + +You'll also need to create tokens for your users. + + from rest_framework.authtoken.models import Token + + token = Token.objects.create(user=...) + print token.key + +For clients to authenticate, the token key should be included in the `Authorization` HTTP header. The key should be prefixed by the string literal "Token", with whitespace separating the two strings. For example: + + Authorization: Token 9944b09199c62bcf9418ad846dd0e4bbdfc6ee4b + +If successfully authenticated, `TokenAuthentication` provides the following credentials. + +* `request.user` will be a `django.contrib.auth.models.User` instance. +* `request.auth` will be a `rest_framework.tokenauth.models.BasicToken` instance. + +**Note:** If you use `TokenAuthentication` in production you must ensure that your API is only available over `https` only. + +## OAuthAuthentication + +This policy uses the [OAuth 2.0][oauth] protocol to authenticate requests. OAuth is appropriate for server-server setups, such as when you want to allow a third-party service to access your API on a user's behalf. + +If successfully authenticated, `OAuthAuthentication` provides the following credentials. + +* `request.user` will be a `django.contrib.auth.models.User` instance. +* `request.auth` will be a `rest_framework.models.OAuthToken` instance. + +## SessionAuthentication + +This policy uses Django's default session backend for authentication. Session authentication is appropriate for AJAX clients that are running in the same session context as your website. + +If successfully authenticated, `SessionAuthentication` provides the following credentials. + +* `request.user` will be a `django.contrib.auth.models.User` instance. +* `request.auth` will be `None`. + +# Custom authentication + +To implement a custom authentication policy, subclass `BaseAuthentication` and override the `.authenticate(self, request)` method. The method should return a two-tuple of `(user, auth)` if authentication succeeds, or `None` otherwise. + +[cite]: http://jacobian.org/writing/rest-worst-practices/ +[basicauth]: http://tools.ietf.org/html/rfc2617 +[oauth]: http://oauth.net/2/ +[permission]: permissions.md +[throttling]: throttling.md diff --git a/docs/api-guide/content-negotiation.md b/docs/api-guide/content-negotiation.md new file mode 100644 index 00000000..10288c94 --- /dev/null +++ b/docs/api-guide/content-negotiation.md @@ -0,0 +1,66 @@ +<a class="github" href="negotiation.py"></a> + +# Content negotiation + +> 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][cite], Fielding et al. + +[cite]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html + +Content negotiation is the process of selecting one of multiple possible representations to return to a client, based on client or server preferences. + +## Determining the accepted renderer + +REST framework uses a simple style of content negotiation to determine which media type should be returned to a client, based on the available renderers, the priorities of each of those renderers, and the client's `Accept:` header. The style used is partly client-driven, and partly server-driven. + +1. More specific media types are given preference to less specific media types. +2. If multiple media types have the same specificity, then preference is given to based on the ordering of the renderers configured for the given view. + +For example, given the following `Accept` header: + + application/json; indent=4, application/json, application/yaml, text/html, */* + +The priorities for each of the given media types would be: + +* `application/json; indent=4` +* `application/json`, `application/yaml` and `text/html` +* `*/*` + +If the requested view was only configured with renderers for `YAML` and `HTML`, then REST framework would select whichever renderer was listed first in the `renderer_classes` list or `DEFAULT_RENDERER_CLASSES` setting. + +For more information on the `HTTP Accept` header, see [RFC 2616][accept-header] + +--- + +**Note**: "q" values are not taken into account by REST framework when determining preference. The use of "q" values negatively impacts caching, and in the author's opinion they are an unnecessary and overcomplicated approach to content negotiation. + +This is a valid approach as the HTTP spec deliberately underspecifies how a server should weight server-based preferences against client-based preferences. + +--- + +# Custom content negotiation + +It's unlikely that you'll want to provide a custom content negotiation scheme for REST framework, but you can do so if needed. To implement a custom content negotiation scheme override `BaseContentNegotiation`. + +REST framework's content negotiation classes handle selection of both the appropriate parser for the request, and the appropriate renderer for the response, so you should implement both the `.select_parser(request, parsers)` and `.select_renderer(request, renderers, format_suffix)` methods. + +## Example + +The following is a custom content negotiation class which ignores the client +request when selecting the appropriate parser or renderer. + + class IgnoreClientContentNegotiation(BaseContentNegotiation): + def select_parser(self, request, parsers): + """ + Select the first parser in the `.parser_classes` list. + """ + return parsers[0] + + def select_renderer(self, request, renderers, format_suffix): + """ + Select the first renderer in the `.renderer_classes` list. + """ + return renderers[0] + +[accept-header]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html diff --git a/docs/api-guide/exceptions.md b/docs/api-guide/exceptions.md new file mode 100644 index 00000000..ba57fde8 --- /dev/null +++ b/docs/api-guide/exceptions.md @@ -0,0 +1,88 @@ +<a class="github" href="exceptions.py"></a> + +# Exceptions + +> Exceptions… allow error handling to be organized cleanly in a central or high-level place within the program structure. +> +> — Doug Hellmann, [Python Exception Handling Techniques][cite] + +## Exception handling in REST framework views + +REST framework's views handle various exceptions, and deal with returning appropriate error responses. + +The handled exceptions are: + +* Subclasses of `APIException` raised inside REST framework. +* Django's `Http404` exception. +* Django's `PermissionDenied` exception. + +In each case, REST framework will return a response with an appropriate status code and content-type. The body of the response will include any additional details regarding the nature of the error. + +By default all error responses will include a key `details` in the body of the response, but other keys may also be included. + +For example, the following request: + + DELETE http://api.example.com/foo/bar HTTP/1.1 + Accept: application/json + +Might receive an error response indicating that the `DELETE` method is not allowed on that resource: + + HTTP/1.1 405 Method Not Allowed + Content-Type: application/json; charset=utf-8 + Content-Length: 42 + + {"detail": "Method 'DELETE' not allowed."} + +--- + +# API Reference + +## APIException + +**Signature:** `APIException(detail=None)` + +The **base class** for all exceptions raised inside REST framework. + +To provide a custom exception, subclass `APIException` and set the `.status_code` and `.detail` properties on the class. + +## ParseError + +**Signature:** `ParseError(detail=None)` + +Raised if the request contains malformed data when accessing `request.DATA` or `request.FILES`. + +By default this exception results in a response with the HTTP status code "400 Bad Request". + +## PermissionDenied + +**Signature:** `PermissionDenied(detail=None)` + +Raised when an incoming request fails the permission checks. + +By default this exception results in a response with the HTTP status code "403 Forbidden". + +## MethodNotAllowed + +**Signature:** `MethodNotAllowed(method, detail=None)` + +Raised when an incoming request occurs that does not map to a handler method on the view. + +By default this exception results in a response with the HTTP status code "405 Method Not Allowed". + +## UnsupportedMediaType + +**Signature:** `UnsupportedMediaType(media_type, detail=None)` + +Raised if there are no parsers that can handle the content type of the request data when accessing `request.DATA` or `request.FILES`. + +By default this exception results in a response with the HTTP status code "415 Unsupported Media Type". + +## Throttled + +**Signature:** `Throttled(wait=None, detail=None)` + +Raised when an incoming request fails the throttling checks. + +By default this exception results in a response with the HTTP status code "429 Too Many Requests". + +[cite]: http://www.doughellmann.com/articles/how-tos/python-exception-handling/index.html diff --git a/docs/api-guide/fields.md b/docs/api-guide/fields.md new file mode 100644 index 00000000..8c3df067 --- /dev/null +++ b/docs/api-guide/fields.md @@ -0,0 +1,278 @@ +<a class="github" href="fields.py"></a> + +# Serializer fields + +> Flat is better than nested. +> +> — [The Zen of Python][cite] + +Serializer fields handle converting between primative values and internal datatypes. They also deal with validating input values, as well as retrieving and setting the values from their parent objects. + +--- + +**Note:** The serializer fields are declared in fields.py, but by convention you should import them using `from rest_framework import serializers` and refer to fields as `serializers.<FieldName>`. + +--- + +## Core arguments + +Each serializer field class constructor takes at least these arguments. Some Field classes take additional, field-specific arguments, but the following should always be accepted: + +### `source` + +The name of the attribute that will be used to populate the field. May be a method that only takes a `self` argument, such as `Field(source='get_absolute_url')`, or may use dotted notation to traverse attributes, such as `Field(source='user.email')`. + +The value `source='*'` has a special meaning, and is used to indicate that the entire object should be passed through to the field. This can be useful for creating nested representations. (See the implementation of the `PaginationSerializer` class for an example.) + +Defaults to the name of the field. + +### `read_only` + +Set this to `True` to ensure that the field is used when serializing a representation, but is not used when updating an instance dureing deserialization. + +Defaults to `False` + +### `required` + +Normally an error will be raised if a field is not supplied during deserialization. +Set to false if this field is not required to be present during deserialization. + +Defaults to `True`. + +### `default` + +If set, this gives the default value that will be used for the field if none is supplied. If not set the default behaviour is to not populate the attribute at all. + +### `validators` + +A list of Django validators that should be used to validate deserialized values. + +### `error_messages` + +A dictionary of error codes to error messages. + +### `widget` + +Used only if rendering the field to HTML. +This argument sets the widget that should be used to render the field. + + +--- + +# Generic Fields + +These generic fields are used for representing arbitrary model fields or the output of model methods. + +## Field + +A generic, **read-only** field. You can use this field for any attribute that does not need to support write operations. + +For example, using the following model. + + class Account(models.Model): + owner = models.ForeignKey('auth.user') + name = models.CharField(max_length=100) + created = models.DateTimeField(auto_now_add=True) + payment_expiry = models.DateTimeField() + + def has_expired(self): + now = datetime.datetime.now() + return now > self.payment_expiry + +A serializer definition that looked like this: + + class AccountSerializer(serializers.HyperlinkedModelSerializer): + expired = Field(source='has_expired') + + class Meta: + fields = ('url', 'owner', 'name', 'expired') + +Would produce output similar to: + + { + 'url': 'http://example.com/api/accounts/3/', + 'owner': 'http://example.com/api/users/12/', + 'name': 'FooCorp business account', + 'expired': True + } + +By default, the `Field` class will perform a basic translation of the source value into primative datatypes, falling back to unicode representations of complex datatypes when necessary. + +You can customize this behaviour by overriding the `.to_native(self, value)` method. + +## WritableField + +A field that supports both read and write operations. By itself `WriteableField` does not perform any translation of input values into a given type. You won't typically use this field directly, but you may want to override it and implement the `.to_native(self, value)` and `.from_native(self, value)` methods. + +## ModelField + +A generic field that can be tied to any arbitrary model field. The `ModelField` class delegates the task of serialization/deserialization to it's associated model field. This field can be used to create serializer fields for custom model fields, without having to create a new custom serializer field. + +**Signature:** `ModelField(model_field=<Django ModelField class>)` + +--- + +# Typed Fields + +These fields represent basic datatypes, and support both reading and writing values. + +## BooleanField + +A Boolean representation. + +Corresponds to `django.db.models.fields.BooleanField`. + +## CharField + +A text representation, optionally validates the text to be shorter than `max_length` and longer than `min_length`. + +Corresponds to `django.db.models.fields.CharField` +or `django.db.models.fields.TextField`. + +**Signature:** `CharField(max_length=None, min_length=None)` + +## ChoiceField + +A field that can accept a value out of a limited set of choices. + +## EmailField + +A text representation, validates the text to be a valid e-mail address. + +Corresponds to `django.db.models.fields.EmailField` + +## DateField + +A date representation. + +Corresponds to `django.db.models.fields.DateField` + +## DateTimeField + +A date and time representation. + +Corresponds to `django.db.models.fields.DateTimeField` + +## IntegerField + +An integer representation. + +Corresponds to `django.db.models.fields.IntegerField`, `django.db.models.fields.SmallIntegerField`, `django.db.models.fields.PositiveIntegerField` and `django.db.models.fields.PositiveSmallIntegerField` + +## FloatField + +A floating point representation. + +Corresponds to `django.db.models.fields.FloatField`. + +--- + +# Relational Fields + +Relational fields are used to represent model relationships. They can be applied to `ForeignKey`, `ManyToManyField` and `OneToOneField` relationships, as well as to reverse relationships, and custom relationships such as `GenericForeignKey`. + +## RelatedField + +This field can be applied to any of the following: + +* A `ForeignKey` field. +* A `OneToOneField` field. +* A reverse OneToOne relationship +* Any other "to-one" relationship. + +By default `RelatedField` will represent the target of the field using it's `__unicode__` method. + +You can customise this behaviour by subclassing `ManyRelatedField`, and overriding the `.to_native(self, value)` method. + +## ManyRelatedField + +This field can be applied to any of the following: + +* A `ManyToManyField` field. +* A reverse ManyToMany relationship. +* A reverse ForeignKey relationship +* Any other "to-many" relationship. + +By default `ManyRelatedField` will represent the targets of the field using their `__unicode__` method. + +For example, given the following models: + + class TaggedItem(models.Model): + """ + Tags arbitrary model instances using a generic relation. + + See: https://docs.djangoproject.com/en/dev/ref/contrib/contenttypes/ + """ + tag = models.SlugField() + content_type = models.ForeignKey(ContentType) + object_id = models.PositiveIntegerField() + content_object = GenericForeignKey('content_type', 'object_id') + + def __unicode__(self): + return self.tag + + + class Bookmark(models.Model): + """ + A bookmark consists of a URL, and 0 or more descriptive tags. + """ + url = models.URLField() + tags = GenericRelation(TaggedItem) + +And a model serializer defined like this: + + class BookmarkSerializer(serializers.ModelSerializer): + tags = serializers.ManyRelatedField(source='tags') + + class Meta: + model = Bookmark + exclude = ('id',) + +Then an example output format for a Bookmark instance would be: + + { + 'tags': [u'django', u'python'], + 'url': u'https://www.djangoproject.com/' + } + +## PrimaryKeyRelatedField + +This field can be applied to any "to-one" relationship, such as a `ForeignKey` field. + +`PrimaryKeyRelatedField` will represent the target of the field using it's primary key. + +Be default, `PrimaryKeyRelatedField` is read-write, although you can change this behaviour using the `read_only` flag. + +## ManyPrimaryKeyRelatedField + +This field can be applied to any "to-many" relationship, such as a `ManyToManyField` field, or a reverse `ForeignKey` relationship. + +`PrimaryKeyRelatedField` will represent the targets of the field using their primary key. + +Be default, `ManyPrimaryKeyRelatedField` is read-write, although you can change this behaviour using the `read_only` flag. + +## HyperlinkedRelatedField + +This field can be applied to any "to-one" relationship, such as a `ForeignKey` field. + +`HyperlinkedRelatedField` will represent the target of the field using a hyperlink. You must include a named URL pattern in your URL conf, with a name like `'{model-name}-detail'` that corresponds to the target of the hyperlink. + +Be default, `HyperlinkedRelatedField` is read-write, although you can change this behaviour using the `read_only` flag. + +## ManyHyperlinkedRelatedField + +This field can be applied to any "to-many" relationship, such as a `ManyToManyField` field, or a reverse `ForeignKey` relationship. + +`ManyHyperlinkedRelatedField` will represent the targets of the field using hyperlinks. You must include a named URL pattern in your URL conf, with a name like `'{model-name}-detail'` that corresponds to the target of the hyperlink. + +Be default, `ManyHyperlinkedRelatedField` is read-write, although you can change this behaviour using the `read_only` flag. + +## HyperLinkedIdentityField + +This field can be applied as an identity relationship, such as the `'url'` field on a HyperlinkedModelSerializer. + +You must include a named URL pattern in your URL conf, with a name like `'{model-name}-detail'` that corresponds to the model. + +This field is always read-only. + +[cite]: http://www.python.org/dev/peps/pep-0020/ diff --git a/docs/api-guide/format-suffixes.md b/docs/api-guide/format-suffixes.md new file mode 100644 index 00000000..6d5feba4 --- /dev/null +++ b/docs/api-guide/format-suffixes.md @@ -0,0 +1,61 @@ +<a class="github" href="urlpatterns.py"></a> + +# Format suffixes + +> Section 6.2.1 does not say that content negotiation should be +used all the time. +> +> — Roy Fielding, [REST discuss mailing list][cite] + +A common pattern for Web APIs is to use filename extensions on URLs to provide an endpoint for a given media type. For example, 'http://example.com/api/users.json' to serve a JSON representation. + +Adding format-suffix patterns to each individual entry in the URLconf for your API is error-prone and non-DRY, so REST framework provides a shortcut to adding these patterns to your URLConf. + +## format_suffix_patterns + +**Signature**: format_suffix_patterns(urlpatterns, suffix_required=False, allowed=None) + +Returns a URL pattern list which includes format suffix patterns appended to each of the URL patterns provided. + +Arguments: + +* **urlpatterns**: Required. A URL pattern list. +* **suffix_required**: Optional. A boolean indicating if suffixes in the URLs should be optional or mandatory. Defaults to `False`, meaning that suffixes are optional by default. +* **allowed**: Optional. A list or tuple of valid format suffixes. If not provided, a wildcard format suffix pattern will be used. + +Example: + + from rest_framework.urlpatterns import format_suffix_patterns + + urlpatterns = patterns('blog.views', + url(r'^/$', 'api_root'), + url(r'^comment/$', 'comment_root'), + url(r'^comment/(?P<pk>[0-9]+)/$', 'comment_instance') + ) + + urlpatterns = format_suffix_patterns(urlpatterns, allowed=['json', 'html']) + +When using `format_suffix_patterns`, you must make sure to add the `'format'` keyword argument to the corresponding views. For example. + + @api_view(('GET',)) + def api_root(request, format=None): + # do stuff... + +The name of the kwarg used may be modified by using the `FORMAT_SUFFIX_KWARG` setting. + +Also note that `format_suffix_patterns` does not support descending into `include` URL patterns. + +--- + +## Accept headers vs. format suffixes + +There seems to be a view among some of the Web community that filename extensions are not a RESTful pattern, and that `HTTP Accept` headers should always be used instead. + +It is actually a misconception. For example, take the following quote from Roy Fielding discussing the relative merits of query parameter media-type indicators vs. file extension media-type indicators: + +“That's why I always prefer extensions. Neither choice has anything to do with REST.” — Roy Fielding, [REST discuss mailing list][cite2] + +The quote does not mention Accept headers, but it does make it clear that format suffixes should be considered an acceptable pattern. + +[cite]: http://tech.groups.yahoo.com/group/rest-discuss/message/5857 +[cite2]: http://tech.groups.yahoo.com/group/rest-discuss/message/14844
\ No newline at end of file diff --git a/docs/api-guide/generic-views.md b/docs/api-guide/generic-views.md new file mode 100644 index 00000000..360ef1a2 --- /dev/null +++ b/docs/api-guide/generic-views.md @@ -0,0 +1,187 @@ +<a class="github" href="mixins.py"></a> +<a class="github" href="generics.py"></a> + +# Generic views + +> Django’s generic views... were developed as a shortcut for common usage patterns... They take certain common idioms and patterns found in view development and abstract them so that you can quickly write common views of data without having to repeat yourself. +> +> — [Django Documentation][cite] + +One of the key benefits of class based views is the way they allow you to compose bits of reusable behaviour. REST framework takes advantage of this by providing a number of pre-built views that provide for commonly used patterns. + +The generic views provided by REST framework allow you to quickly build API views that map closely to your database models. + +If the generic views don't suit the needs of your API, you can drop down to using the regular `APIView` class, or reuse the mixins and base classes used by the generic views to compose your own set of reusable generic views. + +## Examples + +Typically when using the generic views, you'll override the view, and set several class attributes. + + class UserList(generics.ListCreateAPIView): + model = User + serializer_class = UserSerializer + permission_classes = (IsAdminUser,) + paginate_by = 100 + +For more complex cases you might also want to override various methods on the view class. For example. + + class UserList(generics.ListCreateAPIView): + model = User + serializer_class = UserSerializer + permission_classes = (IsAdminUser,) + + def get_paginate_by(self, queryset): + """ + Use smaller pagination for HTML representations. + """ + page_size_param = self.request.QUERY_PARAMS.get('page_size') + if page_size_param: + return int(page_size_param) + return 100 + +For very simple cases you might want to pass through any class attributes using the `.as_view()` method. For example, your URLconf might include something the following entry. + + url(r'^/users/', ListCreateAPIView.as_view(model=User) name='user-list') + +--- + +# API Reference + +The following classes are the concrete generic views. If you're using generic views this is normally the level you'll be working at unless you need heavily customized behavior. + +## CreateAPIView + +Used for **create-only** endpoints. + +Provides `post` method handlers. + +Extends: [GenericAPIView], [CreateModelMixin] + +## ListAPIView + +Used for **read-only** endpoints to represent a **collection of model instances**. + +Provides a `get` method handler. + +Extends: [MultipleObjectAPIView], [ListModelMixin] + +## RetrieveAPIView + +Used for **read-only** endpoints to represent a **single model instance**. + +Provides a `get` method handler. + +Extends: [SingleObjectAPIView], [RetrieveModelMixin] + +## DestroyAPIView + +Used for **delete-only** endpoints for a **single model instance**. + +Provides a `delete` method handler. + +Extends: [SingleObjectAPIView], [DestroyModelMixin] + +## UpdateAPIView + +Used for **update-only** endpoints for a **single model instance**. + +Provides a `put` method handler. + +Extends: [SingleObjectAPIView], [UpdateModelMixin] + +## ListCreateAPIView + +Used for **read-write** endpoints to represent a **collection of model instances**. + +Provides `get` and `post` method handlers. + +Extends: [MultipleObjectAPIView], [ListModelMixin], [CreateModelMixin] + +## RetrieveDestroyAPIView + +Used for **read or delete** endpoints to represent a **single model instance**. + +Provides `get` and `delete` method handlers. + +Extends: [SingleObjectAPIView], [RetrieveModelMixin], [DestroyModelMixin] + +## RetrieveUpdateDestroyAPIView + +Used for **read-write-delete** endpoints to represent a **single model instance**. + +Provides `get`, `put` and `delete` method handlers. + +Extends: [SingleObjectAPIView], [RetrieveModelMixin], [UpdateModelMixin], [DestroyModelMixin] + +--- + +# Base views + +Each of the generic views provided is built by combining one of the base views below, with one or more mixin classes. + +## GenericAPIView + +Extends REST framework's `APIView` class, adding support for serialization of model instances and model querysets. + +## MultipleObjectAPIView + +Provides a base view for acting on a single object, by combining REST framework's `APIView`, and Django's [MultipleObjectMixin]. + +**See also:** ccbv.co.uk documentation for [MultipleObjectMixin][multiple-object-mixin-classy]. + +## SingleObjectAPIView + +Provides a base view for acting on a single object, by combining REST framework's `APIView`, and Django's [SingleObjectMixin]. + +**See also:** ccbv.co.uk documentation for [SingleObjectMixin][single-object-mixin-classy]. + +--- + +# Mixins + +The mixin classes provide the actions that are used to provide the basic view behaviour. Note that the mixin classes provide action methods rather than defining the handler methods such as `.get()` and `.post()` directly. This allows for more flexible composition of behaviour. + +## ListModelMixin + +Provides a `.list(request, *args, **kwargs)` method, that implements listing a queryset. + +Should be mixed in with [MultipleObjectAPIView]. + +## CreateModelMixin + +Provides a `.create(request, *args, **kwargs)` method, that implements creating and saving a new model instance. + +Should be mixed in with any [GenericAPIView]. + +## RetrieveModelMixin + +Provides a `.retrieve(request, *args, **kwargs)` method, that implements returning an existing model instance in a response. + +Should be mixed in with [SingleObjectAPIView]. + +## UpdateModelMixin + +Provides a `.update(request, *args, **kwargs)` method, that implements updating and saving an existing model instance. + +Should be mixed in with [SingleObjectAPIView]. + +## DestroyModelMixin + +Provides a `.destroy(request, *args, **kwargs)` method, that implements deletion of an existing model instance. + +Should be mixed in with [SingleObjectAPIView]. + +[cite]: https://docs.djangoproject.com/en/dev/ref/class-based-views/#base-vs-generic-views +[MultipleObjectMixin]: https://docs.djangoproject.com/en/dev/ref/class-based-views/mixins-multiple-object/ +[SingleObjectMixin]: https://docs.djangoproject.com/en/dev/ref/class-based-views/mixins-single-object/ +[multiple-object-mixin-classy]: http://ccbv.co.uk/projects/Django/1.4/django.views.generic.list/MultipleObjectMixin/ +[single-object-mixin-classy]: http://ccbv.co.uk/projects/Django/1.4/django.views.generic.detail/SingleObjectMixin/ + +[GenericAPIView]: #genericapiview +[SingleObjectAPIView]: #singleobjectapiview +[MultipleObjectAPIView]: #multipleobjectapiview +[ListModelMixin]: #listmodelmixin +[CreateModelMixin]: #createmodelmixin +[RetrieveModelMixin]: #retrievemodelmixin +[UpdateModelMixin]: #updatemodelmixin +[DestroyModelMixin]: #destroymodelmixin
\ No newline at end of file diff --git a/docs/api-guide/pagination.md b/docs/api-guide/pagination.md new file mode 100644 index 00000000..597baba4 --- /dev/null +++ b/docs/api-guide/pagination.md @@ -0,0 +1,125 @@ +<a class="github" href="pagination.py"></a> + +# Pagination + +> Django provides a few classes that help you manage paginated data – that is, data that’s split across several pages, with “Previous/Next” links. +> +> — [Django documentation][cite] + +REST framework includes a `PaginationSerializer` class that makes it easy to return paginated data in a way that can then be rendered to arbitrary media types. + +## Paginating basic data + +Let's start by taking a look at an example from the Django documentation. + + from django.core.paginator import Paginator + objects = ['john', 'paul', 'george', 'ringo'] + paginator = Paginator(objects, 2) + page = paginator.page(1) + page.object_list + # ['john', 'paul'] + +At this point we've got a page object. If we wanted to return this page object as a JSON response, we'd need to provide the client with context such as next and previous links, so that it would be able to page through the remaining results. + + from rest_framework.pagination import PaginationSerializer + serializer = PaginationSerializer(instance=page) + serializer.data + # {'count': 4, 'next': '?page=2', 'previous': None, 'results': [u'john', u'paul']} + +The `context` argument of the `PaginationSerializer` class may optionally include the request. If the request is included in the context then the next and previous links returned by the serializer will use absolute URLs instead of relative URLs. + + request = RequestFactory().get('/foobar') + serializer = PaginationSerializer(instance=page, context={'request': request}) + serializer.data + # {'count': 4, 'next': 'http://testserver/foobar?page=2', 'previous': None, 'results': [u'john', u'paul']} + +We could now return that data in a `Response` object, and it would be rendered into the correct media type. + +## Paginating QuerySets + +Our first example worked because we were using primative objects. If we wanted to paginate a queryset or other complex data, we'd need to specify a serializer to use to serialize the result set itself with. + +We can do this using the `object_serializer_class` attribute on the inner `Meta` class of the pagination serializer. For example. + + class UserSerializer(serializers.ModelSerializer): + """ + Serializes user querysets. + """ + class Meta: + model = User + fields = ('username', 'email') + + class PaginatedUserSerializer(pagination.PaginationSerializer): + """ + Serializes page objects of user querysets. + """ + class Meta: + object_serializer_class = UserSerializer + +We could now use our pagination serializer in a view like this. + + @api_view('GET') + def user_list(request): + queryset = User.objects.all() + paginator = Paginator(queryset, 20) + + page = request.QUERY_PARAMS.get('page') + try: + users = paginator.page(page) + except PageNotAnInteger: + # If page is not an integer, deliver first page. + users = paginator.page(1) + except EmptyPage: + # If page is out of range (e.g. 9999), deliver last page of results. + users = paginator.page(paginator.num_pages) + + serializer_context = {'request': request} + serializer = PaginatedUserSerializer(instance=users, + context=serializer_context) + return Response(serializer.data) + +## Pagination in the generic views + +The generic class based views `ListAPIView` and `ListCreateAPIView` provide pagination of the returned querysets by default. You can customise this behaviour by altering the pagination style, by modifying the default number of results, or by turning pagination off completely. + +The default pagination style may be set globally, using the `PAGINATION_SERIALIZER` and `PAGINATE_BY` settings. For example. + + REST_FRAMEWORK = { + 'PAGINATION_SERIALIZER': ( + 'example_app.pagination.CustomPaginationSerializer', + ), + 'PAGINATE_BY': 10 + } + +You can also set the pagination style on a per-view basis, using the `ListAPIView` generic class-based view. + + class PaginatedListView(ListAPIView): + model = ExampleModel + pagination_serializer_class = CustomPaginationSerializer + paginate_by = 10 + +For more complex requirements such as serialization that differs depending on the requested media type you can override the `.get_paginate_by()` and `.get_pagination_serializer_class()` methods. + +--- + +# Custom pagination serializers + +To create a custom pagination serializer class you should override `pagination.BasePaginationSerializer` and set the fields that you want the serializer to return. + +You can also override the name used for the object list field, by setting the `results_field` attribute, which defaults to `'results'`. + +## Example + +For example, to nest a pair of links labelled 'prev' and 'next', and set the name for the results field to 'objects', you might use something like this. + + class LinksSerializer(serializers.Serializer): + next = pagination.NextURLField(source='*') + prev = pagination.PreviousURLField(source='*') + + class CustomPaginationSerializer(pagination.BasePaginationSerializer): + links = LinksSerializer(source='*') # Takes the page object as the source + total_results = serializers.Field(source='paginator.count') + + results_field = 'objects' + +[cite]: https://docs.djangoproject.com/en/dev/topics/pagination/ diff --git a/docs/api-guide/parsers.md b/docs/api-guide/parsers.md new file mode 100644 index 00000000..59f00f99 --- /dev/null +++ b/docs/api-guide/parsers.md @@ -0,0 +1,161 @@ +<a class="github" href="parsers.py"></a> + +# Parsers + +> Machine interacting web services tend to use more +structured formats for sending data than form-encoded, since they're +sending more complex data than simple forms +> +> — Malcom Tredinnick, [Django developers group][cite] + +REST framework includes a number of built in Parser classes, that allow you to accept requests with various media types. There is also support for defining your own custom parsers, which gives you the flexibility to design the media types that your API accepts. + +## How the parser is determined + +The set of valid parsers for a view is always defined as a list of classes. When either `request.DATA` or `request.FILES` is accessed, REST framework will examine the `Content-Type` header on the incoming request, and determine which parser to use to parse the request content. + +## Setting the parsers + +The default set of parsers may be set globally, using the `DEFAULT_PARSER_CLASSES` setting. For example, the following settings would allow requests with `YAML` content. + + REST_FRAMEWORK = { + 'DEFAULT_PARSER_CLASSES': ( + 'rest_framework.parsers.YAMLParser', + ) + } + +You can also set the renderers used for an individual view, using the `APIView` class based views. + + class ExampleView(APIView): + """ + A view that can accept POST requests with YAML content. + """ + parser_classes = (YAMLParser,) + + def post(self, request, format=None): + return Response({'received data': request.DATA}) + +Or, if you're using the `@api_view` decorator with function based views. + + @api_view(['POST']) + @parser_classes((YAMLParser,)) + def example_view(request, format=None): + """ + A view that can accept POST requests with YAML content. + """ + return Response({'received data': request.DATA}) + +--- + +# API Reference + +## JSONParser + +Parses `JSON` request content. + +**.media_type**: `application/json` + +## YAMLParser + +Parses `YAML` request content. + +**.media_type**: `application/yaml` + +## XMLParser + +Parses REST framework's default style of `XML` request content. + +Note that the `XML` markup language is typically used as the base language for more strictly defined domain-specific languages, such as `RSS`, `Atom`, and `XHTML`. + +If you are considering using `XML` for your API, you may want to consider implementing a custom renderer and parser for your specific requirements, and using an existing domain-specific media-type, or creating your own custom XML-based media-type. + +**.media_type**: `application/xml` + +## FormParser + +Parses HTML form content. `request.DATA` will be populated with a `QueryDict` of data, `request.FILES` will be populated with an empty `QueryDict` of data. + +You will typically want to use both `FormParser` and `MultiPartParser` together in order to fully support HTML form data. + +**.media_type**: `application/x-www-form-urlencoded` + +## MultiPartParser + +Parses multipart HTML form content, which supports file uploads. Both `request.DATA` and `request.FILES` will be populated with a `QueryDict`. + +You will typically want to use both `FormParser` and `MultiPartParser` together in order to fully support HTML form data. + +**.media_type**: `multipart/form-data` + +--- + +# Custom parsers + +To implement a custom parser, you should override `BaseParser`, set the `.media_type` property, and implement the `.parse(self, stream, media_type, parser_context)` method. + +The method should return the data that will be used to populate the `request.DATA` property. + +The arguments passed to `.parse()` are: + +### stream + +A stream-like object representing the body of the request. + +### media_type + +Optional. If provided, this is the media type of the incoming request content. + +Depending on the request's `Content-Type:` header, this may be more specific than the renderer's `media_type` attribute, and may include media type parameters. For example `"text/plain; charset=utf-8"`. + +### parser_context + +Optional. If supplied, this argument will be a dictionary containing any additional context that may be required to parse the request content. + +By default this will include the following keys: `view`, `request`, `args`, `kwargs`. + +## Example + +The following is an example plaintext parser that will populate the `request.DATA` property with a string representing the body of the request. + + class PlainTextParser(BaseParser): + """ + Plain text parser. + """ + + media_type = 'text/plain' + + def parse(self, stream, media_type=None, parser_context=None): + """ + Simply return a string representing the body of the request. + """ + return stream.read() + +## Uploading file content + +If your custom parser needs to support file uploads, you may return a `DataAndFiles` object from the `.parse()` method. `DataAndFiles` should be instantiated with two arguments. The first argument will be used to populate the `request.DATA` property, and the second argument will be used to populate the `request.FILES` property. + +For example: + + class SimpleFileUploadParser(BaseParser): + """ + A naive raw file upload parser. + """ + + def parse(self, stream, media_type=None, parser_context=None): + content = stream.read() + name = 'example.dat' + content_type = 'application/octet-stream' + size = len(content) + charset = 'utf-8' + + # Write a temporary file based on the request content + temp = tempfile.NamedTemporaryFile(delete=False) + temp.write(content) + uploaded = UploadedFile(temp, name, content_type, size, charset) + + # Return the uploaded file + data = {} + files = {name: uploaded} + return DataAndFiles(data, files) + +[cite]: https://groups.google.com/d/topic/django-developers/dxI4qVzrBY4/discussion diff --git a/docs/api-guide/permissions.md b/docs/api-guide/permissions.md new file mode 100644 index 00000000..1a746fb6 --- /dev/null +++ b/docs/api-guide/permissions.md @@ -0,0 +1,118 @@ +<a class="github" href="permissions.py"></a> + +# Permissions + +> Authentication or identification by itself is not usually sufficient to gain access to information or code. For that, the entity requesting access must have authorization. +> +> — [Apple Developer Documentation][cite] + +Together with [authentication] and [throttling], permissions determine whether a request should be granted or denied access. + +Permission checks are always run at the very start of the view, before any other code is allowed to proceed. Permission checks will typically use the authentication information in the `request.user` and `request.auth` properties to determine if the incoming request should be permitted. + +## How permissions are determined + +Permissions in REST framework are always defined as a list of permission classes. + +Before running the main body of the view each permission in the list is checked. +If any permission check fails an `exceptions.PermissionDenied` exception will be raised, and the main body of the view will not run. + +## Object level permissions + +REST framework permissions also support object-level permissioning. Object level permissions are used to determine if a user should be allowed to act on a particular object, which will typically be a model instance. + +Object level permissions are run by REST framework's generic views when `.get_object()` is called. As with view level permissions, an `exceptions.PermissionDenied` exception will be raised if the user is not allowed to act on the given object. + +## Setting the permission policy + +The default permission policy may be set globally, using the `DEFAULT_PERMISSION_CLASSES` setting. For example. + + REST_FRAMEWORK = { + 'DEFAULT_PERMISSION_CLASSES': ( + 'rest_framework.permissions.IsAuthenticated', + ) + } + +If not specified, this setting defaults to allowing unrestricted access: + + 'DEFAULT_PERMISSION_CLASSES': ( + 'rest_framework.permissions.AllowAny', + ) + +You can also set the authentication policy on a per-view basis, using the `APIView` class based views. + + class ExampleView(APIView): + permission_classes = (IsAuthenticated,) + + def get(self, request, format=None): + content = { + 'status': 'request was permitted' + } + return Response(content) + +Or, if you're using the `@api_view` decorator with function based views. + + @api_view('GET') + @permission_classes(IsAuthenticated) + def example_view(request, format=None): + content = { + 'status': 'request was permitted' + } + return Response(content) + +--- + +# API Reference + +## AllowAny + +The `AllowAny` permission class will allow unrestricted access, **regardless of if the request was authenticated or unauthenticated**. + +This permission is not strictly required, since you can achieve the same result by using an empty list or tuple for the permissions setting, but you may find it useful to specify this class because it makes the intention explicit. + +## IsAuthenticated + +The `IsAuthenticated` permission class will deny permission to any unauthenticated user, and allow permission otherwise. + +This permission is suitable if you want your API to only be accessible to registered users. + +## IsAdminUser + +The `IsAdminUser` permission class will deny permission to any user, unless `user.is_staff` is `True` in which case permission will be allowed. + +This permission is suitable is you want your API to only be accessible to a subset of trusted administrators. + +## IsAuthenticatedOrReadOnly + +The `IsAuthenticatedOrReadOnly` will allow authenticated users to perform any request. Requests for unauthorised users will only be permitted if the request method is one of the "safe" methods; `GET`, `HEAD` or `OPTIONS`. + +This permission is suitable if you want to your API to allow read permissions to anonymous users, and only allow write permissions to authenticated users. + +## DjangoModelPermissions + +This permission class ties into Django's standard `django.contrib.auth` [model permissions][contribauth]. When applied to a view that has a `.model` property, authorization will only be granted if the user has the relevant model permissions assigned. + +* `POST` requests require the user to have the `add` permission on the model. +* `PUT` and `PATCH` requests require the user to have the `change` permission on the model. +* `DELETE` requests require the user to have the `delete` permission on the model. + +The default behaviour can also be overridden to support custom model permissions. For example, you might want to include a `view` model permission for `GET` requests. + +To use custom model permissions, override `DjangoModelPermissions` and set the `.perms_map` property. Refer to the source code for details. + +The `DjangoModelPermissions` class also supports object-level permissions. Third-party authorization backends such as [django-guardian][guardian] that provide object-level permissions should work just fine with `DjangoModelPermissions` without any custom configuration required. + +--- + +# Custom permissions + +To implement a custom permission, override `BasePermission` and implement the `.has_permission(self, request, view, obj=None)` method. + +The method should return `True` if the request should be granted access, and `False` otherwise. + + +[cite]: https://developer.apple.com/library/mac/#documentation/security/Conceptual/AuthenticationAndAuthorizationGuide/Authorization/Authorization.html +[authentication]: authentication.md +[throttling]: throttling.md +[contribauth]: https://docs.djangoproject.com/en/1.0/topics/auth/#permissions +[guardian]: https://github.com/lukaszb/django-guardian diff --git a/docs/api-guide/renderers.md b/docs/api-guide/renderers.md new file mode 100644 index 00000000..c3d12ddb --- /dev/null +++ b/docs/api-guide/renderers.md @@ -0,0 +1,267 @@ +<a class="github" href="renderers.py"></a> + +# Renderers + +> Before a TemplateResponse instance can be returned to the client, it must be rendered. The rendering process takes the intermediate representation of template and context, and turns it into the final byte stream that can be served to the client. +> +> — [Django documentation][cite] + +REST framework includes a number of built in Renderer classes, that allow you to return responses with various media types. There is also support for defining your own custom renderers, which gives you the flexibility to design your own media types. + +## How the renderer is determined + +The set of valid renderers for a view is always defined as a list of classes. When a view is entered REST framework will perform content negotiation on the incoming request, and determine the most appropriate renderer to satisfy the request. + +The basic process of content negotiation involves examining the request's `Accept` header, to determine which media types it expects in the response. Optionally, format suffixes on the URL may be used to explicitly request a particular representation. For example the URL `http://example.com/api/users_count.json` might be an endpoint that always returns JSON data. + +For more information see the documentation on [content negotation][conneg]. + +## Setting the renderers + +The default set of renderers may be set globally, using the `DEFAULT_RENDERER_CLASSES` setting. For example, the following settings would use `YAML` as the main media type and also include the self describing API. + + REST_FRAMEWORK = { + 'DEFAULT_RENDERER_CLASSES': ( + 'rest_framework.renderers.YAMLRenderer', + 'rest_framework.renderers.BrowsableAPIRenderer', + ) + } + +You can also set the renderers used for an individual view, using the `APIView` class based views. + + class UserCountView(APIView): + """ + A view that returns the count of active users, in JSON or JSONp. + """ + renderer_classes = (JSONRenderer, JSONPRenderer) + + def get(self, request, format=None): + user_count = User.objects.filter(active=True).count() + content = {'user_count': user_count} + return Response(content) + +Or, if you're using the `@api_view` decorator with function based views. + + @api_view(['GET']) + @renderer_classes((JSONRenderer, JSONPRenderer)) + def user_count_view(request, format=None): + """ + A view that returns the count of active users, in JSON or JSONp. + """ + user_count = User.objects.filter(active=True).count() + content = {'user_count': user_count} + return Response(content) + +## Ordering of renderer classes + +It's important when specifying the renderer classes for your API to think about what priority you want to assign to each media type. If a client underspecifies the representations it can accept, such as sending an `Accept: */*` header, or not including an `Accept` header at all, then REST framework will select the first renderer in the list to use for the response. + +For example if your API serves JSON responses and the HTML browseable API, you might want to make `JSONRenderer` your default renderer, in order to send `JSON` responses to clients that do not specify an `Accept` header. + +If your API includes views that can serve both regular webpages and API responses depending on the request, then you might consider making `TemplateHTMLRenderer` your default renderer, in order to play nicely with older browsers that send [broken accept headers][browser-accept-headers]. + +--- + +# API Reference + +## JSONRenderer + +Renders the request data into `JSON`. + +The client may additionally include an `'indent'` media type parameter, in which case the returned `JSON` will be indented. For example `Accept: application/json; indent=4`. + +**.media_type**: `application/json` + +**.format**: `'.json'` + +## JSONPRenderer + +Renders the request data into `JSONP`. The `JSONP` media type provides a mechanism of allowing cross-domain AJAX requests, by wrapping a `JSON` response in a javascript callback. + +The javascript callback function must be set by the client including a `callback` URL query parameter. For example `http://example.com/api/users?callback=jsonpCallback`. If the callback function is not explicitly set by the client it will default to `'callback'`. + +**Note**: If you require cross-domain AJAX requests, you may also want to consider using [CORS] as an alternative to `JSONP`. + +**.media_type**: `application/javascript` + +**.format**: `'.jsonp'` + +## YAMLRenderer + +Renders the request data into `YAML`. + +**.media_type**: `application/yaml` + +**.format**: `'.yaml'` + +## XMLRenderer + +Renders REST framework's default style of `XML` response content. + +Note that the `XML` markup language is used typically used as the base language for more strictly defined domain-specific languages, such as `RSS`, `Atom`, and `XHTML`. + +If you are considering using `XML` for your API, you may want to consider implementing a custom renderer and parser for your specific requirements, and using an existing domain-specific media-type, or creating your own custom XML-based media-type. + +**.media_type**: `application/xml` + +**.format**: `'.xml'` + +## TemplateHTMLRenderer + +Renders data to HTML, using Django's standard template rendering. +Unlike other renderers, the data passed to the `Response` does not need to be serialized. Also, unlike other renderers, you may want to include a `template_name` argument when creating the `Response`. + +The TemplateHTMLRenderer will create a `RequestContext`, using the `response.data` as the context dict, and determine a template name to use to render the context. + +The template name is determined by (in order of preference): + +1. An explicit `.template_name` attribute set on the response. +2. An explicit `.template_name` attribute set on this class. +3. The return result of calling `view.get_template_names()`. + +An example of a view that uses `TemplateHTMLRenderer`: + + class UserInstance(generics.RetrieveUserAPIView): + """ + A view that returns a templated HTML representations of a given user. + """ + model = Users + renderer_classes = (TemplateHTMLRenderer,) + + def get(self, request, *args, **kwargs) + self.object = self.get_object() + return Response({'user': self.object}, template_name='user_detail.html') + +You can use `TemplateHTMLRenderer` either to return regular HTML pages using REST framework, or to return both HTML and API responses from a single endpoint. + +If you're building websites that use `TemplateHTMLRenderer` along with other renderer classes, you should consider listing `TemplateHTMLRenderer` as the first class in the `renderer_classes` list, so that it will be prioritised first even for browsers that send poorly formed `ACCEPT:` headers. + +**.media_type**: `text/html` + +**.format**: `'.html'` + +See also: `StaticHTMLRenderer` + +## StaticHTMLRenderer + +A simple renderer that simply returns pre-rendered HTML. Unlike other renderers, the data passed to the response object should be a string representing the content to be returned. + +An example of a view that uses `TemplateHTMLRenderer`: + + @api_view(('GET',)) + @renderer_classes((StaticHTMLRenderer,)) + def simple_html_view(request): + data = '<html><body><h1>Hello, world</h1></body></html>' + return Response(data) + +You can use `TemplateHTMLRenderer` either to return regular HTML pages using REST framework, or to return both HTML and API responses from a single endpoint. + +**.media_type**: `text/html` + +**.format**: `'.html'` + +See also: `TemplateHTMLRenderer` + +## BrowsableAPIRenderer + +Renders data into HTML for the Browseable API. This renderer will determine which other renderer would have been given highest priority, and use that to display an API style response within the HTML page. + +**.media_type**: `text/html` + +**.format**: `'.api'` + +--- + +# Custom renderers + +To implement a custom renderer, you should override `BaseRenderer`, set the `.media_type` and `.format` properties, and implement the `.render(self, data, media_type=None, renderer_context=None)` method. + +The arguments passed to the `.render()` method are: + +### `data` + +The request data, as set by the `Response()` instantiation. + +### `media_type=None` + +Optional. If provided, this is the accepted media type, as determined by the content negotiation stage. + +Depending on the client's `Accept:` header, this may be more specific than the renderer's `media_type` attribute, and may include media type parameters. For example `"application/json; nested=true"`. + +### `renderer_context=None` + +Optional. If provided, this is a dictionary of contextual information provided by the view. + +By default this will include the following keys: `view`, `request`, `response`, `args`, `kwargs`. + +## Example + +The following is an example plaintext renderer that will return a response with the `data` parameter as the content of the response. + + from django.utils.encoding import smart_unicode + from rest_framework import renderers + + + class PlainText(renderers.BaseRenderer): + media_type = 'text/plain' + format = 'txt' + + def render(self, data, media_type=None, renderer_context=None): + if isinstance(data, basestring): + return data + return smart_unicode(data) + +--- + +# Advanced renderer usage + +You can do some pretty flexible things using REST framework's renderers. Some examples... + +* Provide either flat or nested representations from the same endpoint, depending on the requested media type. +* Serve both regular HTML webpages, and JSON based API responses from the same endpoints. +* Specify multiple types of HTML representation for API clients to use. +* Underspecify a renderer's media type, such as using `media_type = 'image/*'`, and use the `Accept` header to vary the encoding of the response. + +## Varying behaviour by media type + +In some cases you might want your view to use different serialization styles depending on the accepted media type. If you need to do this you can access `request.accepted_renderer` to determine the negotiated renderer that will be used for the response. + +For example: + + @api_view(('GET',)) + @renderer_classes((TemplateHTMLRenderer, JSONRenderer)) + def list_users(request): + """ + A view that can return JSON or HTML representations + of the users in the system. + """ + queryset = Users.objects.filter(active=True) + + if request.accepted_renderer.format == 'html': + # TemplateHTMLRenderer takes a context dict, + # and additionally requires a 'template_name'. + # It does not require serialization. + data = {'users': queryset} + return Response(data, template_name='list_users.html') + + # JSONRenderer requires serialized data as normal. + serializer = UserSerializer(instance=queryset) + data = serializer.data + return Response(data) + +## Designing your media types + +For the purposes of many Web APIs, simple `JSON` responses with hyperlinked relations may be sufficient. If you want to fully embrace RESTful design and [HATEOAS] you'll need to consider the design and usage of your media types in more detail. + +In [the words of Roy Fielding][quote], "A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types.". + +For good examples of custom media types, see GitHub's use of a custom [application/vnd.github+json] media type, and Mike Amundsen's IANA approved [application/vnd.collection+json] JSON-based hypermedia. + +[cite]: https://docs.djangoproject.com/en/dev/ref/template-response/#the-rendering-process +[conneg]: content-negotiation.md +[browser-accept-headers]: http://www.gethifi.com/blog/browser-rest-http-accept-headers +[CORS]: http://en.wikipedia.org/wiki/Cross-origin_resource_sharing +[HATEOAS]: http://timelessrepo.com/haters-gonna-hateoas +[quote]: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven +[application/vnd.github+json]: http://developer.github.com/v3/media/ +[application/vnd.collection+json]: http://www.amundsen.com/media-types/collection/ diff --git a/docs/api-guide/requests.md b/docs/api-guide/requests.md new file mode 100644 index 00000000..72932f5d --- /dev/null +++ b/docs/api-guide/requests.md @@ -0,0 +1,128 @@ +<a class="github" href="request.py"></a> + +# Requests + +> If you're doing REST-based web service stuff ... you should ignore request.POST. +> +> — Malcom Tredinnick, [Django developers group][cite] + +REST framework's `Request` class extends the standard `HttpRequest`, adding support for REST framework's flexible request parsing and request authentication. + +--- + +# Request parsing + +REST framework's Request objects provide flexible request parsing that allows you to treat requests with JSON data or other media types in the same way that you would normally deal with form data. + +## .DATA + +`request.DATA` returns the parsed content of the request body. This is similar to the standard `request.POST` attribute except that: + +* It supports parsing the content of HTTP methods other than `POST`, meaning that you can access the content of `PUT` and `PATCH` requests. +* It supports REST framework's flexible request parsing, rather than just supporting form data. For example you can handle incoming JSON data in the same way that you handle incoming form data. + +For more details see the [parsers documentation]. + +## .FILES + +`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 is used for `request.DATA`. + +For more details see the [parsers documentation]. + +## .QUERY_PARAMS + +`request.QUERY_PARAMS` is a more correctly named synonym for `request.GET`. + +For clarity inside your code, we recommend using `request.QUERY_PARAMS` instead of the usual `request.GET`, as *any* HTTP method type may include query parameters. + +## .parsers + +The `APIView` class or `@api_view` decorator will ensure that this property is automatically set to a list of `Parser` instances, based on the `parser_classes` set on the view or based on the `DEFAULT_PARSER_CLASSES` setting. + +You won't typically need to access this property. + +--- + +**Note:** If a client sends malformed content, then accessing `request.DATA` or `request.FILES` may raise a `ParseError`. By default REST framework's `APIView` class or `@api_view` decorator will catch the error and return a `400 Bad Request` response. + +If a client sends a request with a content-type that cannot be parsed then a `UnsupportedMediaType` exception will be raised, which by default will be caught and return a `415 Unsupported Media Type` response. + +--- + +# Authentication + +REST framework provides flexible, per-request authentication, that gives you the ability to: + +* Use different authentication policies for different parts of your API. +* Support the use of multiple authentication policies. +* Provide both user and token information associated with the incoming request. + +## .user + +`request.user` typically returns an instance of `django.contrib.auth.models.User`, although the behavior depends on the authentication policy being used. + +If the request is unauthenticated the default value of `request.user` is an instance of `django.contrib.auth.models.AnonymousUser`. + +For more details see the [authentication documentation]. + +## .auth + +`request.auth` returns any additional authentication context. The exact behavior of `request.auth` depends on the authentication policy being used, but it may typically be an instance of the token that the request was authenticated against. + +If the request is unauthenticated, or if no additional context is present, the default value of `request.auth` is `None`. + +For more details see the [authentication documentation]. + +## .authenticators + +The `APIView` class or `@api_view` decorator will ensure that this property is automatically set to a list of `Authentication` instances, based on the `authentication_classes` set on the view or based on the `DEFAULT_AUTHENTICATORS` setting. + +You won't typically need to access this property. + +--- + +# Browser enhancements + +REST framework supports a few browser enhancements such as browser-based `PUT` and `DELETE` forms. + +## .method + +`request.method` returns the **uppercased** string representation of the request's HTTP method. + +Browser-based `PUT` and `DELETE` forms are transparently supported. + +For more information see the [browser enhancements documentation]. + +## .content_type + +`request.content_type`, returns a string object representing the media type of the HTTP request's body, or an empty string if no media type was provided. + +You won't typically need to directly access the request's content type, as you'll normally rely on REST framework's default request parsing behavior. + +If you do need to access the content type of the request you should use the `.content_type` property in preference to using `request.META.get('HTTP_CONTENT_TYPE')`, as it provides transparent support for browser-based non-form content. + +For more information see the [browser enhancements documentation]. + +## .stream + +`request.stream` returns a stream representing the content of the request body. + +You won't typically need to directly access the request's content, as you'll normally rely on REST framework's default request parsing behavior. + +If you do need to access the raw content directly, you should use the `.stream` property in preference to using `request.content`, as it provides transparent support for browser-based non-form content. + +For more information see the [browser enhancements documentation]. + +--- + +# Standard HttpRequest attributes + +As REST framework's `Request` extends Django's `HttpRequest`, all the other standard attributes and methods are also available. For example the `request.META` dictionary is available as normal. + +Note that due to implementation reasons the `Request` class does not inherit from `HttpRequest` class, but instead extends the class using composition. + + +[cite]: https://groups.google.com/d/topic/django-developers/dxI4qVzrBY4/discussion +[parsers documentation]: parsers.md +[authentication documentation]: authentication.md +[browser enhancements documentation]: ../topics/browser-enhancements.md diff --git a/docs/api-guide/responses.md b/docs/api-guide/responses.md new file mode 100644 index 00000000..794f9377 --- /dev/null +++ b/docs/api-guide/responses.md @@ -0,0 +1,94 @@ +<a class="github" href="response.py"></a> + +# Responses + +> 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. +> +> — [Django documentation][cite] + +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 `SimpleTemplateResponse`. `Response` objects are initialised with data, 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 provides a nicer interface for returning Web API responses. + +Unless you want to heavily customize REST framework for some reason, you should always use an `APIView` class or `@api_view` function for views that return `Response` objects. Doing so ensures that the view can perform content negotiation and select the appropriate renderer for the response, before it is returned from the view. + +--- + +# Creating responses + +## Response() + +**Signature:** `Response(data, status=None, template_name=None, headers=None)` + +Unlike regular `HttpResponse` objects, you do not instantiate `Response` objects with rendered content. Instead you pass in unrendered data, which may consist of any python primatives. + +The renderers used by the `Response` class cannot natively handle complex datatypes such as Django model instances, so you need to serialize the data into primative datatypes before creating the `Response` object. + +You can use REST framework's `Serializer` classes to perform this data serialization, or use your own custom serialization. + +Arguments: + +* `data`: The serialized data for the response. +* `status`: A status code for the response. Defaults to 200. See also [status codes][statuscodes]. +* `template_name`: A template name to use if `HTMLRenderer` is selected. +* `headers`: A dictionary of HTTP headers to use in the response. + +--- + +# Attributes + +## .data + +The unrendered content of a `Request` object. + +## .status_code + +The numeric status code of the HTTP response. + +## .content + +The rendered content of the response. The `.render()` method must have been called before `.content` can be accessed. + +## .template_name + +The `template_name`, if supplied. Only required if `HTMLRenderer` or some other custom template renderer is the accepted renderer for the reponse. + +## .accepted_renderer + +The renderer instance that will be used to render the response. + +Set automatically by the `APIView` or `@api_view` immediately before the response is returned from the view. + +## .accepted_media_type + +The media type that was selected by the content negotiation stage. + +Set automatically by the `APIView` or `@api_view` immediately before the response is returned from the view. + +## .renderer_context + +A dictionary of additional context information that will be passed to the renderer's `.render()` method. + +Set automatically by the `APIView` or `@api_view` immediately before the response is returned from the view. + +--- + +# Standard HttpResponse attributes + +The `Response` class extends `SimpleTemplateResponse`, and all the usual attributes and methods are also available on the response. For example you can set headers on the response in the standard way: + + response = Response() + response['Cache-Control'] = 'no-cache' + +## .render() + +**Signature:** `.render()` + +As with any other `TemplateResponse`, this method is called to render the serialized data of the response into the final response content. When `.render()` is called, the response content will be set to the result of calling the `.render(data, accepted_media_type, renderer_context)` method on the `accepted_renderer` instance. + +You won't typically need to call `.render()` yourself, as it's handled by Django's standard response cycle. + +[cite]: https://docs.djangoproject.com/en/dev/ref/template-response/ +[statuscodes]: status-codes.md diff --git a/docs/api-guide/reverse.md b/docs/api-guide/reverse.md new file mode 100644 index 00000000..19930dc3 --- /dev/null +++ b/docs/api-guide/reverse.md @@ -0,0 +1,55 @@ +<a class="github" href="reverse.py"></a> + +# Returning URLs + +> 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][cite] + +As a rule, it's probably better practice to return absolute URIs from your Web APIs, such as `http://example.com/foobar`, rather than returning relative URIs, such as `/foobar`. + +The advantages of doing so are: + +* It's more explicit. +* It leaves less work for your API clients. +* There's no ambiguity about the meaning of the string when it's found in representations such as JSON that do not have a native URI type. +* It makes it easy to do things like markup HTML representations with hyperlinks. + +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. + +## reverse + +**Signature:** `reverse(viewname, *args, **kwargs)` + +Has the same behavior as [`django.core.urlresolvers.reverse`][reverse], except that it returns a fully qualified URL, using the request to determine the host and port. + +You should **include the request as a keyword argument** to the function, for example: + + import datetime + from rest_framework.reverse import reverse + from rest_framework.views import APIView + + class APIRootView(APIView): + def get(self, request): + year = datetime.datetime.now().year + data = { + ... + 'year-summary-url': reverse('year-summary', args=[year], request=request) + } + return Response(data) + +## reverse_lazy + +**Signature:** `reverse_lazy(viewname, *args, **kwargs)` + +Has the same behavior as [`django.core.urlresolvers.reverse_lazy`][reverse-lazy], except that it returns a fully qualified URL, using the request to determine the host and port. + +As with the `reverse` function, you should **include the request as a keyword argument** to the function, for example: + + api_root = reverse_lazy('api-root', request=request) + +[cite]: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_5 +[reverse]: https://docs.djangoproject.com/en/dev/topics/http/urls/#reverse +[reverse-lazy]: https://docs.djangoproject.com/en/dev/topics/http/urls/#reverse-lazy diff --git a/docs/api-guide/serializers.md b/docs/api-guide/serializers.md new file mode 100644 index 00000000..c88b9b0c --- /dev/null +++ b/docs/api-guide/serializers.md @@ -0,0 +1,276 @@ +<a class="github" href="serializers.py"></a> + +# Serializers + +> 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][cite] + +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. + +## Declaring Serializers + +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. + +## Serializing objects + +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"}' + +## Deserializing objects + +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) + +## Validation + +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. + +### Field-level validation + +You can specify custom field-level validation by adding `validate_<fieldname>()` methods to your `Serializer` subclass. These are analagous to `clean_<fieldname>` methods on Django forms, but accept slightly different arguments. They take a dictionary of deserialized attributes as a first argument, and the field name in that dictionary as a second argument (which will be either the name of the field or the value of the `source` argument to the field, if one was provided). Your `validate_<fieldname>` methods should either just return the attrs dictionary or raise a `ValidationError`. For example: + + from rest_framework import serializers + + class BlogPostSerializer(serializers.Serializer): + title = serializers.CharField(max_length=100) + content = serializers.CharField() + + def validate_title(self, attrs, source): + """ + Check that the blog post is about Django + """ + value = attrs[source] + if "Django" not in value: + raise serializers.ValidationError("Blog post is not about Django") + return attrs + +### Final cross-field validation + +To do any other validation that requires access to multiple fields, add a method called `validate` to your `Serializer` subclass. This method takes a single argument, which is the `attrs` dictionary. It should raise a `ValidationError` if necessary, or just return `attrs`. + +## Dealing with nested objects + +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.Field() + username = serializers.Field() + + class CommentSerializer(serializers.Serializer): + user = UserSerializer() + title = serializers.Field() + content = serializers.Field() + created = serializers.Field() + +--- + +**Note**: Nested serializers are only suitable for read-only representations, as there are cases where they would have ambiguous or non-obvious behavior if used when updating instances. For read-write representations you should always use a flat representation, by using one of the `RelatedField` subclasses. + +--- + + +## Creating custom fields + +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(serializers.WritableField): + """ + 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(serializers.WritableField): + 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 + +--- + +# ModelSerializers + +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(serializers.ModelSerializer): + class Meta: + model = Account + +**[TODO: Explain model field to serializer field mapping in more detail]** + +## Specifying fields explicitly + +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(serializers.ModelSerializer): + url = CharField(source='get_absolute_url', read_only=True) + group = NaturalKeyField() + + class Meta: + model = Account + +Extra fields can correspond to any property or callable on the model. + +## Relational fields + +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 `PrimaryKeyRelatedField` and `HyperlinkedRelatedField` 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 representation 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. + +## Specifying which fields should be included + +If you only want a subset of the default fields to be used in a model serializer, you can do so using `fields` or `exclude` options, just as you would with a `ModelForm`. + +For example: + + class AccountSerializer(serializers.ModelSerializer): + class Meta: + model = Account + exclude = ('id',) + +## Specifiying nested serialization + +The default `ModelSerializer` uses primary keys for relationships, but you can also easily generate nested representations using the `depth` option: + + class AccountSerializer(serializers.ModelSerializer): + class Meta: + model = Account + exclude = ('id',) + depth = 1 + +The `depth` option should be set to an integer value that indicates the depth of relationships that should be traversed before reverting to a flat representation. + +## Customising the default fields + +You can create customized subclasses of `ModelSerializer` that use a different set of default fields for the representation, by overriding various `get_<field_type>_field` methods. + +Each of these methods may either return a field or serializer instance, or `None`. + +### get_pk_field + +**Signature**: `.get_pk_field(self, model_field)` + +Returns the field instance that should be used to represent the pk field. + +### get_nested_field + +**Signature**: `.get_nested_field(self, model_field)` + +Returns the field instance that should be used to represent a related field when `depth` is specified as being non-zero. + +### get_related_field + +**Signature**: `.get_related_field(self, model_field, to_many=False)` + +Returns the field instance that should be used to represent a related field when `depth` is not specified, or when nested representations are being used and the depth reaches zero. + +### get_field + +**Signature**: `.get_field(self, model_field)` + +Returns the field instance that should be used for non-relational, non-pk fields. + +### Example: + +The following custom model serializer could be used as a base class for model serializers that should always exclude the pk by default. + + class NoPKModelSerializer(serializers.ModelSerializer): + def get_pk_field(self, model_field): + return None + + + +[cite]: https://groups.google.com/d/topic/django-users/sVFaOfQi4wY/discussion diff --git a/docs/api-guide/settings.md b/docs/api-guide/settings.md new file mode 100644 index 00000000..a3668e2a --- /dev/null +++ b/docs/api-guide/settings.md @@ -0,0 +1,153 @@ +<a class="github" href="settings.py"></a> + +# Settings + +> Namespaces are one honking great idea - let's do more of those! +> +> — [The Zen of Python][cite] + +Configuration for REST framework is all namespaced inside a single Django setting, named `REST_FRAMEWORK`. + +For example your project's `settings.py` file might include something like this: + + REST_FRAMEWORK = { + 'DEFAULT_RENDERER_CLASSES': ( + 'rest_framework.renderers.YAMLRenderer', + ) + 'DEFAULT_PARSER_CLASSES': ( + 'rest_framework.parsers.YAMLParser', + ) + } + +## Accessing settings + +If you need to access the values of REST framework's API settings in your project, +you should use the `api_settings` object. For example. + + from rest_framework.settings import api_settings + + print api_settings.DEFAULT_AUTHENTICATION_CLASSES + +The `api_settings` object will check for any user-defined settings, and otherwise fallback to the default values. Any setting that uses string import paths to refer to a class will automatically import and return the referenced class, instead of the string literal. + +--- + +# API Reference + +## DEFAULT_RENDERER_CLASSES + +A list or tuple of renderer classes, that determines the default set of renderers that may be used when returning a `Response` object. + +Default: + + ( + 'rest_framework.renderers.JSONRenderer', + 'rest_framework.renderers.BrowsableAPIRenderer', + 'rest_framework.renderers.TemplateHTMLRenderer' + ) + +## DEFAULT_PARSER_CLASSES + +A list or tuple of parser classes, that determines the default set of parsers used when accessing the `request.DATA` property. + +Default: + + ( + 'rest_framework.parsers.JSONParser', + 'rest_framework.parsers.FormParser' + ) + +## DEFAULT_AUTHENTICATION_CLASSES + +A list or tuple of authentication classes, that determines the default set of authenticators used when accessing the `request.user` or `request.auth` properties. + +Default: + + ( + 'rest_framework.authentication.SessionAuthentication', + 'rest_framework.authentication.UserBasicAuthentication' + ) + +## DEFAULT_PERMISSION_CLASSES + +A list or tuple of permission classes, that determines the default set of permissions checked at the start of a view. + +Default: + + ( + 'rest_framework.permissions.AllowAny', + ) + +## DEFAULT_THROTTLE_CLASSES + +A list or tuple of throttle classes, that determines the default set of throttles checked at the start of a view. + +Default: `()` + +## DEFAULT_MODEL_SERIALIZER_CLASS + +**TODO** + +Default: `rest_framework.serializers.ModelSerializer` + +## DEFAULT_PAGINATION_SERIALIZER_CLASS + +**TODO** + +Default: `rest_framework.pagination.PaginationSerializer` + +## FORMAT_SUFFIX_KWARG + +**TODO** + +Default: `'format'` + +## UNAUTHENTICATED_USER + +The class that should be used to initialize `request.user` for unauthenticated requests. + +Default: `django.contrib.auth.models.AnonymousUser` + +## UNAUTHENTICATED_TOKEN + +The class that should be used to initialize `request.auth` for unauthenticated requests. + +Default: `None` + +## FORM_METHOD_OVERRIDE + +The name of a form field that may be used to override the HTTP method of the form. + +If the value of this setting is `None` then form method overloading will be disabled. + +Default: `'_method'` + +## FORM_CONTENT_OVERRIDE + +The name of a form field that may be used to override the content of the form payload. Must be used together with `FORM_CONTENTTYPE_OVERRIDE`. + +If either setting is `None` then form content overloading will be disabled. + +Default: `'_content'` + +## FORM_CONTENTTYPE_OVERRIDE + +The name of a form field that may be used to override the content type of the form payload. Must be used together with `FORM_CONTENT_OVERRIDE`. + +If either setting is `None` then form content overloading will be disabled. + +Default: `'_content_type'` + +## URL_ACCEPT_OVERRIDE + +The name of a URL parameter that may be used to override the HTTP `Accept` header. + +If the value of this setting is `None` then URL accept overloading will be disabled. + +Default: `'accept'` + +## URL_FORMAT_OVERRIDE + +Default: `'format'` + +[cite]: http://www.python.org/dev/peps/pep-0020/ diff --git a/docs/api-guide/status-codes.md b/docs/api-guide/status-codes.md new file mode 100644 index 00000000..401f45ce --- /dev/null +++ b/docs/api-guide/status-codes.md @@ -0,0 +1,95 @@ +<a class="github" href="status.py"></a> + +# Status Codes + +> 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][rfc2324], 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 rest_framework 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][rfc2616] +and [RFC 6585][rfc6585]. + +## Informational - 1xx + +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 + +## Successful - 2xx + +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 + +## Redirection - 3xx + +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 + +## Client Error - 4xx + +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 + +## Server Error - 5xx + +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 + + +[rfc2324]: http://www.ietf.org/rfc/rfc2324.txt +[rfc2616]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html +[rfc6585]: http://tools.ietf.org/html/rfc6585 diff --git a/docs/api-guide/throttling.md b/docs/api-guide/throttling.md new file mode 100644 index 00000000..bfda7079 --- /dev/null +++ b/docs/api-guide/throttling.md @@ -0,0 +1,157 @@ +<a class="github" href="throttling.py"></a> + +# Throttling + +> HTTP/1.1 420 Enhance Your Calm +> +> [Twitter API rate limiting response][cite] + +[cite]: https://dev.twitter.com/docs/error-codes-responses + +Throttling is similar to [permissions], in that it determines if a request should be authorized. Throttles indicate a temporary state, and are used to control the rate of requests that clients can make to an API. + +As with permissions, multiple throttles may be used. Your API might have a restrictive throttle for unauthenticated requests, and a less restrictive throttle for authenticated requests. + +Another scenario where you might want to use multiple throttles would be if you need to impose different constraints on different parts of the API, due to some services being particularly resource-intensive. + +Multiple throttles can also be used if you want to impose both burst throttling rates, and sustained throttling rates. For example, you might want to limit a user to a maximum of 60 requests per minute, and 1000 requests per day. + +Throttles do not necessarily only refer to rate-limiting requests. For example a storage service might also need to throttle against bandwidth, and a paid data service might want to throttle against a certain number of a records being accessed. + +## How throttling is determined + +As with permissions and authentication, throttling in REST framework is always defined as a list of classes. + +Before running the main body of the view each throttle in the list is checked. +If any throttle check fails an `exceptions.Throttled` exception will be raised, and the main body of the view will not run. + +## Setting the throttling policy + +The default throttling policy may be set globally, using the `DEFAULT_THROTTLE_CLASSES` and `DEFAULT_THROTTLE_RATES` settings. For example. + + REST_FRAMEWORK = { + 'DEFAULT_THROTTLE_CLASSES': ( + 'rest_framework.throttles.AnonThrottle', + 'rest_framework.throttles.UserThrottle' + ), + 'DEFAULT_THROTTLE_RATES': { + 'anon': '100/day', + 'user': '1000/day' + } + } + +The rate descriptions used in `DEFAULT_THROTTLE_RATES` may include `second`, `minute`, `hour` or `day` as the throttle period. + +You can also set the throttling policy on a per-view basis, using the `APIView` class based views. + + class ExampleView(APIView): + throttle_classes = (UserThrottle,) + + def get(self, request, format=None): + content = { + 'status': 'request was permitted' + } + return Response(content) + +Or, if you're using the `@api_view` decorator with function based views. + + @api_view('GET') + @throttle_classes(UserThrottle) + def example_view(request, format=None): + content = { + 'status': 'request was permitted' + } + return Response(content) + +--- + +# API Reference + +## AnonRateThrottle + +The `AnonThrottle` will only ever throttle unauthenticated users. The IP address of the incoming request is used to generate a unique key to throttle against. + +The allowed request rate is determined from one of the following (in order of preference). + +* The `rate` property on the class, which may be provided by overriding `AnonThrottle` and setting the property. +* The `DEFAULT_THROTTLE_RATES['anon']` setting. + +`AnonThrottle` is suitable if you want to restrict the rate of requests from unknown sources. + +## UserRateThrottle + +The `UserThrottle` will throttle users to a given rate of requests across the API. The user id is used to generate a unique key to throttle against. Unauthenticated requests will fall back to using the IP address of the incoming request to generate a unique key to throttle against. + +The allowed request rate is determined from one of the following (in order of preference). + +* The `rate` property on the class, which may be provided by overriding `UserThrottle` and setting the property. +* The `DEFAULT_THROTTLE_RATES['user']` setting. + +An API may have multiple `UserRateThrottles` in place at the same time. To do so, override `UserRateThrottle` and set a unique "scope" for each class. + +For example, multiple user throttle rates could be implemented by using the following classes... + + class BurstRateThrottle(UserRateThrottle): + scope = 'burst' + + class SustainedRateThrottle(UserRateThrottle): + scope = 'sustained' + +...and the following settings. + + REST_FRAMEWORK = { + 'DEFAULT_THROTTLE_CLASSES': ( + 'example.throttles.BurstRateThrottle', + 'example.throttles.SustainedRateThrottle' + ), + 'DEFAULT_THROTTLE_RATES': { + 'burst': '60/min', + 'sustained': '1000/day' + } + } + +`UserThrottle` is suitable if you want simple global rate restrictions per-user. + +## ScopedRateThrottle + +The `ScopedThrottle` class can be used to restrict access to specific parts of the API. This throttle will only be applied if the view that is being accessed includes a `.throttle_scope` property. The unique throttle key will then be formed by concatenating the "scope" of the request with the unique user id or IP address. + +The allowed request rate is determined by the `DEFAULT_THROTTLE_RATES` setting using a key from the request "scope". + +For example, given the following views... + + class ContactListView(APIView): + throttle_scope = 'contacts' + ... + + class ContactDetailView(ApiView): + throttle_scope = 'contacts' + ... + + class UploadView(APIView): + throttle_scope = 'uploads' + ... + +...and the following settings. + + REST_FRAMEWORK = { + 'DEFAULT_THROTTLE_CLASSES': ( + 'rest_framework.throttles.ScopedRateThrottle' + ), + 'DEFAULT_THROTTLE_RATES': { + 'contacts': '1000/day', + 'uploads': '20/day' + } + } + +User requests to either `ContactListView` or `ContactDetailView` would be restricted to a total of 1000 requests per-day. User requests to `UploadView` would be restricted to 20 requests per day. + +--- + +# Custom throttles + +To create a custom throttle, override `BaseThrottle` and implement `.allow_request(request, view)`. The method should return `True` if the request should be allowed, and `False` otherwise. + +Optionally you may also override the `.wait()` method. If implemented, `.wait()` should return a recommended number of seconds to wait before attempting the next request, or `None`. The `.wait()` method will only be called if `.allow_request()` has previously returned `False`. + +[permissions]: permissions.md diff --git a/docs/api-guide/views.md b/docs/api-guide/views.md new file mode 100644 index 00000000..5b072827 --- /dev/null +++ b/docs/api-guide/views.md @@ -0,0 +1,168 @@ +<a class="github" href="decorators.py"></a> <a class="github" href="views.py"></a> + +# Class Based Views + +> Django's class based views are a welcome departure from the old-style views. +> +> — [Reinout van Rees][cite] + +REST framework provides an `APIView` class, which subclasses Django's `View` class. + +`APIView` classes are different from regular `View` classes in the following ways: + +* Requests passed to the handler methods will be REST framework's `Request` instances, not Django's `HttpRequest` instances. +* Handler methods may return REST framework's `Response`, instead of Django's `HttpResponse`. The view will manage content negotiation and setting the correct renderer on the response. +* Any `APIException` exceptions will be caught and mediated into appropriate responses. +* Incoming requests will be authenticated and appropriate permission and/or throttle checks will be run before dispatching the request to the handler method. + +Using the `APIView` class is pretty much the same as using a regular `View` class, as usual, the incoming request is dispatched to an appropriate handler method such as `.get()` or `.post()`. Additionally, a number of attributes may be set on the class that control various aspects of the API policy. + +For example: + + class ListUsers(APIView): + """ + View to list all users in the system. + + * Requires token authentication. + * Only admin users are able to access this view. + """ + authentication_classes = (authentication.TokenAuthentication,) + permission_classes = (permissions.IsAdminUser,) + + def get(self, request, format=None): + """ + Return a list of all users. + """ + usernames = [user.username for user in User.objects.all()] + return Response(usernames) + +## API policy attributes + +The following attributes control the pluggable aspects of API views. + +### .renderer_classes + +### .parser_classes + +### .authentication_classes + +### .throttle_classes + +### .permission_classes + +### .content_negotiation_class + +## API policy instantiation methods + +The following methods are used by REST framework to instantiate the various pluggable API policies. You won't typically need to override these methods. + +### .get_renderers(self) + +### .get_parsers(self) + +### .get_authenticators(self) + +### .get_throttles(self) + +### .get_permissions(self) + +### .get_content_negotiator(self) + +## API policy implementation methods + +The following methods are called before dispatching to the handler method. + +### .check_permissions(...) + +### .check_throttles(...) + +### .perform_content_negotiation(...) + +## Dispatch methods + +The following methods are called directly by the view's `.dispatch()` method. +These perform any actions that need to occur before or after calling the handler methods such as `.get()`, `.post()`, `put()` and `.delete()`. + +### .initial(self, request, \*args, **kwargs) + +Performs any actions that need to occur before the handler method gets called. +This method is used to enforce permissions and throttling, and perform content negotiation. + +You won't typically need to override this method. + +### .handle_exception(self, exc) + +Any exception thrown by the handler method will be passed to this method, which either returns a `Response` instance, or re-raises the exception. + +The default implementation handles any subclass of `rest_framework.exceptions.APIException`, as well as Django's `Http404` and `PermissionDenied` exceptions, and returns an appropriate error response. + +If you need to customize the error responses your API returns you should subclass this method. + +### .initialize_request(self, request, \*args, **kwargs) + +Ensures that the request object that is passed to the handler method is an instance of `Request`, rather than the usual Django `HttpRequest`. + +You won't typically need to override this method. + +### .finalize_response(self, request, response, \*args, **kwargs) + +Ensures that any `Response` object returned from the handler method will be rendered into the correct content type, as determined by the content negotation. + +You won't typically need to override this method. + +--- + +# Function Based Views + +> Saying [that Class based views] is always the superior solution is a mistake. +> +> — [Nick Coghlan][cite2] + +REST framework also allows you to work with regular function based views. It provides a set of simple decorators that wrap your function based views to ensure they receive an instance of `Request` (rather than the usual Django `HttpRequest`) and allows them to return a `Response` (instead of a Django `HttpResponse`), and allow you to configure how the request is processed. + +## @api_view() + +**Signature:** `@api_view(http_method_names)` + +The core of this functionality is the `api_view` decorator, which takes a list of HTTP methods that your view should respond to. For example, this is how you would write a very simple view that just manually returns some data: + + from rest_framework.decorators import api_view + + @api_view(['GET']) + def hello_world(request): + return Response({"message": "Hello, world!"}) + + +This view will use the default renderers, parsers, authentication classes etc specified in the [settings](settings). + +## API policy decorators + +To override the default settings, REST framework provides a set of additional decorators which can be added to your views. These must come *after* (below) the `@api_view` decorator. For example, to create a view that uses a [throttle](throttling) to ensure it can only be called once per day by a particular user, use the `@throttle_classes` decorator, passing a list of throttle classes: + + from rest_framework.decorators import api_view, throttle_classes + from rest_framework.throttling import UserRateThrottle + + class OncePerDayUserThrottle(UserRateThrottle): + rate = '1/day' + + @api_view(['GET']) + @throttle_classes([OncePerDayUserThrottle]) + def view(request): + return Response({"message": "Hello for today! See you tomorrow!"}) + +These decorators correspond to the attributes set on `APIView` subclasses, described above. + +The available decorators are: + +* `@renderer_classes(...)` +* `@parser_classes(...)` +* `@authentication_classes(...)` +* `@throttle_classes(...)` +* `@permission_classes(...)` + +Each of these decorators takes a single argument which must be a list or tuple of classes. + +[cite]: http://reinout.vanrees.org/weblog/2011/08/24/class-based-views-usage.html +[cite2]: http://www.boredomandlaziness.org/2012/05/djangos-cbvs-are-not-mistake-but.html +[settings]: api-guide/settings.md +[throttling]: api-guide/throttling.md |