Web APIs for Django. 🎸

Overview

Django REST framework

build-status-image coverage-status-image pypi-version

Awesome web-browsable Web APIs.

Full documentation for the project is available at https://www.django-rest-framework.org/.


Funding

REST framework is a collaboratively funded project. If you use REST framework commercially we strongly encourage you to invest in its continued development by signing up for a paid plan.

The initial aim is to provide a single full-time position on REST framework. Every single sign-up makes a significant impact towards making that possible.

Many thanks to all our wonderful sponsors, and in particular to our premium backers, Sentry, Stream, Rollbar, ESG, Retool, and bit.io.


Overview

Django REST framework is a powerful and flexible toolkit for building Web APIs.

Some reasons you might want to use REST framework:

There is a live example API for testing purposes, available here.

Below: Screenshot from the browsable API

Screenshot


Requirements

  • Python (3.5, 3.6, 3.7, 3.8, 3.9)
  • Django (2.2, 3.0, 3.1)

We highly recommend and only officially support the latest patch release of each Python and Django series.

Installation

Install using pip...

pip install djangorestframework

Add 'rest_framework' to your INSTALLED_APPS setting.

INSTALLED_APPS = [
    ...
    'rest_framework',
]

Example

Let's take a look at a quick example of using REST framework to build a simple model-backed API for accessing users and groups.

Startup up a new project like so...

pip install django
pip install djangorestframework
django-admin startproject example .
./manage.py migrate
./manage.py createsuperuser

Now edit the example/urls.py module in your project:

from django.urls import path, include
from django.contrib.auth.models import User
from rest_framework import serializers, viewsets, routers

# Serializers define the API representation.
class UserSerializer(serializers.HyperlinkedModelSerializer):
    class Meta:
        model = User
        fields = ['url', 'username', 'email', 'is_staff']


# ViewSets define the view behavior.
class UserViewSet(viewsets.ModelViewSet):
    queryset = User.objects.all()
    serializer_class = UserSerializer


# Routers provide a way of automatically determining the URL conf.
router = routers.DefaultRouter()
router.register(r'users', UserViewSet)


# Wire up our API using automatic URL routing.
# Additionally, we include login URLs for the browsable API.
urlpatterns = [
    path('', include(router.urls)),
    path('api-auth/', include('rest_framework.urls', namespace='rest_framework')),
]

We'd also like to configure a couple of settings for our API.

Add the following to your settings.py module:

INSTALLED_APPS = [
    ...  # Make sure to include the default installed apps here.
    'rest_framework',
]

REST_FRAMEWORK = {
    # Use Django's standard `django.contrib.auth` permissions,
    # or allow read-only access for unauthenticated users.
    'DEFAULT_PERMISSION_CLASSES': [
        'rest_framework.permissions.DjangoModelPermissionsOrAnonReadOnly',
    ]
}

That's it, we're done!

./manage.py runserver

You can now open the API in your browser at http://127.0.0.1:8000/, and view your new 'users' API. If you use the Login control in the top right corner you'll also be able to add, create and delete users from the system.

You can also interact with the API using command line tools such as curl. For example, to list the users endpoint:

$ curl -H 'Accept: application/json; indent=4' -u admin:password http://127.0.0.1:8000/users/
[
    {
        "url": "http://127.0.0.1:8000/users/1/",
        "username": "admin",
        "email": "[email protected]",
        "is_staff": true,
    }
]

Or to create a new user:

$ curl -X POST -d username=new -d [email protected] -d is_staff=false -H 'Accept: application/json; indent=4' -u admin:password http://127.0.0.1:8000/users/
{
    "url": "http://127.0.0.1:8000/users/2/",
    "username": "new",
    "email": "[email protected]",
    "is_staff": false,
}

Documentation & Support

Full documentation for the project is available at https://www.django-rest-framework.org/.

For questions and support, use the REST framework discussion group, or #restframework on freenode IRC.

You may also want to follow the author on Twitter.

Security

Please see the security policy.

