The 3.9 release gives access to extra actions in the Browsable API, introduces composable permissions and built-in OpenAPI schema support. (Formerly known as Swagger)
If you use REST framework commercially and would like to see this work continue, we strongly encourage you to invest in its continued development by signing up for a paid plan.
REST framework now has a first-pass at directly including OpenAPI schema support. (Formerly known as Swagger)
- There are now
JSONOpenAPIRendererclasses that deal with encoding
coreapi.Documentinstances into OpenAPI YAML or OpenAPI JSON.
get_schema_view(...)method now defaults to OpenAPI YAML, with CoreJSON as a secondary option if it is selected via HTTP content negotiation.
- There is a new management command
generateschema, which you can use to dump the schema into your repository.
Here's an example of adding an OpenAPI schema to the URL conf:
from rest_framework.schemas import get_schema_view from rest_framework.renderers import JSONOpenAPIRenderer from django.urls import path schema_view = get_schema_view( title='Server Monitoring API', url='https://www.example.org/api/', renderer_classes=[JSONOpenAPIRenderer] ) urlpatterns = [ path('schema.json', schema_view), ... ]
And here's how you can use the
generateschema management command:
$ python manage.py generateschema --format openapi > schema.yml
There's lots of different tooling that you can use for working with OpenAPI schemas. One option that we're working on is the API Star command line tool.
You can use
apistar to validate your API schema:
$ apistar validate --path schema.json --format openapi ✓ Valid OpenAPI schema.
Or to build API documentation:
$ apistar docs --path schema.json --format openapi ✓ Documentation built at "build/index.html".
API Star also includes a dynamic client library that uses an API schema to automatically provide a client library interface for making requests.
You can now compose permission classes using the and/or operators,
permission_classes = [IsAuthenticated & (ReadOnly | IsAdmin)]
If you're using custom permission classes then make sure that you are subclassing
BasePermission in order to enable this support.
Following the introduction of the
action decorator in v3.8, extra actions defined on a ViewSet are now available
from the Browsable API.
When defined, a dropdown of "Extra Actions", appropriately filtered to detail/non-detail actions, is displayed.
REST framework 3.9 supports Django versions 1.11, 2.0, and 2.1.
DjangoObjectPermissionsFilter class is pending deprecation, will be deprecated in 3.10 and removed entirely in 3.11.
It has been moved to the third-party
package. Please use this instead.
base_nameargument has been renamed in favor of
Router.get_default_base_namemethod has been renamed in favor of
get_default_base_name() are pending deprecation. They will be deprecated in 3.10 and removed entirely in 3.11.
detail_route are now deprecated in favour of the single
They will be removed entirely in 3.10.
action decorator takes a boolean
APIView.exclude_from_schema and the
exclude_from_schema argument to the
@api_view have now been removed.
APIView you should instead set a
schema = None attribute on the view class.
For function-based views the
@schema decorator can be used to exclude the view from the schema, by using
There are a large number of minor fixes and improvements in this release. See the release notes page for a complete listing.
We're planning to iteratively work towards OpenAPI becoming the standard schema
representation. This will mean that the
coreapi dependency will gradually become
removed, and we'll instead generate the schema directly, rather than building
OpenAPI has clearly become the standard for specifying Web APIs, so there's not much value any more in our schema-agnostic document model. Making this change will mean that we'll more easily be able to take advantage of the full set of OpenAPI functionality.
This will also make a wider range of tooling available.
We'll focus on continuing to develop the API Star library and client tool into a recommended option for generating API docs, validating API schemas, and providing a dynamic client library.
There's also a huge amount of ongoing work on maturing the ASGI landscape, with the possibility that some of this work will eventually feed back into Django.