Package: django-simple-rest
Django Simple RESTDjango Simple REST is a very light framework that provides only the bare bones basics of what is needed to create RESTful APIs on top of Django.InstallationInstall using pip or easy_install:pip installdjango-simple-restoreasy_install installdjango-simple-restAdd the package to the list of installed apps (optional):INSTALLED_APPS +=['simple-rest']This step is optional and is only needed if you plan on using the custom django command(s).Why Another REST Framework?That’s a great question, and the simplest answer to it is that this really isn’t a framework at all, but let me explain a bit further.With the introduction of class-based views in version 1.3 of Django, the web framework has nearly everything it needs built in to create RESTful APIs, but just a few things are missing. This “framework” supplies those last few things.Think of Simple REST as the code that you would have written to get class-based views working properly as a platform for RESTful API development. Looked at from that view, you start to understand what Simple REST1 is; it’s a collection of code that makes it possible to create RESTful APIs with Django’s class-based views, nothing more and nothing less.If you like creating your API by hand, laboring over every last URL, then this is the framework for you. If you want something a little more full featured that handles creating large swaths of your API from Django models and things like that, let me suggest a few excellent frameworks:Tastypie,Piston, andDjango REST.How do I use it?There’s nothing to it, it works just like you’d expect it to—assuming you’re familiar with Django’sclass based views. Before we get started though, let’s create a base project and application for us to play around with.Sample Project SetupThe code in the rest of this document will assume that you’re using Django 1.4 or greater (you can follow along using Django 1.3, but your directory structure will be slightly different form the one below) and that you’ve created a project calledsimple_rest_exampleand an application within it calledphonebook.Once you’ve created your sample project and application, you’ll need to add a new URLconf to the phonebook application where we will add all of our routes for the duration of this tutorial. Then, update the URLconf in thesimple_rest_examplefolder to include the URLconf you’ve just created. This will allow us to do all of our work in the phonebook app from here on out. Theurls.pyfile in yoursimple_rest_examplefolder should now look like the following:# =============================
# simple_rest_example/views.py
# =============================

from django.conf.urls import patterns, include, url

urlpatterns = patterns('',
    url(r'^phonebook/', include('phonebook.urls')),
)If you’ve set everything up correctly, you should have a directory structure that matches the one shown below:simple_rest_example
        |
        |___ simple_rest_sample
        |           |___ __init__.py
        |           |___ settings.py
        |           |___ urls.py
        |           |___ wsgi.py
        |
        |___ phonebook
        |       |
        |       |___ __init__.py
        |       |___ models.py
        |       |___ tests.py
        |       |___ urls.py
        |       |___ views.py
        |
        |___ manage.pyFinally, we’re going to create a new model class calledContactand create our database to hold all of the contacts in our phonebook. Open upphonebook/models.pyand update it to match the following:# =====================
# phonebook/models.py
# =====================

from django.db import models

class Contact(models.Model):
    fname = models.CharField(max_length=30)
    lname = models.CharField(max_length=30)
    phone_number = models.CharField(max_length=12)Once you’ve added a new model, update thesettings.pyfile in thesimple_rest_exampledirectory to use a sqlite database named phonebook.db and run themanage.py syncdbcommand to create the database. Make sure to add an administrator account so that we’ll have something to use later on when discussing the authentication options provided by the Simple REST framework.Creating a ResourceNow that you’ve got your development environment set up properly, let’s take a look at an example of how to use the Simple REST framework to create a dead simple phonebook application.The sample code below shows one example of how we could create a simple resource for managing lists of contacts:# ====================
# phonebook/views.py
# ====================

from django.http import HttpResponse
from django.core import serializers

from simple_rest import Resource

from .models import Contact


