REST framework 2 docs

djangorestframework/exceptions.py

@@ -7,7 +7,15 @@ In addition Django's built in 403 and 404 exceptions are handled.
 from djangorestframework import status
 
 
-class ParseError(Exception):
+class APIException(Exception):
+    """
+    Base class for REST framework exceptions.
+    Subclasses should provide `.status_code` and `.detail` properties.
+    """
+    pass
+
+
+class ParseError(APIException):
     status_code = status.HTTP_400_BAD_REQUEST
     default_detail = 'Malformed request.'
 
@@ -15,7 +23,7 @@ class ParseError(Exception):
         self.detail = detail or self.default_detail
 
 
-class PermissionDenied(Exception):
+class PermissionDenied(APIException):
     status_code = status.HTTP_403_FORBIDDEN
     default_detail = 'You do not have permission to access this resource.'
 
@@ -23,7 +31,7 @@ class PermissionDenied(Exception):
         self.detail = detail or self.default_detail
 
 
-class MethodNotAllowed(Exception):
+class MethodNotAllowed(APIException):
     status_code = status.HTTP_405_METHOD_NOT_ALLOWED
     default_detail = "Method '%s' not allowed."
 
@@ -31,7 +39,7 @@ class MethodNotAllowed(Exception):
         self.detail = (detail or self.default_detail) % method
 
 
-class UnsupportedMediaType(Exception):
+class UnsupportedMediaType(APIException):
     status_code = status.HTTP_415_UNSUPPORTED_MEDIA_TYPE
     default_detail = "Unsupported media type '%s' in request."
 
@@ -39,16 +47,10 @@ class UnsupportedMediaType(Exception):
         self.detail = (detail or self.default_detail) % media_type
 
 
-class Throttled(Exception):
+class Throttled(APIException):
     status_code = status.HTTP_429_TOO_MANY_REQUESTS
     default_detail = "Request was throttled. Expected available in %d seconds."
 
     def __init__(self, wait, detail=None):
         import math
         self.detail = (detail or self.default_detail) % int(math.ceil(wait))
-
-
-REST_FRAMEWORK_EXCEPTIONS = (
-    ParseError, PermissionDenied, MethodNotAllowed,
-    UnsupportedMediaType, Throttled
-)

djangorestframework/views.py