Comments
  • PUT calls don't fully

    PUT calls don't fully "replace the state of the target resource"

    EDIT: For the current status of the issue, skip to https://github.com/encode/django-rest-framework/issues/4231#issuecomment-332935943

    ===

    I'm having an issue implementing an Optimistic Concurrency library on an application that uses DRF to interact with the database. I'm trying to:

    • Confirm that the behavior I'm seeing is attributable to DRF
    • Confirm that this is the intended behavior
    • Determine if there's any practical way to overcome this behavior

    I recently added optimistic concurrency to my Django application. To save you the Wiki lookup:

    • Every model has a version field
    • When an editor edits an object, they get the version of the object they're editing
    • When the editor saves the object, the included version number is compared to the database
    • If the versions match, the editor updated the latest document and the save goes through
    • If the versions don't match, we assume a "conflicting" edit was submitted between the time the editor loaded and saved so we reject the edit
    • If the version is missing, we cannot do testing and should reject the edit

    I had a legacy UI talking through DRF. The legacy UI did not handle version numbers. I expected this to cause concurrency errors, but it did not. If I understand the discussion in #3648 correctly:

    • DRF merges the PUT with the existing record. This causes a missing version ID to be filled with the current database ID
    • Since this always provides a match, omitting this variable will always break an optimistic concurrency system that communicates across DRF
    • ~There are no easy options (like making the field "required") to ensure the data is submitted every time.~ (edit: you can workaround the issue by making it required as demonstrated in this comment)

    Steps to reproduce

    1. Setup an Optimistic Concurrency field on a model
    2. Create a new instance and update several times (to ensure you no longer have a default version number)
    3. Submit an update (PUT) through DRF excluding the version ID

    Expected behavior

    The missing version ID should not match the database and cause a concurrency issue.

    Actual behavior

    The missing version ID is filled by DRF with the current ID so the concurrency check passes.

    Enhancement 
    opened by claytondaley 68
  • Introduce error code for validation errors.

    Introduce error code for validation errors.

    This patch is meant to fix #3111, regarding comments made to #3137 and #3169.

    The ValidationError will now contain a code attribute.

    Before this patch, ValidationError.detail only contained a dict with values equal to a list of string error messages or directly a list containing string error messages.

    Now, the string error messages are replaced with ValidationError.

    This means that, depending on the case, you will not only get a string back but a full object containing both the error message and the error code, respectively ValidationError.detail and ValidationError.code.

    It is important to note that the code attribute is not relevant when the ValidationError represents a combination of errors and hence is None in such cases.

    The main benefit of this change is that the error message and error code are now accessible in the custom exception handler and can be used to format the error response.

    A custom exception handler example is available in the TestValidationErrorWithCode test.

    Regarding the other discussion:

    • This PR doesn't require any new settings
    • The build_error method was dropped
    • The build_error_from_django_validation_error has been kept because this is the only way to "convert" a regular DjangoValidationError to a djrf ValidationError.

    @tomchristie @jpadilla @qsorix: if you don't mind giving this a look ;-)

    Enhancement 
    opened by johnraz 63
  • Removing _closable_objects for pickling breaks response processing

    Removing _closable_objects for pickling breaks response processing

    Here _closable_objects was added to rendering_attrs https://github.com/tomchristie/django-rest-framework/commit/59d0a0387d907260ef8f91bbbca618831abd75a3#diff-21a03cd19b8422c334c33ec8da66e9c8R21

    Every rendering attribute is deleted in __getstate__ method https://github.com/django/django/blob/1.7/django/template/response.py#L45

    But _closable_objects is used in base response handler: https://github.com/django/django/blob/1.7/django/core/handlers/base.py#L210

    That's why after processing response from cache i get error like this:

    Traceback (most recent call last):
      File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/wsgiref/handlers.py", line 85, in run
        self.result = application(self.environ, self.start_response)
      File "/Users/web-chib/drf-ussie/lib/python2.7/site-packages/django/contrib/staticfiles/handlers.py", line 64, in __call__
        return self.application(environ, start_response)
      File "/Users/web-chib/drf-ussie/lib/python2.7/site-packages/django/core/handlers/wsgi.py", line 187, in __call__
        response = self.get_response(request)
      File "/Users/web-chib/drf-ussie/lib/python2.7/site-packages/django/core/handlers/base.py", line 211, in get_response
        response._closable_objects.append(request)
    AttributeError: 'Response' object has no attribute '_closable_objects'
    

    I don't know, should i recreate this attribute by hand, or that's DRF error?

    Bug 
    opened by chibisov 61
  • Schema generation doesn't support response schemas

    Schema generation doesn't support response schemas

    This is a useful feature, at least for swagger, and the way things are right now it cannot be implemented from outside of DRF, since the Link object doesn't contain the schema for the response.

    While the fields can be implied from the input fields, for read only endpoints this is not an option.

    Enhancement Schema Generation 
    opened by gcbirzan 57
  • Request.data empty when multipart/form-data POSTed

    Request.data empty when multipart/form-data POSTed

    Django==1.9.2 djangorestframework==3.3.2

    This is essentially a repost of #3814. There is already some research and discussion attached to that issue that I will not rehash, but the author closed out the item once a workaround was found.

    Is that workaround the long term solution? Is the answer to never touch the Django Request before DRF has a chance to do its thing? This can be difficult to control in projects with third party middleware.

    The issue seems to be that, when POSTing data, Django is exhausting the underlying request stream if the WSGIRequest is accessed prior to initialize_request in the DRF View dispatcher. PUTs seem to be unaffected.

    A totally contrived example that demonstrates the issue. First example, presuming no middleware Request meddling...

    class TestView(APIView):
    
        def post(self, request, *args, **kwargs):
            # request.data, .FILES, and .POST are populated
            # request._request.FILES and .POST are empty
            return Response()
    
        def put(self, request, *args, **kwargs):
            # request.data, .FILES, and .POST are populated
            # request._request.FILES and .POST are empty
            return Response()
    

    Second example, forcibly evaluating the Django request before dispatching.

    class TestView(APIView):
    
        def dispatch(self, request, *args, **kwargs):
            p = request.POST  # Force evaluation of the Django request
            return super().dispatch(request, *args, **kwargs)
    
        def post(self, request, *args, **kwargs):
            # request.data, .FILES, and .POST are empty
            # request._request.FILES and .POST are populated
            return Response()
    
        def put(self, request, *args, **kwargs):
            # request.data, .FILES, and .POST are populated
            # request._request.FILES and .POST are empty
            return Response()
    

    Cheers!

    Needs confirmation 
    opened by CaffeineFueled 55
  • Support

    Support "extra actions" for routing in the HTML forms for the browsable API

    Add support for creating HTML forms for the browsable API for "extra actions" for routing.

    For example using the example from the linked page:

        @detail_route(methods=['post'])
        def set_password(self, request, pk=None):
    

    creating a form for calling set_password. Likely this would require additional arguments passed to the detail_route decorator (such as the serializer used, PasswordSerializer).

    See: https://groups.google.com/forum/#!topic/django-rest-framework/e75osh1Wcyg

    Enhancement 
    opened by cancan101 40
  • Nested Routers: Allow nested URLs for resources, like /carts/{nested_1_pk}/itens/{pk}

    Nested Routers: Allow nested URLs for resources, like /carts/{nested_1_pk}/itens/{pk}

    I wrote a PoC NestedSimpleRouter, that nests its URLs into some other router routes. Usage:

    # urls.py
    (...)
    router = routers.SimpleRouter()
    router.register(r'carts', CartViewSet)
    
    carts_router = routers.NestedSimpleRouter(router, r'carts')
    carts_router.register(r'itens', ItensViewSet)
    
    url_patterns = patterns('',
        url(r'^', include(router.urls)),
        url(r'^', include(carts_router.urls)),
    )
    

    This creates the following URLs:

    ^carts/$ [name='cart-list']
    ^carts/(?P<pk>[^/]+)/$ [name='cart-detail']
    ^carts/(?P<nested_1_pk>[^/]+)/itens/$ [name='item-list']
    ^carts/(?P<nested_1_pk>[^/]+)/itens/(?P<pk>[^/]+)/$ [name='item-detail']
    

    And is intended to be used like:

    # views.py
    class ItemViewSet(viewsets.ViewSet):
        model = Item
    
        def list(self, request, nested_1_pk=None):
            cart = Cart.objects.get(pk=nested_1_pk)
            return Response([])
    
        def retrieve(self, request, pk=None, nested_1_pk=None):
            (...)
    

    The nested_1_pk is automatic, and should grow to nested_{n}_{lookup_field} as you nest Nested routers, but this will need more work into SimpleRouter.get_lookup_regex() to do it ( and I need some sleep now :P )

    It works very well, but have no tests yet.

    What you think?

    Enhancement 
    opened by alanjds 37
  • Serializers many to many field not reflecting edits made in PUT/PATCH if prefetch_related used

    Serializers many to many field not reflecting edits made in PUT/PATCH if prefetch_related used

    If you use a viewset with a queryset using prefetch_related, any update to those prefetched many to many fields is not reflected in the response to the client, although the changes have been saved to the database.

    See below code for very simple example:

    from django.conf.urls import patterns, include, url
    from django.contrib import admin
    from django.contrib.auth.models import User
    from rest_framework import serializers, viewsets, routers
    
    
    class UserSerializer(serializers.ModelSerializer):
        class Meta:
            model = User
            fields = ('id', 'username', 'email', 'groups')
    
    
    class UserViewSet(viewsets.ModelViewSet):
        queryset = User.objects.all().prefetch_related('groups')
        serializer_class = UserSerializer
    
    
    router = routers.DefaultRouter()
    router.register(r'users', UserViewSet)
    
    urlpatterns = patterns('',
        url(r'^', include(router.urls)),
        url(r'^api-auth/', include('rest_framework.urls',
                                   namespace='rest_framework')),
        url(r'^admin/', include(admin.site.urls)),
    )
    

    With the above code, assume there is an existing user with 2 groups assigned:

    {
        "id": 1, 
        "username": "chris", 
        "email": "[email protected]", 
        "groups": [
            1,
            2
        ]
    }
    

    Submitting a PUT to /users/1/ changing groups to [1], the response will still show groups as [1, 2], but if you then did a GET request for /users/1/ you would see the reflected changes.

    You can see this behaviour using the browseable api also.

    Removing prefetch_related from the queryset restores normal behaviour and edits are again reflected in the response.

    This example is very trivial, but if people are using prefetch_related to try and optimise their database queries they may encounter this issue.

    Bug 
    opened by chrismcband 36
  • Discussion: Async view support

    Discussion: Async view support

    Given Django 3.1's upcoming support for async views, it's worth us talking though if there are useful points of async support in REST framework, and what they would be if so.

    I'm going to prefix this by starting with a bit of expectation setting... Django 3.1's async view support is a really impressive bit of foundational work, but there's currently limitations to where it's actually valuable, given that the ORM isn't yet async-capable.

    One thing that'd be really helpful to this discussion would be concrete use-cases where folks demonstrate an actual use-case where they've used or would use an async view in Django, together with the motivation, and demonstrable improvements vs. sticking with a regular sync view.

    We'd also want to scoping this down to the most minimal possible starting point.

    In particular, what would we need to change in order to support this?...

    @api_view(['GET'])
    async def my_view(request):
        ...
    

    The @api_view decorator is implemented on top of the APIView class based view, so an even more minimal question is: what would we need to change in order to support something like this?...

    class MyView(AsyncAPIView):
        async def get(self, request):
            ...
    

    There's a whole bunch of different things to consider there, eg...

    • The authentication/permissions is likely to be a sync ORM operation at the moment.
    • The throttling is likely to be a sync cache operation at the moment.
    • Does Django support reading the request body as an async operation? How would we need to tie this in with the parsing.

    But let's just put those aside for the moment.

    Django's upcoming docs for 3.1 async views mentions...

    For a class-based view, this means making its __call__() method an async def (not its __init__() or as_view()).

    So here's some even simpler questions:

    • What does a Django 3.1 async CBV look like?
    • What would using REST framework's Request explicitly within a Django async view look like (rather than wrapping with @api_view). What provisos are there on operations on the request instance that are currently sync?
    • What would using REST framework's Response explicitly within a Django async view look like (rather than wrapping with @api_view). Are there any provisos on sync operations there?
    opened by tomchristie 35
  • Serializer DateTimeField has unexpected timezone information

    Serializer DateTimeField has unexpected timezone information

    I have TIME_ZONE = 'Asia/Kolkata' and USE_TZ = True in my settings.

    When I create a new object with the browsable api, the serializer displays the newly created object with datetimes that have a trailing +5:30, indicating the timezone. The database is storing the times in UTC.

    The unexpected behavior is that when the object is serialized again later, the datetimes are all in UTC format with a trailing Z. According to the Django docs on current and default time zone, I would expect the serializer to convert the datetimes to the current time zone, which defaults to the default time zone, which is set by TIME_ZONE = 'Asia/Kolkata'.

    Am I missing something?

    Needs further review 
    opened by jonathan-golorry 34
  • Add compound field types

    Add compound field types

    Implementation for #560

    • ListField, ListOrObjectField, DictField compound field types
    • Also, for BaseSerializer.from_native, give files parameter default of None
    Enhancement 
    opened by estebistec 34
  • Versioning doesn't work with Custom middleware

    Versioning doesn't work with Custom middleware

    I have enabled AcceptHeaderVersioning as the DEFAULT_VERSIONING_CLASS. I have added a custom middleware(added at the last of the MIDDLEWARE list) which looks at request.version value and take actions based on the custom logic. However, I see that request.version is not populated in the middleware and returns the error.

      File "/Users/test/opt/miniconda3/envs/test/lib/python3.9/site-packages/django/core/handlers/base.py", line 171, in _get_response
        response = middleware_method(request, callback, callback_args, callback_kwargs)
      File "/Users/test/work/test1/versioncheck/middleware.py", line 35, in process_view
        print(request.version)
    AttributeError: 'WSGIRequest' object has no attribute 'version'
    

    Checklist

    • [ ] Raised initially as discussion #...
    • [x] This cannot be dealt with as a third party library. (We prefer new functionality to be in the form of third party libraries where possible.)
    • [x] I have reduced the issue to the simplest possible case.
    opened by johnugeorge 0
  • Update docs to maintained `djangorestframework-guardian2`

    Update docs to maintained `djangorestframework-guardian2`

    Description

    djangorestframework-guardian has not had a new release for over 3 years

    • https://pypi.org/project/djangorestframework-guardian/#history

    There are no commits for 2.5 years:

    • https://github.com/rpkilby/django-rest-framework-guardian/commits/master

    The maintainer has not responded to an issue about this for over a year

    • https://github.com/rpkilby/django-rest-framework-guardian/issues/19

    djangorestframework-guardian2 is a friendly fork I created that supports the currently supported Django and Python versions

    • https://pypi.org/project/djangorestframework-guardian2/

    Out of courtesy (not trying to bug the maintainer more), I will CC @rpkilby here in case he would like to contend this (in which case I'll happily allow him to maintain the original package again if he desires).

    opened by johnthagen 1
  • Update documentation regarding arguments of ValidationError

    Update documentation regarding arguments of ValidationError

    The documentation used to state that the detail argument was mandatory, but in fact it currently is not.

    Here is the line that defines the default argument: https://github.com/encode/django-rest-framework/blob/master/rest_framework/exceptions.py#L148

    Documentation 
    opened by totycro 1
  • Fix FilePathField required argument

    Fix FilePathField required argument

    Description

    Following on the discussion in #8804 this PR fixes required argument lost in FilePathField constructor by making sure it is passed to the super().__init__ call with other keyword arguments.

    opened by radekwlsk 5
Releases(3.14.0)
  • 3.14.0(Nov 8, 2022)

    • Django 2.2 is no longer supported. #8662
    • Django 4.1 compatibility. #8591
    • Add --api-version CLI option to generateschema management command. #8663
    • Enforce is_valid(raise_exception=False) as a keyword-only argument. #7952
    • Stop calling set_context on Validators. #8589
    • Return NotImplemented from ErrorDetails.__ne__. #8538
    • Don't evaluate DateTimeField.default_timezone when a custom timezone is set. #8531
    • Make relative URLs clickable in Browseable API. #8464
    • Support ManyRelatedField falling back to the default value when the attribute specified by dot notation doesn't exist. Matches ManyRelatedField.get_attribute to Field.get_attribute. #7574
    • Make schemas.openapi.get_reference public. #7515
    • Make ReturnDict support dict union operators on Python 3.9 and later. #8302
    • Update throttling to check if request.user is set before checking if the user is authenticated. #8370
    Source code(tar.gz)
    Source code(zip)
  • 3.13.1(Nov 8, 2022)

  • 3.13.0(Nov 8, 2022)

    • Django 4.0 compatability. #8178
    • Add max_length and min_length options to ListSerializer. #8165
    • Add get_request_serializer and get_response_serializer hooks to AutoSchema. #7424
    • Fix OpenAPI representation of null-able read only fields. #8116
    • Respect UNICODE_JSON setting in API schema outputs. #7991
    • Fix for RemoteUserAuthentication. #7158
    • Make Field constructors keyword-only. #7632
    Source code(tar.gz)
    Source code(zip)
  • 3.9.3(Apr 29, 2019)

    This is the last Django REST Framework release that will support Python 2. Be sure to upgrade to Python 3 before upgrading to Django REST Framework 3.10.

    • Adjusted the compat check for django-guardian to allow the last guardian version (v1.4.9) compatible with Python 2. #6613
    Source code(tar.gz)
    Source code(zip)
  • 3.9.2(Mar 3, 2019)

  • 3.9.1(Feb 28, 2019)

  • 3.9.0(Feb 28, 2019)

    Release announcement: https://www.django-rest-framework.org/community/3.9-announcement/

    Change Notes: https://www.django-rest-framework.org/community/release-notes/#39x-series

    Source code(tar.gz)
    Source code(zip)
  • 3.8.2(Apr 6, 2018)

    Point release for 3.8.x series

    • Fix read_only + default unique_together validation. #5922
    • authtoken.views import coreapi from rest_framework.compat, not directly. #5921
    • Docs: Add missing argument 'detail' to Route #5920
    Source code(tar.gz)
    Source code(zip)
  • 3.8.1(Apr 4, 2018)

    • Use old url_name behavior in route decorators #5915

      For list_route and detail_route maintain the old behavior of url_name, basing it on the url_path instead of the function name.

    Source code(tar.gz)
    Source code(zip)
  • 3.8.0(Apr 3, 2018)

    • Release Announcement

    • 3.8.0 Milestone

    • Breaking Change: Alter read_only plus default behaviour. #5886

      read_only fields will now always be excluded from writable fields.

      Previously read_only fields with a default value would use the default for create and update operations.

      In order to maintain the old behaviour you may need to pass the value of read_only fields when calling save() in the view:

        def perform_create(self, serializer):
            serializer.save(owner=self.request.user)
      

      Alternatively you may override save() or create() or update() on the serialiser as appropriate.

    • Correct allow_null behaviour when required=False #5888

      Without an explicit default, allow_null implies a default of null for outgoing serialisation. Previously such fields were being skipped when read-only or otherwise not required.

      Possible backwards compatibility break if you were relying on such fields being excluded from the outgoing representation. In order to restore the old behaviour you can override data to exclude the field when None.

      For example:

        @property
        def data(self):
            """
            Drop `maybe_none` field if None.
            """
            data = super().data()
            if 'maybe_none' in data and data['maybe_none'] is None:
                del data['maybe_none']
            return data
      
    • Refactor dynamic route generation and improve viewset action introspectibility. #5705

      ViewSets have been provided with new attributes and methods that allow it to introspect its set of actions and the details of the current action.

      • Merged list_route and detail_route into a single action decorator.
      • Get all extra actions on a ViewSet with .get_extra_actions().
      • Extra actions now set the url_name and url_path on the decorated method.
      • Enable action url reversing through .reverse_action() method (added in 3.7.4)
      • Example reverse call: self.reverse_action(self.custom_action.url_name)
      • Add detail initkwarg to indicate if the current action is operating on a collection or a single instance.

      Additional changes:

      • Deprecated list_route & detail_route in favor of action decorator with detail boolean.
      • Deprecated dynamic list/detail route variants in favor of DynamicRoute with detail boolean.
      • Refactored the router's dynamic route generation.
    • Fix formatting of the 3.7.4 release note #5704

    • Docs: Update DRF Writable Nested Serializers references #5711

    • Docs: Fixed typo in auth URLs example. #5713

    • Improve composite field child errors #5655

    • Disable HTML inputs for dict/list fields #5702

    • Fix typo in HostNameVersioning doc #5709

    • Use rsplit to get module and classname for imports #5712

    • Formalize URLPatternsTestCase #5703

    • Add exception translation test #5700

    • Test staticfiles #5701

    • Add drf-yasg to documentation and schema 3rd party packages #5720

    • Remove unused compat._resolve_model() #5733

    • Drop compat workaround for unsupported Python 3.2 #5734

    • Prefer iter(dict) over iter(dict.keys()) #5736

    • Pass python_requires argument to setuptools #5739

    • Remove unused links from docs #5735

    • Prefer https protocol for links in docs when available #5729

    • Add HStoreField, postgres fields tests #5654

    • Always fully qualify ValidationError in docs #5751

    • Remove unreachable code from ManualSchema #5766

    • Allowed customising API documentation code samples #5752

    • Updated docs to use pip show #5757

    • Load 'static' instead of 'staticfiles' in templates #5773

    • Fixed a typo in fields docs #5783

    • Refer to "NamespaceVersioning" instead of "NamespacedVersioning" in the documentation #5754

    • ErrorDetail: add __eq__/__ne__ and __repr__ #5787

    • Replace background-attachment: fixed in docs #5777

    • Make 404 & 403 responses consistent with exceptions.APIException output #5763

    • Small fix to API documentation: schemas #5796

    • Fix schema generation for PrimaryKeyRelatedField #5764

    • Represent serializer DictField as an Object in schema #5765

    • Added docs example reimplementing ObtainAuthToken #5802

    • Add schema to the ObtainAuthToken view #5676

    • Fix request formdata handling #5800

    • Fix authtoken views imports #5818

    • Update pytest, isort #5815 #5817 #5894

    • Fixed active timezone handling for non ISO8601 datetimes. #5833

    • Made TemplateHTMLRenderer render IntegerField inputs when value is 0. #5834

    • Corrected endpoint in tutorial instructions #5835

    • Add Django Rest Framework Role Filters to Third party packages #5809

    • Use single copy of static assets. Update jQuery #5823

    • Changes ternary conditionals to be PEP308 compliant #5827

    • Added links to 'A Todo List API with React' and 'Blog API' tutorials #5837

    • Fix comment typo in ModelSerializer #5844

    • Add admin to installed apps to avoid test failures. #5870

    • Fixed schema for UUIDField in SimpleMetadata. #5872

    • Corrected docs on router include with namespaces. #5843

    • Test using model objects for dotted source default #5880

    • Allow traversing nullable related fields #5849

    • Added: Tutorial: Django REST with React (Django 2.0) #5891

    • Add LimitOffsetPagination.get_count to allow method override #5846

    • Don't show hidden fields in metadata #5854

    • Enable OrderingFilter to handle an empty tuple (or list) for the 'ordering' field. #5899

    • Added generic 500 and 400 JSON error handlers. #5904

    Source code(tar.gz)
    Source code(zip)
  • 3.7.7(Jan 11, 2018)

  • 3.7.4(Dec 20, 2017)

    Point Release for 3.7.x series.

    • Schema: Extract method for manual_fields processing #5633

      Allows for easier customisation of manual_fields processing, for example to provide per-method manual fields. AutoSchema adds get_manual_fields, as the intended override point, and a utility method update_fields, to handle by-name field replacement from a list, which, in general, you are not expected to override.

      Note: AutoSchema.__init__ now ensures manual_fields is a list. Previously may have been stored internally as None.

    • Remove ulrparse compatability shim; use six instead #5579

    • Drop compat wrapper for TimeDelta.total_seconds() #5577

    • Clean up all whitespace throughout project #5578

    • Compat cleanup #5581

    • Add pygments CSS block in browsable API views #5584 #5587

    • Remove set_rollback() from compat #5591

    • Fix request body/POST access #5590

    • Rename test to reference correct issue #5610

    • Documentation Fixes #5611 #5612

    • Remove references to unsupported Django versions in docs and code #5602

    • Test Serializer exclude for declared fields #5599

    • Fixed schema generation for filter backends #5613

    • Minor cleanup for ModelSerializer tests #5598

    • Reimplement request attribute access w/ __getattr__ #5617

    • Fixed SchemaJSRenderer renders invalid Javascript #5607

    • Make Django 2.0 support official/explicit #5619

    • Perform type check on passed request argument #5618

    • Fix AttributeError hiding on request authenticators #5600

    • Update test requirements #5626

    • Docs: Serializer._declared_fields enable modifying fields on a serializer #5629

    • Fix packaging #5624

    • Fix readme rendering for PyPI, add readme build to CI #5625

    • Update tutorial #5622

    • Non-required fields with allow_null=True should not imply a default value #5639

    • Docs: Add allow_null serialization output note #5641

    • Update to use the Django 2.0 release in tox.ini #5645

    • Fix Serializer.data for Browsable API rendering when provided invalid data #5646

    • Docs: Note AutoSchema limitations on bare APIView #5649

    • Add .basename and .reverse_action() to ViewSet #5648

    • Docs: Fix typos in serializers documentation #5652

    • Fix override_settings compat #5668

    • Add DEFAULT_SCHEMA_CLASS setting #5658

    • Add docs note re generated BooleanField being required=False #5665

    • Add 'dist' build #5656

    • Fix typo in docstring #5678

    • Docs: Add UNAUTHENTICATED_USER = None note #5679

    • Update OPTIONS example from “Documenting Your API” #5680

    • Docs: Add note on object permissions for FBVs #5681

    • Docs: Add example to to_representation docs #5682

    • Add link to Classy DRF in docs #5683

    • Document ViewSet.action #5685

    • Fix schema docs typo #5687

    • Fix URL pattern parsing in schema generation #5689

    • Add example using source=‘*’ to custom field docs. #5688

    • Fix format_suffix_patterns behavior with Django 2 path() routes #5691

    See 3.7.4 Milestone

    Source code(tar.gz)
    Source code(zip)
  • 3.7.3(Nov 6, 2017)

  • 3.7.2(Nov 6, 2017)

    Point release for 3.7.x

    • Fixed Django 2.1 compatibility due to removal of django.contrib.auth.login()/logout() views. #5510
    • Add missing import for TextLexer. #5512
    • Adding examples and documentation for caching #5514
    • Include date and date-time format for schema generation #5511
    • Use triple backticks for markdown code blocks #5513
    • Interactive docs - make bottom sidebar items sticky #5516
    • Clarify pagination system check #5524
    • Stop JSONBoundField mangling invalid JSON #5527
    • Have JSONField render as textarea in Browsable API #5530
    • Schema: Exclude OPTIONS/HEAD for ViewSet actions #5532
    • Fix ordering for dotted sources #5533
    • Fix: Fields with allow_null=True should imply a default serialization value #5518
    • Ensure Location header is strictly a 'str', not subclass. #5544
    • Add import to example in api-guide/parsers #5547
    • Catch OverflowError for "out of range" datetimes #5546
    • Add djangorestframework-rapidjson to third party packages #5549
    • Increase test coverage for drf_create_token command #5550
    • Add trove classifier for Python 3.6 support. #5555
    • Add pip cache support to the Travis CI configuration #5556
    • Rename [wheel] section to [bdist_wheel] as the former is legacy #5557
    • Fix invalid escape sequence deprecation warnings #5560
    • Add interactive docs error template #5548
    • Add rounding parameter to DecimalField #5562
    • Fix all BytesWarning caught during tests #5561
    • Use dict and set literals instead of calls to dict() and set() #5559
    • Change ImageField validation pattern, use validators from DjangoImageField #5539
    • Fix processing unicode symbols in query_string by Python 2 #5552

    See 3.7.2 Milestone

    Source code(tar.gz)
    Source code(zip)
  • 3.7.1(Oct 16, 2017)

    • Fix Interactive documentation always uses false for boolean fields in requests #5492
    • Improve compatibility with Django 2.0 alpha. #5500 #5503
    • Improved handling of schema naming collisions #5486
    • Added additional docs and tests around providing a default value for dotted source fields #5489

    3.7.1 Milestone

    Source code(tar.gz)
    Source code(zip)
  • 3.7.0(Oct 6, 2017)

    Headline feature is the ability to add per-view customisation to schema generation.

    • Release Announcement: http://www.django-rest-framework.org/topics/3.7-announcement/
    • 3.7.0 Milestone: https://github.com/encode/django-rest-framework/milestone/49?closed=1
    Source code(tar.gz)
    Source code(zip)
Owner
Encode
Collaboratively funded software development.
Encode
Web APIs for Django. 🎸

Django REST framework Awesome web-browsable Web APIs. Full documentation for the project is available at https://www.django-rest-framework.org/. Fundi

Encode 24.7k Jan 4, 2023
Document Web APIs made with Django Rest Framework

DRF Docs Document Web APIs made with Django Rest Framework. View Demo Contributors Wanted: Do you like this project? Using it? Let's make it better! S

Manos Konstantinidis 626 Nov 20, 2022
Browsable web APIs for Flask.

Flask API Browsable web APIs for Flask. Status: This project is in maintenance mode. The original author (Tom Christie) has shifted his focus to API S

Flask API 1.3k Dec 27, 2022
Creating delicious APIs for Django apps since 2010.

django-tastypie Creating delicious APIs for Django apps since 2010. Currently in beta but being used actively in production on several sites. Requirem

null 3.8k Dec 30, 2022
Scaffold django rest apis like a champion 🚀

scaffold django rest apis like a champion ??

Abdenasser Elidrissi 133 Jan 5, 2023
A small repository of projects built in my course, REST APIs with Flask and Python.

A small repository of projects built in my course, REST APIs with Flask and Python.

Teclado 1k Jan 5, 2023
RESTler is the first stateful REST API fuzzing tool for automatically testing cloud services through their REST APIs and finding security and reliability bugs in these services.

RESTler is the first stateful REST API fuzzing tool for automatically testing cloud services through their REST APIs and finding security and reliability bugs in these services.

Microsoft 1.8k Jan 4, 2023
Sanic-RESTPlus is an extension for Sanic that adds support for quickly building REST APIs.

Sanic RestPlus Sanic-RESTPlus is an extension for Sanic that adds support for quickly building REST APIs. Sanic-RESTPlus encourages best practices wit

Ashley Sommer 106 Oct 14, 2022
A JSON Web Token authentication plugin for the Django REST Framework.

Simple JWT Abstract Simple JWT is a JSON Web Token authentication plugin for the Django REST Framework. For full documentation, visit django-rest-fram

Jazzband 3.3k Jan 4, 2023
Country-specific Django helpers, to use in Django Rest Framework

django-rest-localflavor Country-specific serializers fields, to Django Rest Framework Documentation (soon) The full documentation is at https://django

Gilson Filho 19 Aug 30, 2022
The Web API toolkit. 🛠

?? The Web API toolkit. ?? Community: https://discuss.apistar.org ?? ?? ?? ?? ?? Documentation: https://docs.apistar.com ?? Requirements: Python 3.6+

Encode 5.6k Dec 27, 2022
Async Python 3.6+ web server/framework | Build fast. Run fast.

Sanic | Build fast. Run fast. Build Docs Package Support Stats Sanic is a Python 3.6+ web server and web framework that's written to go fast. It allow

Sanic Community Organization 16.7k Dec 28, 2022
a web-remote minecraft server wrapper with some unique features

Canceled here, continued as Semoxy MCWeb - a Minecraft Server Web Interface MCWeb is a web-remote Minecraft Server Wrapper for controlling your Minecr

Anton Vogelsang 1 Jul 12, 2021
BreakFastApi 🍣 🍔 🍕 The most delicious API on the web

BreakFastApi ?? ?? ?? The most delicious API on the web. Just send a request and you'll receive the most mouth watering dish recipe with estimated coo

Mariia Sizova 156 Nov 19, 2022
Django app for handling the server headers required for Cross-Origin Resource Sharing (CORS)

django-cors-headers A Django App that adds Cross-Origin Resource Sharing (CORS) headers to responses. This allows in-browser requests to your Django a

Adam Johnson 4.8k Jan 5, 2023
Authentication for Django Rest Framework

Dj-Rest-Auth Drop-in API endpoints for handling authentication securely in Django Rest Framework. Works especially well with SPAs (e.g React, Vue, Ang

Michael 1.1k Dec 28, 2022
Authentication Module for django rest auth

django-rest-knox Authentication Module for django rest auth Knox provides easy to use authentication for Django REST Framework The aim is to allow for

James McMahon 873 Dec 30, 2022
REST implementation of Django authentication system.

djoser REST implementation of Django authentication system. djoser library provides a set of Django Rest Framework views to handle basic actions such

Sunscrapers 2.2k Jan 1, 2023