class Contacts(Resource):

    def get(self, request, contact_id=None, **kwargs):
        json_serializer = serializers.get_serializer('json')()
        if contact_id:
            contacts = json_serializer.serialize(Contact.objects.filter(pk=contact_id))
        else:
            contacts = json_serializer.serialize(Contact.objects.all())
        return HttpResponse(contacts, content_type='application/json', status=200)

    def post(self, request, *args, **kwargs):
        Contact.objects.create(
            fname=request.POST.get('fname'),
            lname=request.POST.get('lname'),
            phone_number=request.POST.get('phone_number'))
        return HttpResponse(status=201)

    def delete(self, request, contact_id):
        contact = Contact.objects.get(pk=contact_id)
        contact.delete()
        return HttpResponse(status=200)In the example code above, we imported theResourceclass, which simply inherits from Django’sViewclass and provides the extra sauce to get all of the HTTP methods working properly. Then, we create a new class that inherits from theResourceclass, and we add a function for each HTTP method that we want to handle.The only requirement is that the function name must match the HTTP method name and be in all lower case letters, sogetfor a GET call and so forth.Notice that in thepostmethod, the data for the message body of the request can be accessed through therequest.POSTQueryDictobject. Since all exsiting browsers can only handle GET and POST requests, havingQueryDict``sfor GET and POST were all that were needed in the past and so those were all that Django has historically provided. However, with a RESTful API, the server can receive requests using any HTTP method. As a result, the message body for a request can be found in the corresponding ``QueryDicton therequestobject. For example, if a PUT request is made, the message body data can be accessed through therequest.PUTQueryDict.Considering that browsers only support the GET and POST methods, the Simple REST framework also provides an HTTP method override that can be used to make it possible for a typical website to use a RESTful backend. To override the HTTP method, send the attribute_method, either in the querystring or in the message body, set to the HTTP method you want the request to be treated as.One issue that can arise when allowing the user to use the_methodoption is that the data may not always be in the place you expect it to be. For example, let’s assume that you’ve received a POST request to create a new contact. In this scenario, all of the data can be found in therequest.POSTQueryDictobject as you would expect. However, if you were to send a GET request with all of the data in the querystring and set the_methodto POST, ourpostmethod in the example above would throw an exception. The reason is that request would be treated as a POST request, but the``request.POST``QueryDictobject would be empty since the original request was a GET and all of its data would then be found within therequest.GETQueryDict. To make your code more flexible when allowing this option, you should consider using therequest.REQUESTQueryDictinstead to get all of the data in the request since Django basically compiles all of the data sent into this single object.Now, let’s see how to hook up our resource:# ===================
# phonebook/urls.py
# ===================

from django.conf.urls import patterns, include, url

from .views import Contacts

urlpatterns = patterns('',
    # Allow access to the contacts resource collection
    url(r'^contacts/?$', Contacts.as_view()),

    # Allow access to a single contact resource
    url(r'^contacts/(?P<contact_id>[0-9]+)/?$', Contacts.as_view()),
)The sampleurls.pyabove shows exactly how we would go about creating the URL patterns for our example resource. Again, if you’re familiar with Django class based views, there should be no surprises here.AuthenticationSo what about authentication? Well, you could simply use themethod_decoratorfunction as theDjango docs suggestto decorate each method in your resource with the appropriate authentication decorator. Assuming you want the entire resource protected, you could also decorate the result of the call toas_viewin the URLconf. Both of these options are completely valid and you can feel free to use them, this framework does provide another option, however.In thesimple_rest.auth.decoratorsmodule you’ll find decorators there that you can use to add authentication to your resources. Let’s take a look at a few examples using our sample code from above:# ====================
# phonebook/views.py
# ====================

from django.http import HttpResponse
from django.core import serializers

from simple_rest import Resource
from simple_rest.auth.decorators import login_required, admin_required

from .models import Contact


