Amit Nabarro: RESTful APIs in Django

Very pleased now to introduce Amit Nabarro who is going to talk about RESTful APIs with Django. {Applause}.

AMIT NABARRO: Working? No? Is this working?

NEW SPEAKER: For the video...

AMIT NABARRO: Hi everyone my name is Amit. I am going to talk about RESTful API with Django today. A few words about me. I have been doing software development for a living for far longer than I care to admit. 7 years ago I read a book about ruby on rails and a saw a comparison with Django and I pretty much never looked back. I only work with Django these days.

So, anyone who has done anything with Django in the past knows that traditional Django what I like to call classical Django is based on a concept which is called model view control or a variation of it. Most of the frameworks out there today use this model and Django is no different. And if you have written even the simplest example in Django you know that views return with email, you send a request and they return HTML - - but that’s not always enough because this was maybe could 10 years ago when only browsers taught your application but today other kind of devices talk your application, mobile devices talk your application, machines talk to your application applications, other servers talk your applications and they don’t always want your fancy beautiful HTML you created, they just want raw data because they have their own presentation data their own thing they do with your data. So the traditional or classic model which Django was built on isn’t that useful in those cases.

Well, before I go further I’d like to remind you something which you all should know probably very well that the internet works in a very simple concept which is called request response. You fire up your browser, type in a URL, that request goes to the server then the server generates a response, a response goes back to you. The protocol this whole thing works on is http. Http is a text protocol, it happens to use HTML in classical Django - - - but it doesn’t have to use HTML, it could use other text based formats as well. It could be used Json, XLL, the cool formats you came up with.

So since you can do that with http and since you can return other forms of data rather than just HTML, you could be using the same mechanism in Django to return your data.

Now, why would you want to do it?

The first thing it allows multiple platforms to access your application. For example mobile devices have their own user interface, their own platforms, they’re not interested in your HTML, they just want to get raw data then display it for their users, so they would like to request data in the format of Json most likely.

Other machines, servers that may access your own application and down load information from your database. That’s another good reason to do it.

Modularity, separation, we’re going to talk about this in a little bit.

Then the last part which is also very important, it makes it very easy to develop single page applications. Anyone who doesn’t know what those are, those are Java script applications, called skateful application, the entire application down loads to the browser in one request then all subsequent requests are on HS. You’ve all seen those, they’re very common these days and they’re very useful.

So, in order to have your general project expose these capabilities you need to develop something called a web API. What is a web API? I ask that question on the web and I found this definition: an application programmatic interface to a defined request response message system.

That’s great, that fits really well with the basis on which Django works on the http request response message system. So all we have to do now is to modify our views instead of returning HTML get them to return something else, return Json for example.

A lot of you might say OK fine, I can do that no problem, I don’t need the risk framework or a third party tool, I can return Json no problem I can modify my review and return Json and here is a good example the most simple example which are a function of a view, returns the first name and last name of the user. This will work, this is actually valid code, and if you make a request with any tool to your web server you will get a Json which replies to the first name and the last name of the user currently in session.

Now while this is a very valid example it’s really not very useful because most projects are much more sophisticated, they require a lot more capabilities than just something simple like this and for that reason most projects that involve a web API end up using some kind of a web API framework.

Now I’ve mentioned the term REST and RESTful API, ever since I started talking. What is REST? REST stands for representational state transfer. It’s a software architecture style consisting of guidelines and best practices. REST is not a technology. Rest is an agreement. It’s a contract between a client and a server. I will serve you a restful API. OK I know what that is, I’ll write the client to consume your restful API.

And there are multiple ways to develop web APIs today but REST is considered one of the good ones. And in general alone there are multiple web frameworks that support the model.

Here is a couple of examples and principles of REST. The most important principle of REST is every resource is unique and in REST terminology every request you make is made to a resource, a resource can return data, and here are some examples of URL that is a unique URL for server, requesting first user or requesting user based on first name or requesting - here is an example, the last one is an example of a nes {inaudible} resource it’s a resource that belongs to another resource - this is outside the focus of this talk.

Another important principle of REST is that the inter actions are state less. There is no state carried from one to another. Nothing is saved on a server. Everything has to come either as a body request or in the URL.

So, I said earlier that yes you could write your own views that return Json or return another form of text based response but if you are going to develop something that is a little more sophisticated and simple user name than the simple name of a user then you will want to use a web framework which a - a REST framework which will give you a lot - now what can you expect from a REST framework?

