Merge branch 'restframework2' of https://github.com/tomchristie/django-rest-framework into restframework2

This commit is contained in:
Tom Christie 2012-10-02 19:54:24 +01:00
commit e1518de68f
26 changed files with 754 additions and 78 deletions

0
Django Normal file
View File

View File

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

View File

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

View File

@ -0,0 +1,121 @@
<a class="github" href="pagination.py"></a>
# Pagination
> Django provides a few classes that help you manage paginated data that is, data thats split across several pages, with “Previous/Next” links.
>
> &mdash; [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/

View File

@ -6,18 +6,146 @@
>
> &mdash; [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
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/

View File

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

View File

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

View File

@ -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()

View File

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

View File

@ -1,6 +1,6 @@
<a class="github" href="decorators.py"></a> <a class="github" href="views.py"></a>
# 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
---
# Function Based Views
> Saying [that Class based views] is always the superior solution is a mistake.
>
> &mdash; [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

View File

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

View File

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

View File

@ -16,7 +16,7 @@
<!--[if lt IE 9]>
<script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
<body onload="prettyPrint()" class="{{ page_id }}">
<body onload="prettyPrint()" class="{{ page_id }}-page">
<div class="navbar navbar-inverse navbar-fixed-top">
<div class="navbar-inner">
@ -55,6 +55,7 @@
<li><a href="{{ base_url }}/api-guide/authentication{{ suffix }}">Authentication</a></li>
<li><a href="{{ base_url }}/api-guide/permissions{{ suffix }}">Permissions</a></li>
<li><a href="{{ base_url }}/api-guide/throttling{{ suffix }}">Throttling</a></li>
<li><a href="{{ base_url }}/api-guide/pagination{{ suffix }}">Pagination</a></li>
<li><a href="{{ base_url }}/api-guide/content-negotiation{{ suffix }}">Content negotiation</a></li>
<li><a href="{{ base_url }}/api-guide/format-suffixes{{ suffix }}">Format suffixes</a></li>
<li><a href="{{ base_url }}/api-guide/reverse{{ suffix }}">Returning URLs</a></li>
@ -122,4 +123,4 @@
event.stopPropagation();
});
</script>
</body></html>
</body></html>

View File

@ -1,10 +1,10 @@
# Browser based PUT & DELETE
# Browser hacks
> "There are two noncontroversial uses for overloaded POST. The first is to *simulate* HTTP's uniform interface for clients like web browsers that don't support PUT or DELETE"
>
> &mdash; [RESTful Web Services](1), Leonard Richardson & Sam Ruby.
## Overloading the HTTP method
## Browser based PUT, DELETE, etc...
**TODO: Preamble.** Note that this is the same strategy as is used in [Ruby on Rails](2).
@ -16,7 +16,7 @@ For example, given the following form:
`request.method` would return `"DELETE"`.
## Overloading the HTTP content type
## Browser based submission of non-form content
Browser-based submission of content types other than form are supported by using form fields named `_content` and `_content_type`:
@ -29,13 +29,13 @@ For example, given the following form:
`request.content_type` would return `"application/json"`, and `request.content` would return `"{'count': 1}"`
## Why not just use Javascript?
## URL based accept headers
**[TODO]**
## URL based format suffixes
## Doesn't HTML5 support PUT and DELETE forms?
Nope. It was at one point intended to support `PUT` and `DELETE` forms, but was later [dropped from the spec](3). There remains [ongoing discussion](4) about adding support for `PUT` and `DELETE`, as well as how to support content-types other than form-encoded data.
Nope. It was at one point intended to support `PUT` and `DELETE` forms, but was later [dropped from the spec](3). There remains [ongoing discussion](4) about adding support for `PUT` and `DELETE`, as well as how to support content types other than form-encoded data.
[1]: http://www.amazon.com/Restful-Web-Services-Leonard-Richardson/dp/0596529260
[2]: http://guides.rubyonrails.org/form_helpers.html#how-do-forms-with-put-or-delete-methods-work

View File

@ -139,7 +139,13 @@ class Field(object):
if hasattr(self, 'model_field'):
return self.to_native(self.model_field._get_val_from_obj(obj))
return self.to_native(getattr(obj, self.source or field_name))
if self.source:
value = obj
for component in self.source.split('.'):
value = getattr(value, component)
else:
value = getattr(obj, field_name)
return self.to_native(value)
def to_native(self, value):
"""
@ -152,6 +158,8 @@ class Field(object):
return value
elif hasattr(self, 'model_field'):
return self.model_field.value_to_string(self.obj)
elif hasattr(value, '__iter__') and not isinstance(value, (dict, basestring)):
return [self.to_native(item) for item in value]
return smart_unicode(value)
def attributes(self):
@ -175,7 +183,7 @@ class RelatedField(Field):
"""
def field_to_native(self, obj, field_name):
obj = getattr(obj, field_name)
obj = getattr(obj, self.source or field_name)
if obj.__class__.__name__ in ('RelatedManager', 'ManyRelatedManager'):
return [self.to_native(item) for item in obj.all()]
return self.to_native(obj)
@ -215,10 +223,10 @@ class PrimaryKeyRelatedField(RelatedField):
def field_to_native(self, obj, field_name):
try:
obj = obj.serializable_value(field_name)
obj = obj.serializable_value(self.source or field_name)
except AttributeError:
field = obj._meta.get_field_by_name(field_name)[0]
obj = getattr(obj, field_name)
obj = getattr(obj, self.source or field_name)
if obj.__class__.__name__ == 'RelatedManager':
return [self.to_native(item.pk) for item in obj.all()]
elif isinstance(field, RelatedObject):
@ -431,19 +439,3 @@ class FloatField(Field):
except (TypeError, ValueError):
msg = self.error_messages['invalid'] % value
raise ValidationError(msg)
# field_mapping = {
# models.AutoField: IntegerField,
# models.BooleanField: BooleanField,
# models.CharField: CharField,
# models.DateTimeField: DateTimeField,
# models.DateField: DateField,
# models.BigIntegerField: IntegerField,
# models.IntegerField: IntegerField,
# models.PositiveIntegerField: IntegerField,
# models.FloatField: FloatField
# }
# def modelfield_to_serializerfield(field):
# return field_mapping.get(type(field), Field)

View File

@ -2,7 +2,8 @@
Generic views that provide commmonly needed behaviour.
"""
from rest_framework import views, mixins, serializers
from rest_framework import views, mixins
from rest_framework.settings import api_settings
from django.views.generic.detail import SingleObjectMixin
from django.views.generic.list import MultipleObjectMixin
@ -14,22 +15,39 @@ class BaseView(views.APIView):
Base class for all other generic views.
"""
serializer_class = None
model_serializer_class = api_settings.MODEL_SERIALIZER
def get_serializer(self, data=None, files=None, instance=None):
# TODO: add support for files
# TODO: add support for seperate serializer/deserializer
def get_serializer_context(self):
"""
Extra context provided to the serializer class.
"""
return {
'request': self.request,
'format': self.format,
'view': self
}
def get_serializer_class(self):
"""
Return the class to use for the serializer.
Use `self.serializer_class`, falling back to constructing a
model serializer class from `self.model_serializer_class`
"""
serializer_class = self.serializer_class
if serializer_class is None:
class DefaultSerializer(serializers.ModelSerializer):
class DefaultSerializer(self.model_serializer_class):
class Meta:
model = self.model
serializer_class = DefaultSerializer
context = {
'request': self.request,
'format': self.kwargs.get('format', None)
}
return serializer_class
def get_serializer(self, data=None, files=None, instance=None):
# TODO: add support for files
# TODO: add support for seperate serializer/deserializer
serializer_class = self.get_serializer_class()
context = self.get_serializer_context()
return serializer_class(data, instance=instance, context=context)
@ -37,7 +55,24 @@ class MultipleObjectBaseView(MultipleObjectMixin, BaseView):
"""
Base class for generic views onto a queryset.
"""
pass
pagination_serializer_class = api_settings.PAGINATION_SERIALIZER
paginate_by = api_settings.PAGINATE_BY
def get_pagination_serializer_class(self):
"""
Return the class to use for the pagination serializer.
"""
class SerializerClass(self.pagination_serializer_class):
class Meta:
object_serializer_class = self.get_serializer_class()
return SerializerClass
def get_pagination_serializer(self, page=None):
pagination_serializer_class = self.get_pagination_serializer_class()
context = self.get_serializer_context()
return pagination_serializer_class(instance=page, context=context)
class SingleObjectBaseView(SingleObjectMixin, BaseView):

View File

@ -7,6 +7,7 @@ which allows mixin classes to be composed in interesting ways.
Eg. Use mixins to build a Resource class, and have a Router class
perform the binding of http methods to actions for us.
"""
from django.http import Http404
from rest_framework import status
from rest_framework.response import Response
@ -30,9 +31,27 @@ class ListModelMixin(object):
List a queryset.
Should be mixed in with `MultipleObjectBaseView`.
"""
empty_error = u"Empty list and '%(class_name)s.allow_empty' is False."
def list(self, request, *args, **kwargs):
self.object_list = self.get_queryset()
serializer = self.get_serializer(instance=self.object_list)
# Default is to allow empty querysets. This can be altered by setting
# `.allow_empty = False`, to raise 404 errors on empty querysets.
allow_empty = self.get_allow_empty()
if not allow_empty and len(self.object_list) == 0:
error_args = {'class_name': self.__class__.__name__}
raise Http404(self.empty_error % error_args)
# Pagination size is set by the `.paginate_by` attribute,
# which may be `None` to disable pagination.
page_size = self.get_paginate_by(self.object_list)
if page_size:
paginator, page, queryset, is_paginated = self.paginate_queryset(self.object_list, page_size)
serializer = self.get_pagination_serializer(page)
else:
serializer = self.get_serializer(instance=self.object_list)
return Response(serializer.data)

View File

@ -0,0 +1,80 @@
from rest_framework import serializers
# TODO: Support URLconf kwarg-style paging
class NextPageField(serializers.Field):
"""
Field that returns a link to the next page in paginated results.
"""
def to_native(self, value):
if not value.has_next():
return None
page = value.next_page_number()
request = self.context.get('request')
relative_url = '?page=%d' % page
if request:
return request.build_absolute_uri(relative_url)
return relative_url
class PreviousPageField(serializers.Field):
"""
Field that returns a link to the previous page in paginated results.
"""
def to_native(self, value):
if not value.has_previous():
return None
page = value.previous_page_number()
request = self.context.get('request')
relative_url = '?page=%d' % page
if request:
return request.build_absolute_uri('?page=%d' % page)
return relative_url
class PaginationSerializerOptions(serializers.SerializerOptions):
"""
An object that stores the options that may be provided to a
pagination serializer by using the inner `Meta` class.
Accessible on the instance as `serializer.opts`.
"""
def __init__(self, meta):
super(PaginationSerializerOptions, self).__init__(meta)
self.object_serializer_class = getattr(meta, 'object_serializer_class',
serializers.Field)
class BasePaginationSerializer(serializers.Serializer):
"""
A base class for pagination serializers to inherit from,
to make implementing custom serializers more easy.
"""
_options_class = PaginationSerializerOptions
results_field = 'results'
def __init__(self, *args, **kwargs):
"""
Override init to add in the object serializer field on-the-fly.
"""
super(BasePaginationSerializer, self).__init__(*args, **kwargs)
results_field = self.results_field
object_serializer = self.opts.object_serializer_class
self.fields[results_field] = object_serializer(source='object_list')
def to_native(self, obj):
"""
Prevent default behaviour of iterating over elements, and serializing
each in turn.
"""
return self.convert_object(obj)
class PaginationSerializer(BasePaginationSerializer):
"""
A default implementation of a pagination serializer.
"""
count = serializers.Field(source='paginator.count')
next = NextPageField(source='*')
previous = PreviousPageField(source='*')

View File

@ -33,6 +33,8 @@ class Response(SimpleTemplateResponse):
@property
def rendered_content(self):
assert self.renderer, "No renderer set on Response"
self['Content-Type'] = self.renderer.media_type
if self.data is None:
return self.renderer.render()

View File

@ -3,6 +3,7 @@ import datetime
import types
from decimal import Decimal
from django.core.serializers.base import DeserializedObject
from django.db import models
from django.utils.datastructures import SortedDict
from rest_framework.compat import get_concrete_model
from rest_framework.fields import *
@ -70,7 +71,7 @@ class SerializerMetaclass(type):
class SerializerOptions(object):
"""
Meta class options for ModelSerializer
Meta class options for Serializer
"""
def __init__(self, meta):
self.nested = getattr(meta, 'nested', False)
@ -308,17 +309,31 @@ class ModelSerializer(RelatedField, Serializer):
fields += [field for field in opts.many_to_many if field.serialize]
ret = SortedDict()
is_pk = True # First field in the list is the pk
for model_field in fields:
if model_field.rel and nested:
if is_pk:
field = self.get_pk_field(model_field)
is_pk = False
elif model_field.rel and nested:
field = self.get_nested_field(model_field)
elif model_field.rel:
field = self.get_related_field(model_field)
else:
field = self.get_field(model_field)
field.initialize(parent=self, model_field=model_field)
ret[model_field.name] = field
if field is not None:
field.initialize(parent=self, model_field=model_field)
ret[model_field.name] = field
return ret
def get_pk_field(self, model_field):
"""
Returns a default instance of the pk field.
"""
return Field(readonly=True)
def get_nested_field(self, model_field):
"""
Creates a default instance of a nested relational field.
@ -333,9 +348,22 @@ class ModelSerializer(RelatedField, Serializer):
def get_field(self, model_field):
"""
Creates a default instance of a basic field.
Creates a default instance of a basic non-relational field.
"""
return Field()
field_mapping = dict([
[models.FloatField, FloatField],
[models.IntegerField, IntegerField],
[models.DateTimeField, DateTimeField],
[models.DateField, DateField],
[models.EmailField, EmailField],
[models.CharField, CharField],
[models.CommaSeparatedIntegerField, CharField],
[models.BooleanField, BooleanField]
])
try:
return field_mapping[model_field.__class__]()
except KeyError:
return Field()
def restore_object(self, attrs, instance=None):
"""

View File

@ -44,13 +44,17 @@ DEFAULTS = {
'anon': None,
},
'MODEL_SERIALIZER': 'rest_framework.serializers.ModelSerializer',
'PAGINATION_SERIALIZER': 'rest_framework.pagination.PaginationSerializer',
'PAGINATE_BY': 20,
'UNAUTHENTICATED_USER': 'django.contrib.auth.models.AnonymousUser',
'UNAUTHENTICATED_TOKEN': None,
'FORM_METHOD_OVERRIDE': '_method',
'FORM_CONTENT_OVERRIDE': '_content',
'FORM_CONTENTTYPE_OVERRIDE': '_content_type',
'URL_ACCEPT_OVERRIDE': '_accept',
'URL_ACCEPT_OVERRIDE': 'accept',
'URL_FORMAT_OVERRIDE': 'format',
'FORMAT_SUFFIX_KWARG': 'format'
@ -65,6 +69,8 @@ IMPORT_STRINGS = (
'DEFAULT_PERMISSIONS',
'DEFAULT_THROTTLES',
'DEFAULT_CONTENT_NEGOTIATION',
'MODEL_SERIALIZER',
'PAGINATION_SERIALIZER',
'UNAUTHENTICATED_USER',
'UNAUTHENTICATED_TOKEN',
)

View File

@ -1,5 +1,5 @@
from django import template
from django.core.urlresolvers import reverse, NoReverseMatch
from django.core.urlresolvers import reverse
from django.http import QueryDict
from django.utils.encoding import force_unicode
from django.utils.html import escape

View File

@ -13,6 +13,7 @@ class RootView(generics.RootAPIView):
Example description for OPTIONS.
"""
model = BasicModel
paginate_by = None
class InstanceView(generics.InstanceAPIView):
@ -51,7 +52,8 @@ class TestRootView(TestCase):
POST requests to RootAPIView should create a new object.
"""
content = {'text': 'foobar'}
request = factory.post('/', json.dumps(content), content_type='application/json')
request = factory.post('/', json.dumps(content),
content_type='application/json')
response = self.view(request).render()
self.assertEquals(response.status_code, status.HTTP_201_CREATED)
self.assertEquals(response.data, {'id': 4, 'text': u'foobar'})
@ -63,7 +65,8 @@ class TestRootView(TestCase):
PUT requests to RootAPIView should not be allowed
"""
content = {'text': 'foobar'}
request = factory.put('/', json.dumps(content), content_type='application/json')
request = factory.put('/', json.dumps(content),
content_type='application/json')
response = self.view(request).render()
self.assertEquals(response.status_code, status.HTTP_405_METHOD_NOT_ALLOWED)
self.assertEquals(response.data, {"detail": "Method 'PUT' not allowed."})
@ -99,6 +102,19 @@ class TestRootView(TestCase):
self.assertEquals(response.status_code, status.HTTP_200_OK)
self.assertEquals(response.data, expected)
def test_post_cannot_set_id(self):
"""
POST requests to create a new object should not be able to set the id.
"""
content = {'id': 999, 'text': 'foobar'}
request = factory.post('/', json.dumps(content),
content_type='application/json')
response = self.view(request).render()
self.assertEquals(response.status_code, status.HTTP_201_CREATED)
self.assertEquals(response.data, {'id': 4, 'text': u'foobar'})
created = self.objects.get(id=4)
self.assertEquals(created.text, 'foobar')
class TestInstanceView(TestCase):
def setUp(self):
@ -129,7 +145,8 @@ class TestInstanceView(TestCase):
POST requests to InstanceAPIView should not be allowed
"""
content = {'text': 'foobar'}
request = factory.post('/', json.dumps(content), content_type='application/json')
request = factory.post('/', json.dumps(content),
content_type='application/json')
response = self.view(request).render()
self.assertEquals(response.status_code, status.HTTP_405_METHOD_NOT_ALLOWED)
self.assertEquals(response.data, {"detail": "Method 'POST' not allowed."})
@ -139,7 +156,8 @@ class TestInstanceView(TestCase):
PUT requests to InstanceAPIView should update an object.
"""
content = {'text': 'foobar'}
request = factory.put('/1', json.dumps(content), content_type='application/json')
request = factory.put('/1', json.dumps(content),
content_type='application/json')
response = self.view(request, pk=1).render()
self.assertEquals(response.status_code, status.HTTP_200_OK)
self.assertEquals(response.data, {'id': 1, 'text': 'foobar'})
@ -178,3 +196,16 @@ class TestInstanceView(TestCase):
}
self.assertEquals(response.status_code, status.HTTP_200_OK)
self.assertEquals(response.data, expected)
def test_put_cannot_set_id(self):
"""
POST requests to create a new object should not be able to set the id.
"""
content = {'id': 999, 'text': 'foobar'}
request = factory.put('/1', json.dumps(content),
content_type='application/json')
response = self.view(request, pk=1).render()
self.assertEquals(response.status_code, status.HTTP_200_OK)
self.assertEquals(response.data, {'id': 1, 'text': 'foobar'})
updated = self.objects.get(id=1)
self.assertEquals(updated.text, 'foobar')

View File

@ -0,0 +1,87 @@
from django.core.paginator import Paginator
from django.test import TestCase
from django.test.client import RequestFactory
from rest_framework import generics, status, pagination
from rest_framework.tests.models import BasicModel
factory = RequestFactory()
class RootView(generics.RootAPIView):
"""
Example description for OPTIONS.
"""
model = BasicModel
paginate_by = 10
class IntegrationTestPagination(TestCase):
"""
Integration tests for paginated list views.
"""
def setUp(self):
"""
Create 26 BasicModel intances.
"""
for char in 'abcdefghijklmnopqrstuvwxyz':
BasicModel(text=char * 3).save()
self.objects = BasicModel.objects
self.data = [
{'id': obj.id, 'text': obj.text}
for obj in self.objects.all()
]
self.view = RootView.as_view()
def test_get_paginated_root_view(self):
"""
GET requests to paginated RootAPIView should return paginated results.
"""
request = factory.get('/')
response = self.view(request).render()
self.assertEquals(response.status_code, status.HTTP_200_OK)
self.assertEquals(response.data['count'], 26)
self.assertEquals(response.data['results'], self.data[:10])
self.assertNotEquals(response.data['next'], None)
self.assertEquals(response.data['previous'], None)
request = factory.get(response.data['next'])
response = self.view(request).render()
self.assertEquals(response.status_code, status.HTTP_200_OK)
self.assertEquals(response.data['count'], 26)
self.assertEquals(response.data['results'], self.data[10:20])
self.assertNotEquals(response.data['next'], None)
self.assertNotEquals(response.data['previous'], None)
request = factory.get(response.data['next'])
response = self.view(request).render()
self.assertEquals(response.status_code, status.HTTP_200_OK)
self.assertEquals(response.data['count'], 26)
self.assertEquals(response.data['results'], self.data[20:])
self.assertEquals(response.data['next'], None)
self.assertNotEquals(response.data['previous'], None)
class UnitTestPagination(TestCase):
"""
Unit tests for pagination of primative objects.
"""
def setUp(self):
self.objects = [char * 3 for char in 'abcdefghijklmnopqrstuvwxyz']
paginator = Paginator(self.objects, 10)
self.first_page = paginator.page(1)
self.last_page = paginator.page(3)
def test_native_pagination(self):
serializer = pagination.PaginationSerializer(instance=self.first_page)
self.assertEquals(serializer.data['count'], 26)
self.assertEquals(serializer.data['next'], '?page=2')
self.assertEquals(serializer.data['previous'], None)
self.assertEquals(serializer.data['results'], self.objects[:10])
serializer = pagination.PaginationSerializer(instance=self.last_page)
self.assertEquals(serializer.data['count'], 26)
self.assertEquals(serializer.data['next'], None)
self.assertEquals(serializer.data['previous'], '?page=2')
self.assertEquals(serializer.data['results'], self.objects[20:])

View File

@ -11,6 +11,7 @@ from rest_framework.views import APIView
from rest_framework.renderers import BaseRenderer, JSONRenderer, YAMLRenderer, \
XMLRenderer, JSONPRenderer, DocumentingHTMLRenderer
from rest_framework.parsers import YAMLParser, XMLParser
from rest_framework.settings import api_settings
from StringIO import StringIO
import datetime
@ -164,7 +165,11 @@ class RendererEndToEndTests(TestCase):
def test_specified_renderer_serializes_content_on_accept_query(self):
"""The '_accept' query string should behave in the same way as the Accept header."""
resp = self.client.get('/?_accept=%s' % RendererB.media_type)
param = '?%s=%s' % (
api_settings.URL_ACCEPT_OVERRIDE,
RendererB.media_type
)
resp = self.client.get('/' + param)
self.assertEquals(resp['Content-Type'], RendererB.media_type)
self.assertEquals(resp.content, RENDERER_B_SERIALIZER(DUMMYCONTENT))
self.assertEquals(resp.status_code, DUMMYSTATUS)
@ -177,7 +182,11 @@ class RendererEndToEndTests(TestCase):
def test_specified_renderer_serializes_content_on_format_query(self):
"""If a 'format' query is specified, the renderer with the matching
format attribute should serialize the response."""
resp = self.client.get('/?format=%s' % RendererB.format)
param = '?%s=%s' % (
api_settings.URL_FORMAT_OVERRIDE,
RendererB.format
)
resp = self.client.get('/' + param)
self.assertEquals(resp['Content-Type'], RendererB.media_type)
self.assertEquals(resp.content, RENDERER_B_SERIALIZER(DUMMYCONTENT))
self.assertEquals(resp.status_code, DUMMYSTATUS)
@ -193,7 +202,11 @@ class RendererEndToEndTests(TestCase):
def test_specified_renderer_is_used_on_format_query_with_matching_accept(self):
"""If both a 'format' query and a matching Accept header specified,
the renderer with the matching format attribute should serialize the response."""
resp = self.client.get('/?format=%s' % RendererB.format,
param = '?%s=%s' % (
api_settings.URL_FORMAT_OVERRIDE,
RendererB.format
)
resp = self.client.get('/' + param,
HTTP_ACCEPT=RendererB.media_type)
self.assertEquals(resp['Content-Type'], RendererB.media_type)
self.assertEquals(resp.content, RENDERER_B_SERIALIZER(DUMMYCONTENT))

View File

@ -11,6 +11,7 @@ from rest_framework.renderers import (
JSONRenderer,
DocumentingHTMLRenderer
)
from rest_framework.settings import api_settings
class MockPickleRenderer(BaseRenderer):
@ -121,7 +122,11 @@ class RendererIntegrationTests(TestCase):
def test_specified_renderer_serializes_content_on_accept_query(self):
"""The '_accept' query string should behave in the same way as the Accept header."""
resp = self.client.get('/?_accept=%s' % RendererB.media_type)
param = '?%s=%s' % (
api_settings.URL_ACCEPT_OVERRIDE,
RendererB.media_type
)
resp = self.client.get('/' + param)
self.assertEquals(resp['Content-Type'], RendererB.media_type)
self.assertEquals(resp.content, RENDERER_B_SERIALIZER(DUMMYCONTENT))
self.assertEquals(resp.status_code, DUMMYSTATUS)