class Contacts(Resource):

    def get(self, request, contact_id=None, **kwargs):
        json_serializer = serializers.get_serializer('json')()
        if contact_id:
            contacts = json_serializer.serialize(Contact.objects.filter(pk=contact_id))
        else:
            contacts = json_serializer.serialize(Contact.objects.all())
        return HttpResponse(contacts, content_type='application/json', status=200)

    @login_required
    def post(self, request, *args, **kwargs):
        Contact.objects.create(
            fname=request.POST.get('fname'),
            lname=request.POST.get('lname'),
            phone_number=request.POST.get('phone_number'))
        return HttpResponse(status=201)

    @admin_required
    def delete(self, request, contact_id):
        contact = Contact.objects.get(pk=contact_id)
        contact.delete()
        return HttpResponse(status=200)Assuming that we don’t mind if anyone sees our collection of contacts, we can leavegetmethod as is, but let’s assume that we have strict requirements for who can add and delete contacts. Assuming that only registered users can add contacts, we add thelogin_requireddecorator to thepostmethod. We don’t mind if any our members add new contacts, but we don’t want a contact to be accidentally deleted from our database, so let’s decorate that one differently with theadmin_requireddecorator.admin_requiredsimply makes sure that the user is logged in and is also a super user before they will be granted access to the decorated view method.Now, this can get a bit tedious if we have lots of resources and they all tend to have the same authentication requirements. To make a little less tedious, the authentication decorators work on both classes and methods. In the example below we’re adding a superuser requirement to every method offered by the resource simply by decorating the resource class:# ====================
# phonebook/views.py
# ====================

from django.http import HttpResponse
from django.core import serializers

from simple_rest import Resource
from simple_rest.auth.decorators import admin_required

from .models import Contact


@admin_required
class Contacts(Resource):

    def get(self, request, contact_id=None, **kwargs):
        json_serializer = serializers.get_serializer('json')()
        if contact_id:
            contacts = json_serializer.serialize(Contact.objects.filter(pk=contact_id))
        else:
            contacts = json_serializer.serialize(Contact.objects.all())
        return HttpResponse(contacts, content_type='application/json', status=200)

    def post(self, request, *args, **kwargs):
        Contact.objects.create(
            fname=request.POST.get('fname'),
            lname=request.POST.get('lname'),
            phone_number=request.POST.get('phone_number'))
        return HttpResponse(status=201)

    def delete(self, request, contact_id):
        contact = Contact.objects.get(pk=contact_id)
        contact.delete()
        return HttpResponse(status=200)Before we leave the topic of authentication decorators there are two more items to take a look at.First, when using the framework’s authentication decorators, the correct RESTful response is returned whenever authentication fails. The typical Django authentication decorators will try to redirect the user to the login page. While this is great when you’re on a webpage, when accessing the resource from any other type of client, receiving a 401 (Unauthorized) is the preferred response and the one that is returned when using Simple REST authentication decorators. For that reason alone, you should prefer the Simple REST authentication decorators over Django’s built in ones when creating a RESTful API.The other item to discuss is thesignature_requiredauthentication decorator. Many APIs use a secure signature to identify and the Simple REST framework provides an authentication decorator that you can use to add that functionality to your resources. Thesignature_requireddecorator will expect that anHMAC, as defined byRFC 2104, is sent with the HTTP request in order to authenticate the user. An HMAC is built around a user’s secret key and so there needs to be a way for thesignature_requireddecorator to get that secret key and that is done by providing the decorator with a function that takes a DjangoHttpRequestobject and any number of positional and keyword arguments as defined by the URLconf. Let’s take a look at an example of using thesignature_requireddecorator with our sample resource code:# ====================
# phonebook/views.py
# ====================

from django.http import HttpResponse
from django.core import serializers

from simple_rest import Resource
from simple_rest.auth.decorators import signature_required

from .models import Contact


def secret_key(request, *args, **kwargs):
    return 'test'

