Django Rest Framework - Building a Web API
Post on 16-Apr-2017
Embed Size (px)
Marcos PereiraBuilding a web API with Django
Retrieves a ResourceCacheableGETCreates a new ResourcePOSTUpdates an existing ResourcePUTRemoves a ResourceDELETE
u Json, XML, etc.
u HATEOAS (Hipemedia As The Engine Of ApplicationState)
Django REST framework is a powerful andflexible toolkit for building Web APIs.
u Some reasons you might want to use REST framework:
u The Web browsable API is a huge usability win for your developers.
u Authentication policies including packagesfor OAuth1a and OAuth2.
u Serialization that supports both ORM and non-ORM data sources.
u Customizable all the way down - just use regular function-basedviews if you don't need the more powerful features.
u Extensive documentation, and great community support.
u Used and trusted by large companies suchas Mozilla and Eventbrite.
2. Class-Based Views/Mixins
3. Generic Views
5. HTTP Requests
6. Rendered Responses
Django Rest Framework
5. HTTP Requests
6. HTTP Responses
u Requirements:u Python (2.7, 3.2, 3.3, 3.4, 3.5)
u Django (1.7+, 1.8, 1.9)
DRF - Serialization
u Creating a Serializer class
u Working with Serializers
u Using ModelSerializers
Serializers ~ Djangos Forms
DRF - Requests and Responsesu Request objects:
u REST framework introduces a Request object that extendsthe regular HttpRequest, and provides more flexible requestparsing. The core functionality of the Request object isthe request.data attribute, which is similar to request.POST, but more useful for working with Web APIs.
u Response objects:u REST framework also introduces a Response object, which is
a type of TemplateResponse that takes unrendered contentand uses content negotiation to determine the correctcontent type to return to the client.
u Status codes:u Using numeric HTTP status codes in your views doesn't always
make for obvious reading, and it's easy to not notice if youget an error code wrong. REST framework provides more explicit identifiers for each status code, suchas HTTP_400_BAD_REQUEST in the status module. It's a goodidea to use these throughout rather than using numericidentifiers.
DRF - Requests and Responses
u Wrapping API views
u REST framework provides two wrappers you can use towrite API views:
u The @api_view decorator for working with function basedviews.
u The APIView class for working with class based views.
DRF - Class Based Views
u We can also write our API views using class basedviews, rather than function based views. As we'll seethis is a powerful pattern that allows us to reuse common functionality, and helps us keep ourcode DRY (don't repeat yourself).
u Writing our API using class based views
u Using mixins
u Using generic class based views
DRF - Relationships & Hyperlinked APIs
u At the moment relationships within our API are represented by using primary keys. In this part of thetutorial we'll improve the cohesion and discoverability ofour API, by instead using hyperlinking for relationships.
u Using primary keys.
u Using hyperlinking between entities.
u Using a unique identifying slug field on the related entity.
u Using the default string representation of the related entity.
u Nesting the related entity inside the parent representation.
u Some other custom representation.
DRF - ViewSets & Routersu REST framework includes an abstraction for dealing
with ViewSets, that allows the developer toconcentrate on modeling the state and interactionsof the API, and leave the URL construction to behandled automatically, based on common conventions.
u ViewSet classes are almost the same thingas View classes, except that they provide operationssuch as read, or update, and not method handlerssuch as get or put.
u Using Routersu Binding ViewSets
DRF - Authentication & Permissions
u Authenticating with the API
u Adding required permissions to views
u Custom Permissions
Questions & Discussion