django-dynamicresponse

Lightweight framework for easily providing REST APIs for web apps built with Django.


License
BSD-3-Clause
Install
pip install django-dynamicresponse==0.5.0

Documentation

django-dynamicresponse

django-dynamicresponse is a lightweight framework for easily providing REST API's for Django applications.

The framework is intentionally very lightweight and minimalistic, and is designed to interoperate with existing Django code (such as form validation), without major changes.

In most cases, the only changes needed to add full REST API to an existing Django application is modifying the return statements in your views to return one of the response classes described below instead of a standard Django HttpResponse.

Features

  • Easy integration with existing code
  • Reuse same views and logic for both API and normal requests (no need for separate API handlers)
  • Decodes submitted JSON into request.POST, fully compatible with Django forms
  • Built-in support for HTTP Basic authentication

Installation

Install django-dynamicresponse:

pip install django-dynamicresponse

Alternatively, download the source code and manually add it to your PYTHONPATH.

Add the two middleware classes to MIDDLEWARE_CLASSES in your settings.py:

MIDDLEWARE_CLASSES = (
   'dynamicresponse.middleware.api.APIMiddleware',
   'dynamicresponse.middleware.dynamicformat.DynamicFormatMiddleware',
)

APIMiddleware detects incoming API requests based on HTTP headers and provides support for Basic authentication.

DynamicFormatMiddleware decodes incoming JSON content into request.POST, as well as rendering appropriate responses based on the returned value from your views.

Settings

These are the available configurable settings, along with their default values:

Name Default Description
DYNAMICRESPONSE_JSON_FORM_ERRORS False Outputs form errors in JSON
DYNAMICRESPONSE_BASIC_REALM_NAME 'API' The name of the Basic Auth realm
DYNAMICRESPONSE_DJANGO_USER_FIELDS ('id', 'email', 'first_name', 'last_name') Defines which fields to include when serializing a Django auth User object

Tests

Run unit tests by running python setup.py test

Usage

See the included sample project for sample code using the framework to implement a simple blog application.

Import dynamicresponse in the views you want to use it:

from dynamicresponse.response import *

Return an instance of the appropriate response class depending on your view logic:

@login_required
def customer_list(request):
    """Lists all customers."""

    customers = Customer.objects.all()
    return SerializeOrRender('customers/list.html', { 'customers': customers })

The framework provides two response classes; SerializeOrRender and SerializeOrRedirect.

As the names imply, these response classes serialize the supplied context as JSON for API requests, and renders a template or redirects to a URL for normal requests. The first argument of both classes specifies the template to be rendered or the URL to redirect the user to.

To implement a REST API, you simply use SerializeOrRender in situations where you would typically use render_to_response, and SerializeOrRedirect in cases where you would otherwise return an HttpResponseRedirect instance.

For API requests, the second argument of the constructor is the context to be serialized for API requests. When rendering templates, it is often useful to pass additional context (such as forms and paginators) that is only useful when rendering the template, even though they are not relevant for API requests. The SerializeOrRender class supports additional context via a third argument, extra:

@login_required
def customer_list(request):
    """Lists all customers."""

    customers = Customer.objects.all()
    return SerializeOrRender('customers/list.html', { 'customers': customers }, extra={ 'somevalue': 'something' })

In this case, only customers are serialized in API responses, while both customers and somevalue is accessible when the template is rendered for normal requests.

Status codes

Content is normally returned as JSON with HTTP status code 200. If you want to return a different status code, set the status argument to one of the following values:

Constant HTTP status Description
CR_OK 200 Default status
CR_INVALID_DATA 400 One or more forms are invalid
CR_NOT_FOUND 404 Not found (optional alternative to HttpResponseNotFound for consistency)
CR_CONFIRM 405 Confirm action with HTTP POST (use with SerializeOrRender with confirmation template)
CR_DELETED 204 The resource has been deleted

You can add custom status values by defining them as a tuple consisting of a string constant and the HTTP status code to return:

CR_REQUIRES_UPGRADE = ('REQUIRES_UPGRADE', 402)

Customizing serialization

By default, all fields not starting with an underscore (_) on the models will be serialized when returning a JSON response for API requests.

You can override this behavior by adding a serialize_fields method to your models, returning the fields to include:

class BlogPost(models.Model):

    title = models.CharField('Title', max_length=255)
    text = models.TextField('Text')

    def serialize_fields(self):
        """Only these fields will be included in API responses."""
    
        return [
            'id',
            'title',
            'content',
        ]

This behavior also extends to nested objects. For instance, if the model above had included a foreign key to an author, only the fields defined in the author's serialize_fields method would have been included.

By default, callables are not included in the serialization. However, you can include names of callables in serialize_fields to explicitly include them in the serialization. This can for instance be useful to provide API users with useful dynamically computed information.