@signature_required(secret_key)
class Contacts(Resource):

    def get(self, request, contact_id=None, **kwargs):
        json_serializer = serializers.get_serializer('json')()
        if contact_id:
            contacts = json_serializer.serialize(Contact.objects.filter(pk=contact_id))
        else:
            contacts = json_serializer.serialize(Contact.objects.all())
        return HttpResponse(contacts, content_type='application/json', status=200)

    def post(self, request, *args, **kwargs):
        Contact.objects.create(
            fname=request.POST.get('fname'),
            lname=request.POST.get('lname'),
            phone_number=request.POST.get('phone_number'))
        return HttpResponse(status=201)

    def delete(self, request, contact_id):
        contact = Contact.objects.get(pk=contact_id)
        contact.delete()
        return HttpResponse(status=200)Thesignature_requireddecorator takes one argument, a function that, when called with an HttpRequest object and any number of positional and keyword arguments as defined by the URLconf entry for the resource, will return a string representing the secret key for the user making the request. In the example above, we created a function that returns the string ‘test’ no matter what arguments are passed into the function. Obviously, you don’t want to use a secret key function like this in production, but for our purposes it will suffice.To test out thesignature_requireddecorator, you can hit any of the URLs for the Contacts resource with atvalue representing a UTC POSIX timestamp for the current time and asigvalue representing the HMAC signature generated from the data being sent, the timestamp, and the secret key (in this case, ‘test’). If you’ve added ‘simple_rest’ to your list ofINSTALLED_APPS, you can use the handyurlencodecommand to calculate the signature and timestamp for testing your resources. The command line below shows how to generate the timestamp and signature values for a simple GET request. To test the GET call, just enter the line below into your command line and copy and paste the response to the querystring part of the URL:% manage.py urlencode --secret-key=testTo URL encode the request body as well, just include each piece of data as a key=value pair in the call to theurlencodecommand. As an example of how to do so, let’s test thePOSTcall. Run the following command in your terminal and copy the results into either the request body or the querystring portion of the URL:% manage.py urlencode --secret-key fname=Winston lname=Smith phone_number=555-555-5555Simple REST provides one more decorator that’s sort of a mashup of two other decorators. The decoratorauth_requiredworks in the same manner as thesignature_required(meaning that it takes a function that returns a secret key) but it requires that the user is either logged in or has a valid signature before granting them access to the resource.Finally, you can create your own authentication decorators with relative ease. The Simple REST framework provides two functions to help out with this task. First, therequest_passes_testfunction can be used to create a new decorator function. Then thewrap_objectfunction can be used to properly decorate either an entire class or a specific method within. The code below shows a sample of how you would create a decorator that makes sure a user has the proper permission to access a resource:from simple_rest.auth.decorators import request_passes_test
from simple_rest.utils.decorators import wrap_object


def has_permission(request, *args, **kwargs):
    return False # Make sure the user has the proper permission here

def permission_required(obj):
    decorator = request_passes_test(has_permission,
        message="You don't have permission to access this resource",
        status=403
    )
    return wrap_object(obj, decorator)Form ValidationIf you want to use a form to validate the data in a REST request (e.g., a POST to create a new resource) you can run into some problems using Django’s ModelForm class. Specifically, let’s assume that you have a model that has several optional attributes with default values specified. If you send a request to create a new instance of this class but only include data for a handful of the optional attributes, you’d expect that the form object you create would not fail validation since saving the object would mean that the new record would simply end up with the default values for the missing attributes. This is, however, not the case with Django’s ModelForm class. It is expecting to see all of the data in every request and will fail if any is missing.To solve this issue, the Simple REST framework provides aModelFormclass insimple_rest.formsthat inherits from Django’sModelFormand initializes the incoming request with the default values from the underlying model object for any missing attributes. This allows the form validation to work correctly and for the new object to be saved with only a portion of the full set of attributes sent within the request. To use the class, simply import it instead of the normal DjangoModelFormand have your form class inherit from it instead of Django’s.To give it a try, let’s add another field to theContactmodel class inphonebook/models.pyto hold an honorific for a contact. We’ll make this field optional and make the default title be ‘(no title)’. With these new changes, themodels.pyfile should match the one listed below:# ====================
# phonebook/models.py
# ====================

from django.db import models

