diff --git a/Django b/Django
new file mode 100644
index 000000000..e69de29bb
diff --git a/docs/api-guide/authentication.md b/docs/api-guide/authentication.md
index f24c6a81b..c69953607 100644
--- a/docs/api-guide/authentication.md
+++ b/docs/api-guide/authentication.md
@@ -39,6 +39,7 @@ You can also set the authentication policy on a per-view basis, using the `APIVi
class ExampleView(APIView):
authentication_classes = (SessionAuthentication, UserBasicAuthentication)
+ permission_classes = (IsAuthenticated,)
def get(self, request, format=None):
content = {
@@ -49,10 +50,9 @@ You can also set the authentication policy on a per-view basis, using the `APIVi
Or, if you're using the `@api_view` decorator with function based views.
- @api_view(
- allowed=('GET',),
- authentication_classes=(SessionAuthentication, UserBasicAuthentication)
- )
+ @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.
diff --git a/docs/api-guide/generic-views.md b/docs/api-guide/generic-views.md
index 202875a4a..88f245c7a 100644
--- a/docs/api-guide/generic-views.md
+++ b/docs/api-guide/generic-views.md
@@ -7,4 +7,92 @@
>
> — [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.
+
+## Example
+
+...
+
+---
+
+# API Reference
+
+## ListAPIView
+
+Used for read-write endpoints to represent a collection of model instances.
+
+Provides a `get` method handler.
+
+## ListCreateAPIView
+
+Used for read-write endpoints to represent a collection of model instances.
+
+Provides `get` and `post` method handlers.
+
+## RetrieveAPIView
+
+Used for read-only endpoints to represent a single model instance.
+
+Provides a `get` method handler.
+
+## RetrieveUpdateDestroyAPIView
+
+Used for read-write endpoints to represent a single model instance.
+
+Provides `get`, `put` and `delete` method handlers.
+
+---
+
+# Base views
+
+## BaseAPIView
+
+Extends REST framework's `APIView` class, adding support for serialization of model instances and model querysets.
+
+## MultipleObjectBaseAPIView
+
+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].
+
+## SingleObjectBaseAPIView
+
+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
+
+## ListModelMixin
+
+Provides a `.list(request, *args, **kwargs)` method, that implements listing a queryset.
+
+## CreateModelMixin
+
+Provides a `.create(request, *args, **kwargs)` method, that implements creating and saving a new model instance.
+
+## RetrieveModelMixin
+
+Provides a `.retrieve(request, *args, **kwargs)` method, that implements returning an existing model instance in a response.
+
+## UpdateModelMixin
+
+Provides a `.update(request, *args, **kwargs)` method, that implements updating and saving an existing model instance.
+
+## DestroyModelMixin
+
+Provides a `.destroy(request, *args, **kwargs)` method, that implements deletion of an existing model instance.
+
+## MetadataMixin
+
+Provides a `.metadata(request, *args, **kwargs)` method, that returns a response containing metadata about the view.
+
[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/
diff --git a/docs/api-guide/pagination.md b/docs/api-guide/pagination.md
new file mode 100644
index 000000000..50be59bf9
--- /dev/null
+++ b/docs/api-guide/pagination.md
@@ -0,0 +1,121 @@
+
+
+# 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.
+
+## Creating 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'`.
+
+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/renderers.md b/docs/api-guide/renderers.md
index d644599e5..134c37491 100644
--- a/docs/api-guide/renderers.md
+++ b/docs/api-guide/renderers.md
@@ -6,18 +6,146 @@
>
> — [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 flexiblity 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_RENDERERS` setting. For example, the following settings would use `YAML` as the main media type and also include the self describing API.
+
+ REST_FRAMEWORK = {
+ 'DEFAULT_RENDERERS': (
+ 'rest_framework.renderers.YAMLRenderer',
+ 'rest_framework.renderers.DocumentingHTMLRenderer',
+ )
+ }
+
+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].
+
## JSONRenderer
+**.media_type:** `application/json`
+
+**.format:** `'.json'`
+
## JSONPRenderer
+**.media_type:** `application/javascript`
+
+**.format:** `'.jsonp'`
+
## YAMLRenderer
+**.media_type:** `application/yaml`
+
+**.format:** `'.yaml'`
+
## XMLRenderer
+**.media_type:** `application/xml`
+
+**.format:** `'.xml'`
+
## DocumentingHTMLRenderer
-## TemplatedHTMLRenderer
+**.media_type:** `text/html`
+
+**.format:** `'.api'`
+
+## TemplateHTMLRenderer
+
+**.media_type:** `text/html`
+
+**.format:** `'.html'`
## Custom renderers
-[cite]: https://docs.djangoproject.com/en/dev/ref/template-response/#the-rendering-process
\ No newline at end of file
+To implement a custom renderer, you should override `BaseRenderer`, set the `.media_type` and `.format` properties, and implement the `.render(self, data, media_type)` method.
+
+## 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.
+
+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))
+ @template_name('list_users.html')
+ 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 does not require serialization.
+ data = {'users': queryset}
+ else:
+ # 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 neeed 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
+[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/
\ No newline at end of file
diff --git a/docs/api-guide/responses.md b/docs/api-guide/responses.md
index 6c279f171..e9ebcf819 100644
--- a/docs/api-guide/responses.md
+++ b/docs/api-guide/responses.md
@@ -8,18 +8,30 @@
REST framework supports HTTP content negotiation by providing a `Response` class which allows you to return content that can be rendered into multiple content types, depending on the client request.
-The `Response` class subclasses Django's `TemplateResponse`. `Response` objects are initialised with content, which should consist of native python primatives. REST framework then uses standard HTTP content negotiation to determine how it should render the final response content.
+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 does provide a better interface for returning Web API responses.
+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.
-## Response(content, headers=None, renderers=None, view=None, format=None, status=None)
+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.
+## Response(data, status=None, headers=None)
-## .renderers
+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.
-## .view
+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.
-## .format
+You can use REST framework's `Serializer` classes to perform this data serialization, or use your own custom serialization.
+## .data
+
+The unrendered content of a `Request` object can be accessed using the `.data` attribute.
+
+## .content
+
+To access the rendered content of a `Response` object, you must first call `.render()`. You'll typically only need to do this in cases such as unit testing responses - when you return a `Response` from a view Django's response cycle will handle calling `.render()` for you.
+
+## .renderer
+
+When you return a `Response` instance, the `APIView` class or `@api_view` decorator will select the appropriate renderer, and set the `.renderer` attribute on the `Response`, before returning it from the view.
[cite]: https://docs.djangoproject.com/en/dev/ref/template-response/
\ No newline at end of file
diff --git a/docs/api-guide/reverse.md b/docs/api-guide/reverse.md
index 3fa654c09..8485087e4 100644
--- a/docs/api-guide/reverse.md
+++ b/docs/api-guide/reverse.md
@@ -19,22 +19,28 @@ REST framework provides two utility functions to make it more simple to return a
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(viewname, request, *args, **kwargs)
+## reverse
+
+**Signature:** `reverse(viewname, request, *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.
+ import datetime
from rest_framework.utils import reverse
from rest_framework.views import APIView
- class MyView(APIView):
+ class APIRootView(APIView):
def get(self, request):
- content = {
+ year = datetime.datetime.now().year
+ data = {
...
- 'url': reverse('year-summary', request, args=[1945])
+ 'year-summary-url': reverse('year-summary', request, args=[year])
}
- return Response(content)
+ return Response(data)
-## reverse_lazy(viewname, request, *args, **kwargs)
+## reverse_lazy
+
+**Signature:** `reverse_lazy(viewname, request, *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.
diff --git a/docs/api-guide/serializers.md b/docs/api-guide/serializers.md
index 38a1e560e..4ddc6e0af 100644
--- a/docs/api-guide/serializers.md
+++ b/docs/api-guide/serializers.md
@@ -230,6 +230,9 @@ The `nested` option may also be set by passing it to the `serialize()` method.
class Meta:
model = Account
+ def get_pk_field(self, model_field):
+ return Field(readonly=True)
+
def get_nested_field(self, model_field):
return ModelSerializer()
diff --git a/docs/api-guide/settings.md b/docs/api-guide/settings.md
index 0f66e85ec..43be0d474 100644
--- a/docs/api-guide/settings.md
+++ b/docs/api-guide/settings.md
@@ -136,6 +136,10 @@ The name of a URL parameter that may be used to override the HTTP `Accept` heade
If the value of this setting is `None` then URL accept overloading will be disabled.
-Default: `'_accept'`
+Default: `'accept'`
+
+## URL_FORMAT_OVERRIDE
+
+Default: `'format'`
[cite]: http://www.python.org/dev/peps/pep-0020/
diff --git a/docs/api-guide/views.md b/docs/api-guide/views.md
index e7f12b45e..a615026f3 100644
--- a/docs/api-guide/views.md
+++ b/docs/api-guide/views.md
@@ -1,6 +1,6 @@
-# Views
+# Class Based Views
> Django's class based views are a welcome departure from the old-style views.
>
@@ -110,4 +110,17 @@ Ensures that any `Response` object returned from the handler method will be rend
You won't typically need to override this method.
-[cite]: http://reinout.vanrees.org/weblog/2011/08/24/class-based-views-usage.html
\ No newline at end of file
+---
+
+# Function Based Views
+
+> Saying [that Class based views] is always the superior solution is a mistake.
+>
+> — [Nick Coghlan][cite2]
+
+REST framework also gives you to work with regular function based views...
+
+**[TODO]**
+
+[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
\ No newline at end of file
diff --git a/docs/index.md b/docs/index.md
index 6e4d6257a..e301f77ad 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -85,6 +85,7 @@ The API guide is your complete reference manual to all the functionality provide
* [Authentication][authentication]
* [Permissions][permissions]
* [Throttling][throttling]
+* [Pagination][pagination]
* [Content negotiation][contentnegotiation]
* [Format suffixes][formatsuffixes]
* [Returning URLs][reverse]
@@ -162,6 +163,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
[authentication]: api-guide/authentication.md
[permissions]: api-guide/permissions.md
[throttling]: api-guide/throttling.md
+[pagination]: api-guide/pagination.md
[contentnegotiation]: api-guide/content-negotiation.md
[formatsuffixes]: api-guide/format-suffixes.md
[reverse]: api-guide/reverse.md
diff --git a/docs/static/css/default.css b/docs/static/css/default.css
index 213a700ed..49aac3a30 100644
--- a/docs/static/css/default.css
+++ b/docs/static/css/default.css
@@ -36,14 +36,14 @@ pre {
}
/* GitHub 'Star' badge */
-body.index #main-content iframe {
+body.index-page #main-content iframe {
float: right;
margin-top: -12px;
margin-right: -15px;
}
/* Travis CI badge */
-body.index #main-content p:first-of-type {
+body.index-page #main-content p:first-of-type {
float: right;
margin-right: 8px;
margin-top: -14px;
diff --git a/docs/template.html b/docs/template.html
index 4ac94f404..fbd30159a 100644
--- a/docs/template.html
+++ b/docs/template.html
@@ -16,7 +16,7 @@
-
+