Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Chpy 0915
- 1. {‘foo’: ‘bar’} Intro to web api’s using django and django-rest-framework
- 2. A Quick Dive… ignoring all the TL ; DR stuff
- 4. Delegation
- 6. How we roll in
- 8. Options zzz
- 9. DJANGO REST FRAMEWORK What it is and what it is ‘!’
- 10. Django Rest Framework Components
- 12. Let’s Roll . . DEMO
- 13. 1. virtualenv [env_name] 2. pip install Django 3. pip install djangorestframework 4. pip install django-filters 5. django-cors-headers
- 14. Working with DRF. . . A simple TODO’s Application
- 15. Conclusions
- 16. D.R.Y do not repeat yourself Search for Reusable Apps . . . TL;DR
- 17. Power of mixin’s and meaning full defaults go a long way
Editor's Notes
- Welcome Learning these new concepts is relatively easy considering you are already familiar with Python., Rajkumar wonderfully explained how we can get started using Django to create web-applications.. with that knowledge let's dive right in.. All or most of the websites / web-applications use web-api’s of some sort to interact with the persistent storage (database)., the primary goal of many of these services is to detach the dependency and help in separation of roles between client & server. The web server is responsible for fetching the data from the storage., translating it into a structure which the client (browser) can understand and forward that data to the client. The client on the other hand is only concerned about how to render and manipulate that data & sending updates back to the server.
- We will be using JS, AJAX for client - server interaction, for a pure python client we can use urllib2 or numerous other libraries.. Lets take the following example
- The traditional scenario (server sending HTML) How do we achieve separation of contexts.. what is it.. What we need to achieve is server not being involved in rendering any of the HTML .. u ask the server “can i see today’s comic” it does a couple of checks (arbitrary., if we have any) and sends the relevant data in the above image it’s a HTML page Traditionally, the server is also responsible for a lot of other things as well .. fetching the data is the obvious one, it also has to take a HTML template and render the appropriate content into it and send the html page back. This is good if we are talking about a static webpage. But that’s the old days, a web-api only sends data relevant enough for the client to take it forward., a image URL in this instance . The important thing to note is that the server is not concerned about who the client is, all which is required to talk to the server is HTTP. With api’s we can take advantage of several client-side templating languages like mustache.js to do that task of rendering the page as we wish.
- Leaving the technicalities & specifics of how django does its stuff., we can simplify the task of getting “today’s comic image” to the following steps Connect to the database and based on the what user is asking for try to find the database record If we cannot find the database record, let the client know If we do find something, serialize the relevant information into JSON (or anything else what the client is asking) Send the serialized data back to the client Loop Web-API’s make the following image possible..
- Let’s see some code.. To better understand how we can make the client happy..
- As soon as the client requests data on some URL, django first checks if we defined that URL and if so tries to execute the code associated with that URL., in this case lets asuse that the url is “www.foobar.com/get_comic_url” and we told django to exucute a function called “get_todays_comic_image” which does the steps we discussed in the previous slide., and send back
- Important thing to note here is that we are not doing any kind of HTML magic.. we are just sending the relevant information back to the client., we expect that the client already knows how to work with the data we are providing. Now let's get into the complexities of this: remember that we’re hard coding to JSON, imagine a client who is asking for some other response type say csv or xml and in a real world scenario there will be a lot more data and a lot more URL’s to worry about .. We can, still do, what we did in the previous example where we tell django to call a function for a url., and handle all the special cases.. which honestly is a little overwhelming., Trust me i’ve actually done that.
- a whole bunch of them exist in one form or the other which will allow you to implement what we were trying to do using the language of your choosing, but lets look at how django rest api does this..
- keeping with the principles of django, the django-rest-framework or DRF as the community calls it is a collection of different reusable applications which makes creating and working with the aforementioned problems a little bearable., simply put it's a module with a lot of helper functions useful in creating a restful api. “REST framework is an agnostic Web API toolkit. It does help guide you towards building well-connected APIs, and makes it easy to design appropriate media types, but it does not strictly enforce any particular design style.” it does not enforce the HATEOAS which stands for Hypertext As The Engine Of Application State (It means that hypertext should be used to find your way through the API) this is what the author of DRF has to say about HATEOAS “What REST framework doesn't do is give you machine readable hypermedia formats such as HAL, Collection+JSON, JSON API or HTML microformats by default, or the ability to auto-magically create fully HATEOAS style APIs that include hypermedia-based form descriptions and semantically labelled hyperlinks. Doing so would involve making opinionated choices about API design that should really remain outside of the framework's scope.” TASTYPIE another wonderful framework is fully compliant with HATEOAS with that in mind let's see how things work in DRF
- DRF also as we previously discussed divides the implementation into smaller chunks for reusability. It's a relatively small list to work with as each piece does one thing and only one thing very well. like the Requests .. whose only purpose in life is to convert the HTTP Request into a python object. similarly Responses deal in converting python native objects into valid HTTP Responses.. most of these components will only be used if we need to implement something very specific to us… like sending back a CSV or User Group Based Permissions, most of the times for a normal application which consumes JSON the defaults are good enough.. Most of the work which we will be doing will generally be inheriting form a class and if required modify the default behaviour., a good example would be to update a field in the database table called lastupdated_by with the user in question., but with proper design even this can be abstracted out into a Custom-Class, which can be used for inheritance instead of the factory ones.. Let’s look at sending “today’s comic image url to the client” using DRF
- First we define a structure for our database in Django as we usually do.. then comes the DRF part.. The Serializer responsible for converting Python Objects in order to transport them to the client over the wire., and also translated data sent by the client into Python Objects. Next is the ViewSet which does the heavy lifting of fetching from the database using the orm, converting it to JSON/CSV/. .. using a serializer and finally sending the Response back to the client., and also handle any eventualities.. a viewset internally inherits from individual components called mixins, whose only purpose is to handle inserts, updates, deletes… So if we wanted to have a scenario where we only need updates we can use one of the provided mixins.. we will look at those in more detail later.. the important thing to take home here is the general architecture & how functional components are broken down into modules so that they can be used in multiple places.
- Installing Django & Rest-Framework
- The take away is D.R.Y, and search or ask the community for the best tool for the job.,
- Scaling that simple to-do's app into something really useful can be very easily accomplished using DRF’s components., thinking about application development in terms of a web-API’s simplifies a lot of client code which we need to write & maintain .. Or for matter even the server code as we do not have to manage the task of creating the webpages (HTML) on the server.. With the numerous client side technologies which are being developed for the specific task of creating webpages & many other things which make sense only on the browser can be delegated to the browser. . Which leaves the server to just to server the most important thing DATA Thanks.
- Questions.