class Contact(models.Model):
    title = models.CharField(max_length=10, default='(no title)')
    fname = models.CharField(max_length=30)
    lname = models.CharField(max_length=30)
    phone_number = models.CharField(max_length=12)Once, you’ve updated themodels.pyfile, either delete and rerunsyncdbor add the new column to the phonebook_contact table by hand. Then, create a new form class calledContactFormin thephonebook/views.pyfile and set its model toContact. Then you can remove the code to create a new contact in thepostmethod and replace it with code that uses the newContactformclass. The result should be similar to the following:# ====================
# phonebook/views.py
# ====================

from django.http import HttpResponse
from django.core import serializers

from simple_rest import Resource
from simple_rest.auth.decorators import signature_required
from simple_rest.forms import ModelForm

from .models import Contact


def secret_key(request, *args, **kwargs):
    return 'test'


class ContactForm(ModelForm):
    class Meta:
        model = Contact


@signature_required(secret_key)
class Contacts(Resource):

    def get(self, request, contact_id=None, **kwargs):
        json_serializer = serializers.get_serializer('json')()
        if contact_id:
            contacts = json_serializer.serialize(Contact.objects.filter(pk=contact_id))
        else:
            contacts = json_serializer.serialize(Contact.objects.all())
        return HttpResponse(contacts, content_type='application/json', status=200)

    def post(self, request, *args, **kwargs):
        form = ContactForm(request.POST)
        if not form.is_valid():
            return HttpResponse(status=409)
        form.save()
        return HttpResponse(status=201)

    def delete(self, request, contact_id):
        contact = Contact.objects.get(pk=contact_id)
        contact.delete()
        return HttpResponse(status=200)Content NegotiationA key factor to having a truly RESTful API is the decoupling of your resources from their representation. In other words, whether or not a resource is delivered as XML or JSON shouldn’t be part of the resource itself. This is wherecontent negotiationcomes into play. It provides a standardized way for a single URI to serve a resource while still allowing the user to request several different representations of that resource. Content negotiation is part of the HTTP specification and the mechanism it provides the client for requesting a representation is through the Accept header. In the Accept header the client gives a list of acceptable representations and the server works out the best possible representation of the resource to deliver according to what is available on the server and desired representations requested.The Simple Rest framework provides a mechanism by which you can add content negotiation to your resources. This functionality is provided in theRESTfulResponseclass. TheRESTfulResponseclass is an implementation of the method described by James Bennett in his article “Another take on content negotiation”. The way it works is simple, create an instance of the class and use it as a decorator on your resource. The rest of this section will take a look at a few examples to show the different options available to you when using theRESTfulResonseclass to provide multiple representations of your resource.The first example below shows the absolute simplest way to use theRESTfulResponseclass. By default, the RESTfulResponse provides JSON, HTML, and plain text formats. JSON is one of the most popular resource representations (arguably the most popular, at least for APIs being created today) and so theRESTfulResponseclass provides support for it right out of the box. The HTML format is mainly provided to make it easy to view the data in a browser and also to allow theDjango Debug Toolbarto function properly when testing RESTful APIs. The HTML representation will format the data as JSON and, if you havepygmentsinstalled, the data will syntax highlighted as well.To provide a JSON representation of your resource using the RESTfulResponse class, you simply create an instance of it and decorate your resource just like the example shows below:# ====================
# phonebook/views.py
# ====================

from django.http import HttpResponse

from simple_rest import Resource
from simple_rest.auth.decorators import signature_required
from simple_rest.forms import ModelForm
from simple_rest.response import RESTfulResponse

from .models import Contact


def secret_key(request, *args, **kwargs):
    return 'test'


class ContactForm(ModelForm):
    class Meta:
        model = Contact