@@ -226,7 +226,7 @@ class View(DjangoView):
         Handle any exception that occurs, by returning an appropriate response,
         or re-raising the error.
         """
-        if isinstance(exc, exceptions.REST_FRAMEWORK_EXCEPTIONS):
+        if isinstance(exc, exceptions.APIException):
             return Response({'detail': exc.detail}, status=exc.status_code)
         elif isinstance(exc, Http404):
             return Response({'detail': 'Not found'},

docs/api-guide/contentnegotiation.md

@@ -0,0 +1 @@
+> HTTP has provisions for several mechanisms for "content negotiation" -- the process of selecting the best representation for a given response when there are multiple representations available. -- RFC 2616, Fielding et al.

docs/api-guide/exceptions.md

@@ -0,0 +1,3 @@
+# Exceptions
+
+

docs/api-guide/parsers.md

@@ -0,0 +1,3 @@
+# Parsers
+
+## .parse(request)

docs/api-guide/renderers.md

@@ -0,0 +1,4 @@
+# Renderers
+
+## .render(response)
+

docs/api-guide/requests.md

@@ -1,14 +1,12 @@
-Request
+# Requests
-=======
 
 > If you're doing REST-based web service stuff ... you should ignore request.POST.
 >
-> — Malcom Tredinnick, [Django developers group][1]
+> — Malcom Tredinnick, [Django developers group][cite]
 
-The `Request` object in `djangorestframework` extends the standard `HttpRequest`, adding support for parsing multiple content types, allowing browser-based `PUT`, `DELETE` and other methods, and adding flexible per-request authentication.
+REST framework's `Request` class extends the standard `HttpRequest`, adding support for parsing multiple content types, allowing browser-based `PUT`, `DELETE` and other methods, and adding flexible per-request authentication.
 
-method
+## .method
-------
 
 `request.method` returns the uppercased string representation of the request's HTTP method.
 
@@ -16,40 +14,34 @@ Browser-based `PUT`, `DELETE` and other requests are supported, and can be made
 
 
 
-content_type
+## .content_type
-------------
 
 `request.content`, returns a string object representing the mimetype of the HTTP request's body, if one exists.
 
 
 
-DATA
+## .DATA
-----
 
 `request.DATA` returns the parsed content of the request body.  This is similar to the standard `HttpRequest.POST` attribute except that:
 
 1. It supports parsing the content of HTTP methods other than `POST`, meaning that you can access the content of `PUT` and `PATCH` requests.
 2. It supports parsing multiple content types, rather than just form data.  For example you can handle incoming json data in the same way that you handle incoming form data.
 
-FILES
+## .FILES
------
 
 `request.FILES` returns any uploaded files that may be present in the content of the request body.  This is the same as the standard `HttpRequest` behavior, except that the same flexible request parsing that is used for `request.DATA`.
 
 This allows you to support file uploads from multiple content-types.  For example you can write a parser that supports `POST`ing the raw content of a file, instead of using form-encoded file uploads.
 
-user
+## .user
-----
 
 `request.user` returns a `django.contrib.auth.models.User` instance. 
 
-auth
+## .auth
-----
 
 `request.auth` returns any additional authentication context that may not be contained in `request.user`.  The exact behavior of `request.auth` depends on what authentication has been set in `request.authentication`.  For many types of authentication this will simply be `None`, but it may also be an object representing a permission scope, an expiry time, or any other information that might be contained in a token-based authentication scheme.
 
-parsers
+## .parsers
--------
 
 `request.parsers` should be set to a list of `Parser` instances that can be used to parse the content of the request body.
 
@@ -57,15 +49,13 @@ parsers
 
 If you're using the `djangorestframework.views.View` class... **[TODO]**
 
-stream
+## .stream
-------
 
 `request.stream` returns a stream representing the content of the request body.
 
 You will not typically need to access `request.stream`, unless you're writing a `Parser` class.
 
-authentication
+## .authentication
---------------
 
 `request.authentication` should be set to a list of `Authentication` instances that can be used to authenticate the request.
 
@@ -73,4 +63,4 @@ authentication
 
 If you're using the `djangorestframework.views.View` class... **[TODO]**
 
-[1]: https://groups.google.com/d/topic/django-developers/dxI4qVzrBY4/discussion
+[cite]: https://groups.google.com/d/topic/django-developers/dxI4qVzrBY4/discussion

docs/api-guide/responses.md

@@ -0,0 +1,23 @@
+# Responses
+
+> Unlike basic HttpResponse objects, TemplateResponse objects retain the details of the context that was provided by the view to compute the response. The final output of the response is not computed until it is needed, later in the response process.
+>
+> — [Django documentation][cite]
+
+REST framework supports HTTP content negotiation by providing a `Response` class which allows you to return content that can be rendered into multiple content types, depending on the client request.
+
+The `Response` class subclasses Django's `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.
+
+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.
+
+## Response(content, headers=None,  renderers=None, view=None, format=None, status=None)
+
+
+## .renderers
+
+## .view
+
+## .format
+
+
+[cite]: https://docs.djangoproject.com/en/dev/ref/template-response/

docs/api-guide/serializers.md

@@ -0,0 +1,241 @@
+# Serializers
+
+> Expanding the usefulness of the serializers is something that we would
+like to address. However, it's not a trivial problem, and it
+will take some serious design work. Any offers to help out in this
+area would be gratefully accepted.
+>
+> — Russell Keith-Magee, [Django users group][cite]
+
+Serializers allow complex data such as querysets and model instances to be converted to native python datatypes that can then be easily rendered into `JSON`, `XML` or other content types.  Serializers also provide deserialization, allowing parsed data to be converted back into complex types, after first validating the incoming data.
+
+REST framework's serializers work very similarly to Django's `Form` and `ModelForm` classes.  It provides a `Serializer` class which gives you a powerful, generic way to control the output of your responses, as well as a `ModelSerializer` class which provides a useful shortcut for creating serializers that deal with model instances and querysets.
+
+## Declaring Serializers
+
+Let's start by creating a simple object we can use for example purposes:
+
+    class Comment(object):
+        def __init__(self, email, content, created=None):
+            self.email = email
+            self.content = content
+            self.created = created or datetime.datetime.now()
+    
+    comment = Comment(email='leila@example.com', content='foo bar')
+
+We'll declare a serializer that we can use to serialize and deserialize `Comment` objects.
+Declaring a serializer looks very similar to declaring a form:
+
+    class CommentSerializer(serializers.Serializer):
+        email = serializers.EmailField()
+        content = serializers.CharField(max_length=200)
+        created = serializers.DateTimeField()
+
+        def restore_object(self, attrs, instance=None):
+            if instance:
+                instance.title = attrs['title']
+                instance.content = attrs['content']
+                instance.created = attrs['created']
+                return instance
+            return Comment(**attrs) 
+
+The first part of serializer class defines the fields that get serialized/deserialized.  The `restore_object` method defines how fully fledged instances get created when deserializing data.  The `restore_object` method is optional, and is only required if we want our serializer to support deserialization.
+
+## Serializing objects
+
+We can now use `CommentSerializer` to serialize a comment, or list of comments.  Again, using the `Serializer` class looks a lot like using a `Form` class.
+
+    serializer = CommentSerializer(instance=comment)
+    serializer.data
+    # {'email': u'leila@example.com', 'content': u'foo bar', 'created': datetime.datetime(2012, 8, 22, 16, 20, 9, 822774)}
+
+At this point we've translated the model instance into python native datatypes.  To finalise the serialization process we render the data into `json`.
+
+    stream = JSONRenderer().render(data)
+    stream
+    # '{"email": "leila@example.com", "content": "foo bar", "created": "2012-08-22T16:20:09.822"}'
+
+## Deserializing objects
+        
+Deserialization is similar.  First we parse a stream into python native datatypes... 
+
+    data = JSONParser().parse(stream)
+
+...then we restore those native datatypes into a fully populated object instance.
+
+    serializer = CommentSerializer(data)
+    serializer.is_valid()
+    # True
+    serializer.object
+    # <Comment object at 0x10633b2d0>
+    >>> serializer.deserialize('json', stream)
+
+## Validation
+
+When deserializing data, you always need to call `is_valid()` before attempting to access the deserialized object.  If any validation errors occur, the `.errors` and `.non_field_errors` properties will contain the resulting error messages.
+
+**TODO: Describe validation in more depth**
+
+## Dealing with nested objects
+
+The previous example is fine for dealing with objects that only have simple datatypes, but sometimes we also need to be able to represent more complex objects,
+where some of the attributes of an object might not be simple datatypes such as strings, dates or integers.
+
+The `Serializer` class is itself a type of `Field`, and can be used to represent relationships where one object type is nested inside another.
+
+    class UserSerializer(serializers.Serializer):
+        email = serializers.EmailField()
+        username = serializers.CharField()
+        
+        def restore_object(self, attrs, instance=None):
+            return User(**attrs)
+
+
+    class CommentSerializer(serializers.Serializer):
+        user = serializers.UserSerializer()
+        title = serializers.CharField()
+        content = serializers.CharField(max_length=200)
+        created = serializers.DateTimeField()
+        
+        def restore_object(self, attrs, instance=None):
+            return Comment(**attrs)
+
+## Creating custom fields
+
+If you want to create a custom field, you'll probably want to override either one or both of the `.to_native()` and `.from_native()` methods.  These two methods are used to convert between the intial datatype, and a primative, serializable datatype.  Primative datatypes may be any of a number, string, date/time/datetime or None.  They may also be any list or dictionary like object that only contains other primative objects.
+
+The `.to_native()` method is called to convert the initial datatype into a primative, serializable datatype.  The `from_native()` method is called to restore a primative datatype into it's initial representation.
+
+Let's look at an example of serializing a class that represents an RGB color value:
+
+    class Color(object):
+        """
+        A color represented in the RGB colorspace.
+        """
+
+        def __init__(self, red, green, blue):
+            assert(red >= 0 and green >= 0 and blue >= 0)
+            assert(red < 256 and green < 256 and blue < 256)
+            self.red, self.green, self.blue = red, green, blue
+
+    class ColourField(Field):
+        """
+        Color objects are serialized into "rgb(#, #, #)" notation.
+        """
+
+        def to_native(self, obj):
+            return "rgb(%d, %d, %d)" % (obj.red, obj.green, obj.blue)
+      
+        def from_native(self, data):
+            data = data.strip('rgb(').rstrip(')')
+            red, green, blue = [int(col) for col in data.split(',')]
+            return Color(red, green, blue)
+            
+
+By default field values are treated as mapping to an attribute on the object.  If you need to customize how the field value is accessed and set you need to override `.field_to_native()` and/or `.field_from_native()`.
+
+As an example, let's create a field that can be used represent the class name of the object being serialized:
+
+    class ClassNameField(Field):
+        def field_to_native(self, obj, field_name):
+            """
+            Serialize the object's class name, not an attribute of the object.
+            """
+            return obj.__class__.__name__
+
+        def field_from_native(self, data, field_name, into):
+            """
+            We don't want to set anything when we revert this field.
+            """
+            pass
+
+---
+
+# ModelSerializers
+
+Often you'll want serializer classes that map closely to model definitions.
+The `ModelSerializer` class lets you automatically create a Serializer class with fields that corrospond to the Model fields.
+
+    class AccountSerializer(ModelSerializer):
+        class Meta:
+            model = Account
+
+**[TODO: Explain model field to serializer field mapping in more detail]**
+
+## Specifying fields explicitly 
+
+You can add extra fields to a `ModelSerializer` or override the default fields by declaring fields on the class, just as you would for a `Serializer` class.
+
+    class AccountSerializer(ModelSerializer):
+        url = CharField(source='get_absolute_url', readonly=True)
+        group = NaturalKeyField()
+
+        class Meta:
+            model = Account
+
+Extra fields can corrospond to any property or callable on the model.
+
+## Relational fields
+
+When serializing model instances, there are a number of different ways you might choose to represent relationships.  The default representation is to use the primary keys of the related instances.
+
+Alternative representations include serializing using natural keys, serializing complete nested representations, or serializing using a custom representation, such as a URL that uniquely identifies the model instances.
+
+The `PrimaryKeyField` and `NaturalKeyField` fields provide alternative flat representations.
+
+The `ModelSerializer` class can itself be used as a field, in order to serialize relationships using nested representations.
+
+The `RelatedField` class may be subclassed to create a custom represenation of a relationship.  The subclass should override `.to_native()`, and optionally `.from_native()` if deserialization is supported.
+
+All the relational fields may be used for any relationship or reverse relationship on a model.
+
+## Specifying which fields should be included
+
+If you only want a subset of the default fields to be used in a model serializer, you can do so using `fields` or `exclude` options, just as you would with a `ModelForm`.
+
+For example:
+
+    class AccountSerializer(ModelSerializer):
+        class Meta:
+            model = Account
+            exclude = ('id',)
+
+The `fields` and `exclude` options may also be set by passing them to the `serialize()` method.
+
+**[TODO: Possibly only allow .serialize(fields=…) in FixtureSerializer for backwards compatability, but remove for ModelSerializer]**
+
+## Specifiying nested serialization
+
+The default `ModelSerializer` uses primary keys for relationships, but you can also easily generate nested representations using the `nested` option:
+
+    class AccountSerializer(ModelSerializer):
+        class Meta:
+            model = Account
+            exclude = ('id',)
+            nested = True
+
+The `nested` option may be set to either `True`, `False`, or an integer value.  If given an integer value it indicates the depth of relationships that should be traversed before reverting to a flat representation.
+
+When serializing objects using a nested representation any occurances of recursion will be recognised, and will fall back to using a flat representation.
+
+The `nested` option may also be set by passing it to the `serialize()` method.
+
+**[TODO: Possibly only allow .serialize(nested=…) in FixtureSerializer]**
+
+## Customising the default fields used by a ModelSerializer
+
+    class AccountSerializer(ModelSerializer):
+        class Meta:
+            model = Account
+
+        def get_nested_field(self, model_field):
+            return ModelSerializer()
+
+        def get_related_field(self, model_field):
+            return NaturalKeyField()
+
+        def get_field(self, model_field):
+            return Field()
+
+
+[cite]: https://groups.google.com/d/topic/django-users/sVFaOfQi4wY/discussion

docs/api-guide/status-codes.md

@@ -0,0 +1,93 @@
+# Status Codes
+
+> 418 I'm a teapot - Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout.
+>
+> — [RFC 2324][rfc2324], Hyper Text Coffee Pot Control Protocol
+
+Using bare status codes in your responses isn't recommended.  REST framework includes a set of named constants that you can use to make more code more obvious and readable.
+
+    from djangorestframework import status
+
+    def empty_view(self):
+        content = {'please move along': 'nothing to see here'}
+        return Response(content, status=status.HTTP_404_NOT_FOUND)
+
+The full set of HTTP status codes included in the `status` module is listed below.
+
+For more information on proper usage of HTTP status codes see [RFC 2616][rfc2616]
+and [RFC 6585][rfc6585].
+
+## Informational - 1xx
+
+This class of status code indicates a provisional response.  There are no 1xx status codes used in REST framework by default.
+
+    HTTP_100_CONTINUE
+    HTTP_101_SWITCHING_PROTOCOLS
+
+## Successful - 2xx
+
+This class of status code indicates that the client's request was successfully received, understood, and accepted.
+
+    HTTP_200_OK
+    HTTP_201_CREATED
+    HTTP_202_ACCEPTED
+    HTTP_203_NON_AUTHORITATIVE_INFORMATION
+    HTTP_204_NO_CONTENT
+    HTTP_205_RESET_CONTENT
+    HTTP_206_PARTIAL_CONTENT
+
+## Redirection - 3xx 
+
+This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request.
+
+    HTTP_300_MULTIPLE_CHOICES
+    HTTP_301_MOVED_PERMANENTLY
+    HTTP_302_FOUND
+    HTTP_303_SEE_OTHER
+    HTTP_304_NOT_MODIFIED
+    HTTP_305_USE_PROXY
+    HTTP_306_RESERVED
+    HTTP_307_TEMPORARY_REDIRECT
+
+## Client Error - 4xx
+
+The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
+
+    HTTP_400_BAD_REQUEST
+    HTTP_401_UNAUTHORIZED
+    HTTP_402_PAYMENT_REQUIRED
+    HTTP_403_FORBIDDEN
+    HTTP_404_NOT_FOUND
+    HTTP_405_METHOD_NOT_ALLOWED
+    HTTP_406_NOT_ACCEPTABLE
+    HTTP_407_PROXY_AUTHENTICATION_REQUIRED
+    HTTP_408_REQUEST_TIMEOUT
+    HTTP_409_CONFLICT
+    HTTP_410_GONE
+    HTTP_411_LENGTH_REQUIRED
+    HTTP_412_PRECONDITION_FAILED
+    HTTP_413_REQUEST_ENTITY_TOO_LARGE
+    HTTP_414_REQUEST_URI_TOO_LONG
+    HTTP_415_UNSUPPORTED_MEDIA_TYPE
+    HTTP_416_REQUESTED_RANGE_NOT_SATISFIABLE
+    HTTP_417_EXPECTATION_FAILED
+    HTTP_428_PRECONDITION_REQUIRED
+    HTTP_429_TOO_MANY_REQUESTS
+    HTTP_431_REQUEST_HEADER_FIELDS_TOO_LARGE
+
+## Server Error - 5xx
+
+Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
+
+    HTTP_500_INTERNAL_SERVER_ERROR
+    HTTP_501_NOT_IMPLEMENTED
+    HTTP_502_BAD_GATEWAY
+    HTTP_503_SERVICE_UNAVAILABLE
+    HTTP_504_GATEWAY_TIMEOUT
+    HTTP_505_HTTP_VERSION_NOT_SUPPORTED
+    HTTP_511_NETWORD_AUTHENTICATION_REQUIRED
+
+
+[rfc2324]: http://www.ietf.org/rfc/rfc2324.txt
+[rfc2616]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
+[rfc6585]: http://tools.ietf.org/html/rfc6585

docs/api-guide/urls.md

@@ -0,0 +1,41 @@
+# Returning URIs from your Web APIs
+
+> The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components.
+>
+> — Roy Fielding, [Architectural Styles and the Design of Network-based Software Architectures][cite]
+
+As a rule, it's probably better practice to return absolute URIs from you web APIs, such as `http://example.com/foobar`, rather than returning relative URIs, such as `/foobar`.
+
+The advantages of doing so are:
+
+* It's more explicit.
+* It leaves less work for your API clients.
+* There's no ambiguity about the meaning of the string when it's found in representations such as JSON that do not have a native URI type.
+* It allows use to easily do things like markup HTML representations with hyperlinks.
+
+REST framework provides two utility functions to make it more simple to return absolute URIs from your Web API.
+
+There's no requirement for you to use them, but if you do then the self-describing API will be able to automatically hyperlink it's output for you, which makes browsing the API much easier.
+
+## reverse(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.
+
+    from djangorestframework.utils import reverse
+    from djangorestframework.views import APIView
+   
+	class MyView(APIView):
+	    def get(self, request):
+			content = {
+ 				...
+    		    'url': reverse('year-summary', request, args=[1945])
+            }
+    		return Response(content)
+
+## 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.
+
+[cite]: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_5
+[reverse]: https://docs.djangoproject.com/en/dev/topics/http/urls/#reverse
+[reverse-lazy]: https://docs.djangoproject.com/en/dev/topics/http/urls/#reverse-lazy

docs/api-guide/views.md

@@ -0,0 +1,39 @@
+> Django's class based views are a welcome departure from the old-style views.
+>
+> — [Reinout van Rees][cite]
+
+# Views
+
+REST framework provides a simple `APIView` class, built on Django's `django.generics.views.View`.  The `APIView` class ensures five main things:
+
+1. Any requests inside the view will become `Request` instances.
+2. `Request` instances will have their `renderers` and `authentication` attributes automatically set. 
+3. `Response` instances will have their `parsers` and `serializer` attributes automatically set.
+4. `APIException` exceptions will be caught and return appropriate responses.
+5. Any permissions provided will be checked prior to passing the request to a handler method.
+
+Additionally there are a some minor extras, such as providing a default `options` handler, setting some common headers on the response prior to return, and providing the useful `initial()` and `final()` hooks.
+
+## APIView
+
+## Method handlers
+
+Describe that APIView handles regular .get(), .post(), .put(), .delete() etc...
+
+## .initial(request, *args, **kwargs)
+
+## .final(request, response, *args, **kwargs)
+
+## .parsers
+
+## .renderers
+
+## .serializer
+
+## .authentication
+
+## .permissions
+
+## .headers
+
+[cite]: http://reinout.vanrees.org/weblog/2011/08/24/class-based-views-usage.html

docs/csrf.md

@@ -1,4 +0,0 @@
-REST framework and CSRF protection
-==================================
-
-> "Take a close look at possible CSRF / XSRF vulnerabilities on your own websites. They're the worst kind of vulnerability -- very easy to exploit by attackers, yet not so intuitively easy to understand for software developers, at least until you've been bitten by one." - Jeff Atwood

docs/index.md

@@ -1,10 +1,62 @@
-Quickstart
+# Django REST framework
-==========
+
+**A toolkit for building well-connected, self-describing Web APIs.**
+
+**WARNING: This documentation is for the 2.0 redesign of REST framework.  It is a work in progress.**
+
+Django REST framework is a lightweight library that makes it easy to build Web APIs.  It is designed as a modular and easy to customize architecture, based on Django's class based views.
+
+Web APIs built using REST framework are fully self-describing and web browseable - a huge useability win for your developers.  It also supports a wide range of media types, authentication and permission policies out of the box.
+
+## Requirements
+
+REST framework requires the following:
+
+* Python (2.6, 2.7)
+* Django (1.3, 1.4, 1.5)
+* [URLObject][urlobject] (2.0.0+)
+
+The following packages are optional:
+
+* [Markdown][markdown] (2.1.0+) - Markdown support for the self describing API.
+* [PyYAML][yaml] (3.10+) - YAML content type support.
+
+If you're installing using `pip`, all requirements and optional packages will be installed by default.
+
+## Installation
+
+**WARNING: These instructions will only become valid once this becomes the master version**
+
+Install using `pip`...
+
+    pip install djangorestframework
+
+...or clone the project from github.
+
+    git clone git@github.com:tomchristie/django-rest-framework.git
+    pip install -r requirements.txt
+
+Add `djangorestframework` to your `INSTALLED_APPS`.
+
+    INSTALLED_APPS = (
+        ...
+        'djangorestframework',        
+    )
+
+If you're intending to use the browserable API you'll want to add REST framework's login and logout views.  Add the following to your root `urls.py` file.
+
+    urlpatterns = patterns('',
+        ...
+        url(r'^auth', include('djangorestframework.urls', namespace='djangorestframework'))
+    )
+ 
+## Quickstart
 
 **TODO**
 
-Tutorial
+## Tutorial
-========
+
+The tutorial will walk you through the building blocks that make up REST framework.   It'll take a little while to get through, but it'll give you a comprehensive understanding of how everything fits together, and is highly recommended reading.
 
 * [1 - Serialization][tut-1]
 * [2 - Requests & Responses][tut-2]
@@ -13,8 +65,9 @@ Tutorial
 * [5 - Relationships & hyperlinked APIs][tut-5]
 * [6 - Resource orientated projects][tut-6]
 
-API Guide
+## API Guide
-=========
+
+The API guide is your complete reference manual to all the functionality provided by REST framework.
 
 * [Requests][request]
 * [Responses][response]
@@ -24,21 +77,45 @@ API Guide
 * [Serializers][serializers]
 * [Authentication][authentication]
 * [Permissions][permissions]
+* [Exceptions][exceptions]
 * [Status codes][status]
-
-Topics
-======
-
 * [Returning URLs][urls]
+
+## Topics
+
+General guides to using REST framework.
+
 * [CSRF][csrf]
 * [Form overloading][formoverloading]
 
-Other
+## License
-=====
 
-* Why REST framework
+Copyright (c) 2011-2012, Tom Christie
-* Contributing
+All rights reserved.
-* Change Log
+
+Redistribution and use in source and binary forms, with or without 
+modification, are permitted provided that the following conditions are met:
+
+Redistributions of source code must retain the above copyright notice, this 
+list of conditions and the following disclaimer.
+Redistributions in binary form must reproduce the above copyright notice, this 
+list of conditions and the following disclaimer in the documentation and/or 
+other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND 
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE 
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 
+OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+[urlobject]: https://github.com/zacharyvoase/urlobject
+[markdown]: http://pypi.python.org/pypi/Markdown/
+[yaml]: http://pypi.python.org/pypi/PyYAML
 
 [tut-1]: tutorial/1-serialization.md
 [tut-2]: tutorial/2-requests-and-responses.md
@@ -47,16 +124,17 @@ Other
 [tut-5]: tutorial/5-relationships-and-hyperlinked-apis.md
 [tut-6]: tutorial/6-resource-orientated-projects.md
 
-[request]: request.md
+[request]: api-guide/requests.md
-[response]: response.md
+[response]: api-guide/responses.md
-[views]: views.md
+[views]: api-guide/views.md
-[parsers]: parsers.md
+[parsers]: api-guide/parsers.md
-[renderers]: renderers.md
+[renderers]: api-guide/renderers.md
-[serializers]: serializers.md
+[serializers]: api-guide/serializers.md
-[authentication]: authentication.md
+[authentication]: api-guide/authentication.md
-[permissions]: permissions.md
+[permissions]: api-guide/permissions.md
-[status]: status.md
+[exceptions]: api-guide/exceptions.md
+[status]: api-guide/status.md
+[urls]: api-guide/urls.md
 
-[urls]: urls.md
+[csrf]: topics/csrf.md
-[csrf]: csrf.md
+[formoverloading]: topics/formoverloading.md
-[formoverloading]: formoverloading.md

docs/mkdocs.py

@@ -0,0 +1,56 @@
+#!/usr/bin/env python
+
+import markdown
+import os
+import re
+
+root = os.path.dirname(__file__)
+local = True
+
+if local:
+    base_url = 'file://%s/html/' % os.path.normpath(os.path.join(os.getcwd(), root))
+    suffix = '.html'
+    index = 'index.html'
+else:
+    base_url = 'http://tomchristie.github.com/restframeworkdocs/'
+    suffix = ''
+    index = ''
+
+
+main_header = '<li class="main"><a href="#{{ anchor }}">{{ title }}</a></li>'
+sub_header = '<li><a href="#{{ anchor }}">{{ title }}</a></li>'
+
+page = open(os.path.join(root, 'template.html'), 'r').read()
+
+for (dirpath, dirnames, filenames) in os.walk(root):
+    for filename in filenames:
+        if not filename.endswith('.md'):
+            continue
+
+        toc = ''
+        text = open(os.path.join(dirpath, filename), 'r').read().decode('utf-8')
+        for line in text.splitlines():
+            if line.startswith('# '):
+                title = line[2:].strip()
+                template = main_header
+            elif line.startswith('## '):
+                title = line[3:].strip()
+                template = sub_header
+            else:
+                continue
+
+            anchor = title.lower().replace(' ', '-').replace(':-', '-').replace("'", '').replace('?', '').replace('.', '')
+            template = template.replace('{{ title }}', title)
+            template = template.replace('{{ anchor }}', anchor)
+            toc += template + '\n'
+
+        content = markdown.markdown(text, ['headerid'])
+
+        build_dir = os.path.join(root, 'html', dirpath)
+        build_file = os.path.join(build_dir, filename[:-3] + '.html')
+
+        if not os.path.exists(build_dir):
+            os.makedirs(build_dir)
+        output = page.replace('{{ content }}', content).replace('{{ toc }}', toc).replace('{{ base_url }}', base_url).replace('{{ suffix }}', suffix).replace('{{ index }}', index)
+        output = re.sub(r'a href="([^"]*)\.md"', r'a href="\1.html"', output)
+        open(build_file, 'w').write(output.encode('utf-8'))

docs/parsers.md

@@ -1,5 +0,0 @@
-Parsers
-=======
-
-.parse(request)
----------------

docs/renderers.md

@@ -1,6 +0,0 @@
-Renderers
-=========
-
-.render(response)
------------------
-

docs/response.md

@@ -1,27 +0,0 @@
-Responses
-=========
-
-> HTTP has provisions for several mechanisms for "content negotiation" -- the process of selecting the best representation for a given response when there are multiple representations available. -- RFC 2616, Fielding et al.
-
-> Unlike basic HttpResponse objects, TemplateResponse objects retain the details of the context that was provided by the view to compute the response. The final output of the response is not computed until it is needed, later in the response process. -- Django documentation.
-
-Django 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`.  It works by allowing you to specify a serializer and a number of different renderers.  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.
-
-Response(content, status, headers=None, serializer=None, renderers=None, format=None)
--------------------------------------------------------------------------------------
-
-serializer
-----------
-
-renderers
----------
-
-view
-----
-
-ImmediateResponse(...)
-----------------------

docs/serializers.md

@@ -1,47 +0,0 @@
-Serializers
-===========
-
-> Expanding the usefulness of the serializers is something that we would
-like to address. However, it's not a trivial problem, and it
-will take some serious design work. Any offers to help out in this
-area would be gratefully accepted.
- - Russell Keith-Magee, [Django users group][1]
-
-Serializers provide a way of filtering the content of responses, prior to the response being rendered.
-
-They also allow us to use complex data such as querysets and model instances for the content of our responses, and convert that data into native python datatypes that can then be easily rendered into `JSON`, `XML` or whatever.
-
-REST framework includes a default `Serializer` class which gives you a powerful, generic way to control the output of your responses, but you can also write custom serializers for your data, or create other generic serialization strategies to suit the needs of your API.
-
-BaseSerializer
---------------
-
-This is the base class for all serializers.  If you want to provide your own custom serialization, override this class.
-
-.serialize()
-------------
-
-Serializer
-----------
-
-This is the default serializer.
-
-fields
-------
-
-include
--------
-
-exclude
--------
-
-rename
-------
-
-related_serializer
-------------------
-
-depth
------
-
-[1]: https://groups.google.com/d/topic/django-users/sVFaOfQi4wY/discussion

docs/status.md

@@ -1,17 +0,0 @@
-Status Codes
-============
-
-> 418 I'm a teapot - Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout.
- - RFC 2324
-
-REST framework provides a ...
-These are simply ...
-
-    from djangorestframework import status
-
-    def view(self):
-        return Response(status=status.HTTP_404_NOT_FOUND)
-
-For more information see [RFC 2616](1).
-
-[1]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

docs/template.html

@@ -0,0 +1,150 @@
+<!DOCTYPE html>
+<html lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    <meta charset="utf-8">
+    <title>Django REST framework</title>
+    <meta name="viewport" content="width=device-width, initial-scale=1.0">
+    <meta name="description" content="">
+    <meta name="author" content="">
+
+    <!-- Le styles -->
+    <link href="{{ base_url }}/css/bootstrap.css" rel="stylesheet">
+    <style type="text/css">
+      body {
+        padding-top: 60px;
+        padding-bottom: 40px;
+      }
+      .sidebar-nav {
+        padding: 9px 0;
+      }
+      .nav-list li.main {
+        font-weight: bold;
+      }
+      blockquote {
+font-family: Georgia, serif;
+font-size: 18px;
+font-style: italic;
+margin: 0.25em 0;
+padding: 0.25em 40px;
+line-height: 1.45;
+position: relative;
+color: #383838;
+border-left: none;
+}
+
+blockquote:before {
+display: block;
+content: "\201C";
+font-size: 80px;
+position: absolute;
+left: -10px;
+top: -20px;
+color: #7a7a7a;
+}
+
+blockquote p:last-child {
+color: #999999;
+font-size: 14px;
+display: block;
+margin-top: 5px;
+}
+    </style>
+    <link href="{{ base_url }}/css/bootstrap-responsive.css" rel="stylesheet">
+
+    <!-- Le HTML5 shim, for IE6-8 support of HTML5 elements -->
+    <!--[if lt IE 9]>
+      <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
+    <![endif]-->
+  <body>
+
+    <div class="navbar navbar-inverse navbar-fixed-top">
+      <div class="navbar-inner">
+        <div class="container-fluid">
+          <a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse">
+            <span class="icon-bar"></span>
+            <span class="icon-bar"></span>
+            <span class="icon-bar"></span>
+          </a>
+          <a class="brand" href="{{ base_url }}{{ index }}">Django REST framework</a>
+          <div class="nav-collapse collapse">
+            <ul class="nav">
+              <li><a href="{{ base_url }}{{ index }}">Home</a></li>
+              <li class="dropdown">
+                <a href="#" class="dropdown-toggle" data-toggle="dropdown">Tutorial <b class="caret"></b></a>
+                <ul class="dropdown-menu">
+                  <li><a href="{{ base_url }}/tutorial/1-serialization{{ suffix }}">1 - Serialization</a></li>
+                  <li><a href="{{ base_url }}/tutorial/2-requests-and-responses{{ suffix }}">2 - Requests and responses</a></li>
+                  <li><a href="{{ base_url }}/tutorial/3-class-based-views{{ suffix }}">3 - Class based views</a></li>
+                  <li><a href="{{ base_url }}/tutorial/4-authentication-permissions-and-throttling{{ suffix }}">4 - Authentication, permissions and throttling</a></li>
+                  <li><a href="{{ base_url }}/tutorial/5-relationships-and-hyperlinked-apis{{ suffix }}">5 - Relationships and hyperlinked APIs</a></li>
+                  <li><a href="{{ base_url }}/tutorial/6-resource-orientated-projects{{ suffix }}">6 - Resource orientated projects</a></li>
+                </ul>
+              </li>
+              <li class="dropdown">
+                <a href="#" class="dropdown-toggle" data-toggle="dropdown">API Guide <b class="caret"></b></a>
+                <ul class="dropdown-menu">
+                  <li><a href="{{ base_url }}/api-guide/requests{{ suffix }}">Requests</a></li>
+                  <li><a href="{{ base_url }}/api-guide/responses{{ suffix }}">Responses</a></li>
+                  <li><a href="{{ base_url }}/api-guide/views{{ suffix }}">Views</a></li>
+                  <li><a href="{{ base_url }}/api-guide/parsers{{ suffix }}">Parsers</a></li>
+                  <li><a href="{{ base_url }}/api-guide/renderers{{ suffix }}">Renderers</a></li>
+                  <li><a href="{{ base_url }}/api-guide/serializers{{ suffix }}">Serializers</a></li>
+                  <li><a href="{{ base_url }}/api-guide/fields{{ suffix }}">Serializer fields</a></li>
+                  <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/exceptions{{ suffix }}">Exceptions</a></li>
+                  <li><a href="{{ base_url }}/api-guide/status-codes{{ suffix }}">Status codes</a></li>
+                  <li><a href="{{ base_url }}/api-guide/urls{{ suffix }}">Returning URLs</a></li>
+                </ul>
+              </li>
+              <li class="dropdown">
+                <a href="#" class="dropdown-toggle" data-toggle="dropdown">Topics <b class="caret"></b></a>
+                <ul class="dropdown-menu">
+                  <li><a href="{{ base_url }}/topics/csrf{{ suffix }}">Working with AJAX and CSRF</a></li>
+                  <li><a href="{{ base_url }}/topics/formoverloading{{ suffix }}">Browser based PUT, PATCH and DELETE</a></li>
+                </ul>
+              </li>
+            </ul>
+            <ul class="nav pull-right">
+                      <li class="dropdown">
+                        <a href="#" class="dropdown-toggle" data-toggle="dropdown">Version: 2.0.0 <b class="caret"></b></a>
+                        <ul class="dropdown-menu">
+                          <li><a href="#">Trunk</a></li>
+                          <li><a href="#">2.0.0</a></li>
+                        </ul>
+                      </li>
+                    </ul>
+          </div><!--/.nav-collapse -->
+        </div>
+      </div>
+    </div>
+
+    <div class="container-fluid">
+      <div class="row-fluid">
+          <div class="span3">
+            <div class="well affix span3">
+              <ul class="nav nav-list side-nav">
+{{ toc }}
+              </ul>
+            </div>
+        </div>
+
+        <div class="span9">
+{{ content }}
+        </div><!--/span-->
+      </div><!--/row-->
+    </div><!--/.fluid-container-->
+
+    <!-- Le javascript
+    ================================================== -->
+    <!-- Placed at the end of the document so the pages load faster -->
+    <script src="{{ base_url }}/js/jquery.js"></script>
+    <script src="{{ base_url }}/js/bootstrap-dropdown.js"></script>
+    <script src="{{ base_url }}/js/bootstrap-scrollspy.js"></script>
+    <script>
+    //$('.side-nav').scrollspy()
+    var shiftWindow = function() { scrollBy(0, -50) };
+    if (location.hash) shiftWindow();
+    window.addEventListener("hashchange", shiftWindow);
+    </script>
+</body></html>

docs/topics/csrf.md

@@ -0,0 +1,12 @@
+# Working with AJAX and CSRF
+
+> "Take a close look at possible CSRF / XSRF vulnerabilities on your own websites. They're the worst kind of vulnerability -- very easy to exploit by attackers, yet not so intuitively easy to understand for software developers, at least until you've been bitten by one."
+>
+>  — [Jeff Atwood][cite]
+
+* Explain need to add CSRF token to AJAX requests.
+* Explain defered CSRF style used by REST framework
+* Why you should use Django's standard login/logout views, and not REST framework view
+
+
+[cite]: http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html

docs/topics/formoverloading.md

@@ -1,12 +1,12 @@
-Supporting browser-based PUT & DELETE
+# Browser based PUT & DELETE
-=====================================
 
-> "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" - [RESTful Web Services](1), Leonard Richardson & Sam Ruby.
+> "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"
+>
+> — [RESTful Web Services](1), Leonard Richardson & Sam Ruby.
 
-This is the same strategy as is used in [Ruby on Rails](2).
+## Overloading the HTTP method
 
-Overloading the HTTP method
+**TODO: Preamble.**  Note that this is the same strategy as is used in [Ruby on Rails](2).
----------------------------
 
 For example, given the following form:
 
@@ -16,8 +16,7 @@ For example, given the following form:
 
 `request.method` would return `"DELETE"`.
 
-Overloading the HTTP content type
+## Overloading the HTTP content type
----------------------------------
 
 Browser-based submission of content types other than form are supported by using form fields named `_content` and `_content_type`:
 
@@ -30,13 +29,11 @@ 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? 
+## Why not just use Javascript? 
-============================
 
 **[TODO]**
 
-Doesn't HTML5 support PUT and DELETE forms?
+## 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.
 

docs/urls.md

@@ -1,42 +0,0 @@
-Returning URIs from your Web APIs
-=================================
-
-> The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components.
-> -- <cite>Roy Fielding, Architectural Styles and the Design of Network-based Software Architectures.</cite>
-
-As a rule, it's probably better practice to return absolute URIs from you web APIs, eg. "http://example.com/foobar", rather than returning relative URIs, eg. "/foobar".
-
-The advantages of doing so are:
-
-* It's more explicit.
-* It leaves less work for your API clients.
-* There's no ambiguity about the meaning of the string when it's found in representations such as JSON that do not have a native URI type.
-* It allows use to easily do things like markup HTML representations with hyperlinks.
-
-Django REST framework provides two utility functions to make it more simple to return absolute URIs from your Web API.
-
-There's no requirement for you to use them, but if you do then the self-describing API will be able to automatically hyperlink it's output for you, which makes browsing the API much easier.
-
-reverse(viewname, request, ...)
--------------------------------
-
-Has the same behavior as [`django.core.urlresolvers.reverse`](1), except that it returns a fully qualified URL, using the request to determine the host and port.
-
-    from djangorestframework.utils import reverse
-    from djangorestframework.views import View
-   
-	class MyView(View):
-	    def get(self, request):
-			context = {
- 				...
-    		    'url': reverse('year-summary', request, args=[1945])
-            }
-    		return Response(context)
-
-reverse_lazy(viewname, request, ...)
-------------------------------------
-
-Has the same behavior as [`django.core.urlresolvers.reverse_lazy`](2), except that it returns a fully qualified URL, using the request to determine the host and port.
-
-[1]: https://docs.djangoproject.com/en/dev/topics/http/urls/#reverse
-[1]: https://docs.djangoproject.com/en/dev/topics/http/urls/#reverse-lazy

docs/views.md

@@ -1,43 +0,0 @@
-Views
-=====
-
-REST framework provides a simple `View` class, built on Django's `django.generics.views.View`.  The `View` class ensures five main things:
-
-1. Any requests inside the view will become `Request` instances.
-2. `Request` instances will have their `renderers` and `authentication` attributes automatically set. 
-3. `Response` instances will have their `parsers` and `serializer` attributes automatically set.
-4. `ImmediateResponse` exceptions will be caught and returned as regular responses.
-5. Any permissions provided will be checked prior to passing the request to a handler method.
-
-Additionally there are a some minor extras, such as providing a default `options` handler, setting some common headers on the response prior to return, and providing the useful `initial()` and `final()` hooks.
-
-View
-----
-
-.get(), .post(), .put(), .delete() etc...
------------------------------------------
-
-.initial(request, *args, **kwargs)
-----------------------------------
-
-.final(request, response, *args, **kwargs)
-------------------------------------------
-
-.parsers
---------
-
-.renderers
-----------
-
-.serializer
------------
-
-.authentication
----------------
-
-.permissions
-------------
-
-.headers
---------
-