As you can see, if you using django-rest-framework, you will found many different response format. This middleware to solve all of these problems with Standard API Response. All HTTP Response status stored into json response, not in HTTP Status (because mobile application, like android can't fetch the response body when HTTP Status >= 400).
This snippet shows how to add a `url` field to your API objects, which will then show up as an object in your JSON output. As parameters, you can specify: - `urls`: A list of strings that exist on your URLMan class - `attribute`: The name of the URLMan class on your model, defaults to `"urls"` - `full`: If the full URLs including schema and hostname should be supplied, defaults to `True`
Mixin for Django Rest Framework View/Viewsets to use different response data/serializers without unnecessary hacks. Just extend your DRFs view/viewset with this mixin after the DRF's APIView (sub)classes.
Using Django REST Framework for Model views there is always the issue of making duplicated queries without either prefetching the objects that will be accessed using the serializer and as such will lead to large number of queries being made to the database. This will help in optimizing the queryset used for the viewset by accessing the `_meta.fields` property of the serializer.
[DRF browsable API interface](http://www.django-rest-framework.org/api-guide/filtering/#customizing-the-interface) for django-rest-framework-gis [InBBoxFilter](https://github.com/djangonauts/django-rest-framework-gis#inbboxfilter) Tested with Django==1.10.5 django-filter==1.0.1 djangorestframework==3.5.4 djangorestframework-gis==0.11 
Say you want to keep your API secure and thus it has authentication, but there's this one View action in a ViewSet which unlike the rest of the ViewSet's actions needs to allow free access without authentication. This solution applies the good old `IsAuthenticated` permission to all ViewSet actions except those defined in a `login_exempt_actions` list. That's a list of the ViewSet action's names. This is a simple solution for this particular problem, which I imagine could be quite common. Any case where the requirements are more complex should implement one of the DRF permissions extensions which allow for the use of logical operators. **NOTE**: Remember that `request.user` will be an `AnonymousUser` instance, so be careful with any code which assumes it'll be a `User` instance. This could be the case with, say, a custom `get_queryset` implementation.
This hasn't been thoroughly tested yet but so far it works great. We had no use for sessions or the built in authentication middleware for django as this was built to be a microservice for authentication. Unfortunately if you just use the django rest framework-jwt package the authentication occurs at the view level meaning request.user.is_authenticated() will always return False. We have a few internal non-api views that needed @login_required. We have a stripped down version of django that is very performant that we are using for microservices with built-in authorization using JSON Web Tokens. This service is authentication which has access to a `users` table. Any questions or curious how well lightweight django is working for microservices, or we he are doing the the authorization on the other services, or just improvements please drop a line - thanks.