The first thing you can expect is see realisation, take your data, see realising it, Json. HTML very important. Pagination, you have a lot of data and you need to paginate through your data you can’t obviously make a single request from all the data in your database because that will take for ever. Validation another important thing especially when you submit data if you are posting or putting data and want to validate it that’s another thing you can expect from a REST framework authentication anything to do with users logging into your system. Authorisation anything that has to do with what the user is allowed to do on the system. Throttling, throttling deals with managing too many request’s when your server is bombed with requests you want to slow down, you want to allow users to have only certain amount of requests per se second or certain amount per millisecond that is where throttling comes in. Caching very important. If you have a single request data being called multiple times you want to cache your response so you don’t have to get it from the database then serialise it again because it’s a very good concept and it’s a very rooted in Django itself. API discovery that’s also very important. If you are developing an API which goes to another third party user which will use your API you want that API to be documented and discoverable and you can expect your REST framework to expose its own API or its own scheme and say OK these are APIs I’m exposing, unit testing if you don’t write unit test you should be ashamed of yourself. And a lot more ...

Existing REST frameworks are for Django. The first is the Django REST framework DRF, written by Tom Christie, excellent piece of software, fantastic, huge user community, very well documented, highly recommended.

Django tasty pie just as good just as well documented, huge user community, actually it’s even been around longer than DRF, and it’s a very good option. Django piston is a third one. I wouldn’t use it. Django piston is dead; it hasn’t been maintained for a while, documentation code, just don’t use it, if you happen to run into it move on.

Here’s an example of something which takes a model, a Django model and turns it into a resource. So I mention before that in the REST terminology we consider our data as resources. Here is an example of taking a book model or a database model which represents a book and turning it into a - this is all you need to do in order to get, take a model and turn it into 4 lines of code. Obviously a very simple example, probably more simple than the tutorial you’re going to see in tasty pie, this is done in tasty pie not DRF, but DRF is very, very similar. And what will happen is these 4 lines of code is going to turn your model into a resource which you can perform crude operations on, create up-date - all that in 4 lines of code. It’s pretty cool.

Working with SQL that’s not a problem at all. REST is not limited to relational databases. You can wrap your data sources with a REST framework to any data source you are using whether it’s a relation database like {inaudible} or using mongo DB or any other thing. In fact on the fourth day of this conference, there is a workshop that I’m doing on mongo DB and Django and I’ll be touching that subject in very detailed way.

That’s it. Pretty much. {Applause} I would like to say one more thing. REST is a very big concept and I can probably talk about it all day but given that it was only 20 minutes I tried to condense it as much as possible and give you an introduction to it but if you are interested in talking more about REST I am going to be here for the REST of the conference.

NEW SPEAKER: Thank you very much. Questions if anyone is interested.

NEW SPEAKER: Which of the 2 recommended frameworks do you think is most likely to end up in the core of Django?

AMIT NABARRO: I don’t know if I can answer this question unopinionated. You want an opinion I have no idea. I use Django testify {inaudible} for familiarity and no other reason. Django framework is fantastic but it’s my personal preference.

NEW SPEAKER: What’s the main reason you decided to use Django and not rails for your APIs except to {inaudible}.

AMIT NABARRO: Before I was doing computation I was using Python so it was just easier for me to do it but if you look at - I like to look at trends and Django is really trending up and ruby on rails is ... that’s not my opinion ... {applause}.

NEW SPEAKER: My question is - ruby on rails doesn’t have much support on-line {inaudible} engineering things like that, whereas Python has a lot of support on things like data management and engineering things like that. What’s your take on that like?

AMIT NABARRO: It’s a known fact Python has way more third party modules than ruby so you are more likely to find something in Python than - I can give an example, just not too long ago I was writing a driver for an engine and it was talking something called mud bus which is just a protocol for motors to talk and it’s based on http and {inaudible} wait a minute...motor bus ... that was it. Anything else? OK thank you very much. {Applause}.

DANIELE: So while Yamila sets up, to let you know that there is a jobs fayre with the sponsors in the foyer, so if you are interested in talking to them, now might be a good time. Otherwise they are going the be here all day, you can talk to them at any time.

If you didn’t get the message earlier, whatever it says on any piece of paper you may see, lunch will start at 12:30 that is the earliest we are doing lunch. If you are only here for the Open Day, sorry, we are not able to provide you lunch because we have only provided lunch for the people who signed up for it because, those are the numbers we have, but there are plenty of places to grab a bite to eat nearby.