@signature_required(secret_key)
class Contacts(Resource):

    @RESTfulResponse()
    def get(self, request, contact_id=None, **kwargs):
        if contact_id:
            contacts = Contact.objects.filter(pk=contact_id)
        else:
            contacts = Contact.objects.all()
        return contacts

    def post(self, request, *args, **kwargs):
        form = ContactForm(request.POST)
        if not form.is_valid():
            return HttpResponse(status=409)
        form.save()
        return HttpResponse(status=201)

    def delete(self, request, contact_id):
        contact = Contact.objects.get(pk=contact_id)
        contact.delete()
        return HttpResponse(status=200)Notice that in thegetmethod above we are no longer returning an HttpResponse object, instead we return theQuerySetof the contacts that matched the GET request. When using content negotiation on your resources, simple serializable python objects are the typical response. If you return an HttpResponse object it will simply bypass the content negotiation and just return the response object as is.In the example above we only decorated thegetmethod, but an instance of RESTfulResponse works just as the authentication decorators we saw earlier in that they can be used to decorate methods or full classes. In the next example we decorate the entire resource and, though we can continue to return an HttpResponse object, if we want all of our methods to enjoy the benefits provided by the RESTfulResponse decorator, we need to change what they return from an HttpResponse object to a serializable python object. The code below shows how you can do that for the simple example we saw above:# ====================
# phonebook/views.py
# ====================

from django.http import HttpResponse

from simple_rest import Resource
from simple_rest.auth.decorators import signature_required
from simple_rest.forms import ModelForm
from simple_rest.response import RESTfulResponse

from .models import Contact


def secret_key(request, *args, **kwargs):
    return 'test'


class ContactForm(ModelForm):
    class Meta:
        model = Contact


@RESTfulResponse()
@signature_required(secret_key)
class Contacts(Resource):

    def get(self, request, contact_id=None, **kwargs):
        if contact_id:
            contacts = Contact.objects.filter(pk=contact_id)
        else:
            contacts = Contact.objects.all()
        return contacts

    def post(self, request, *args, **kwargs):
        form = ContactForm(request.POST)
        if not form.is_valid():
            return HttpResponse(status=409)
        form.save()
        return None, 201

    def delete(self, request, contact_id):
        contact = Contact.objects.get(pk=contact_id)
        contact.delete()
        return None, 200One thing to notice in the code above is that thepostmethod returns a tuple. That’s because when we use theRESTfulResponsedecorator it’s expected that we are returning a tuple the first element of which is the object to be serialized and returned to the client. The second (optional) element of the response tuple is the status code of the response. If only a serializable object is returned (as we’ve done in thegetmethod), the default status code of 200 (OK) is used. If, on the other hand, you’d like to return an empty response with just the HTTP Response Code set to signify the success or failure of the operation, you can simply returnNonefor the data object and the desired status code as the second element in the tuple. In thepostmethod in the code sample above we see an example of this. Since performing a POST on our resource creates a new instance of that resource we want to return a 201 (Created) signifying that a new resource was succesfully created and the response body can be empty.Finally, content negotiation doesn’t really do much if you only provide a single representation of your resource. The question then becomes: how do we provide more than just the default JSON representation? The answer is that we pass into theRESTfulResponseconstructor a dict that maps mime types to either a python callable that can be called on the data object to transform it into the designated representation or a string that points to a template that will be used to produce the desired representation. In this example we’ll be using a template to transform the resource into an XML representation.The first step is to create our XML template. Create a new folder in the phonebook application’s directory calledtemplatesand add a file calledphonebook.xmlto it. Make sure that thedjango.template.loaders.app_directories.Loaderline is included, and uncommented, in theTEMPLATE_LOADERStuple insimple_rest_example/settings.py. This will ensure that Django will pick up templates within the apps that you’ve registered in theINSTALLED_APPStuple.Now we just need to add some XML/code to turn our response data into proper XML. TheRESTfulResponsedecorator will automatically provide any data returned from the resource to the template under the namecontext. In the exmaple code below we sort the contacts in thecontextvariable according to last name and return a contact element that has fname, lname, phone_number, and title subelements:<?xml version="1.0"?>
{% with contacts=context.values|dictsort:"lname" %}
<phonebook>
  {% for contact in contacts %}
      <contact>
        <fname>{{ contact.fname }}</fname>
        <lname>{{ contact.lname }}</lname>
        <phone_number>{{ contact.phone_number }}</phone_number>
        <title>{{ contact.title }}</title>
      </contact>
  {% endfor %}
</phonebook>
{% endwith %}Once we’ve got the template created, we just need to create a new RESTfulResponse decorator with the correct mime type mapped to the template. The code below shows how to do that by passing a dictionary that maps supported mimetypes to either a function or a template filename. The RESTFulResponse class also inherits from thecollections.MutableMappingAbstract Base Class, so you could have just as easily added the mimetype to function/template mapping like you would with any ordinary python dict. Also keep in mind that JSON, HTML, and plain text are provided by default, so our mime type mapping dict doesn’t need to contain an entry for any of those—unless you want to override the default behavior:# ====================
# phonebook/views.py
# ====================

from django.http import HttpResponse

from simple_rest import Resource
from simple_rest.auth.decorators import signature_required
from simple_rest.forms import ModelForm
from simple_rest.response import RESTfulResponse

from .models import Contact


def secret_key(request, *args, **kwargs):
    return 'test'

json_or_xml = RESTfulResponse({'application/xml': 'phonebook.xml'})
# Since RESTfulResponse inherits from collections.MutableMapping, we could
# have also done the following instead of passing a dict to the constructor
# json_or_xml = RESTfulResponse()
# json_or_xml['application/xml'] = 'phonebook.xml'


class ContactForm(ModelForm):
    class Meta:
        model = Contact


@json_or_xml
@signature_required(secret_key)
class Contacts(Resource):

    def get(self, request, contact_id=None, **kwargs):
        if contact_id:
            contacts = Contact.objects.filter(pk=contact_id)
        else:
            contacts = Contact.objects.all()
        return contacts

    def post(self, request, *args, **kwargs):
        form = ContactForm(request.POST)
        if not form.is_valid():
            return HttpResponse(status=409)
        form.save()
        return None, 201

    def delete(self, request, contact_id):
        contact = Contact.objects.get(pk=contact_id)
        contact.delete()
        return None, 200With the new changes in place, you can get either XML or JSON just by changing the Accept header in your request. The only problem with this scenario though is that you can’t always simply change the Accept header. For example, a simple HTML form (no JavaScript) will always send a request with Accept headers set to HTML (or XHTML) and probably some form of XML. If you want to specify the format of the response, and you don’t have access to the Accept header, you can either append a file extension to the URL or pass a_formatattribute in the request’s querystring or message body. If either a file extension or an override attribute is used, the response format will be determined using it, otherwise, if neither is present, it will fallback on the Accept header to determine the requested format.Using the_formatoverride attribute is easy, simply add the attribute to the HTTP call in either the querystring or the message body and it just works. there’s absolutely nothing that needs to be done on the backend to get the override attribute working. If, on the other hand, you want to use the file extension override, you will need to alter your URL patterns to accept an optional named pattern. The name you should use for the optional file extenstion is the same as the name for the override attribute. The example below shows the newly alteredphonebook/urls.pyfile with the optional file extension:# ===================
# phonebook/urls.py
# ===================

from django.conf.urls import patterns, include, url

from .views import Contacts

urlpatterns = patterns('',
    # Allow access to the contacts resource collection
    url(r'^contacts(\.(?P<_format>[a-zA-Z]+))?/?$', Contacts.as_view()),

    # # Allow access to a single contact resource
    url(r'^contacts/(?P<contact_id>[0-9]+)(\.(?P<_format>[a-zA-Z]+))?/?$',
        Contacts.as_view()),
)Keep in mind that the example above will be passing a new keyword argument into your view methods, so you’ll need to make sure that the last parameter on your view methods is the catch all parameter for keyword arguments (**kwargs).With the addition above made to the URLconf, you can now request differnt response formats using either a file extension on the URL, a_formatattribute in querystring or message body, or by specifying the desired format in the Accept header. The order of precedence is override attribute, then file extension, and finally the HTTP Accept header.