Here are resources for curl and Django Rest framework:
DRF Serialization and Views
00:22 It provides classes called serializers for turning your Django models into JSON or XML or whatever else you’re going to use for your payload, views for controlling what can and can’t be seen in your API, and tools to tie into the URLs to specify where your objects live and how to access them.
00:42 Are you like me and prefer function-based views over class-based views? Or are you one of those folks who are the other way around? No worries, DRF provides a way to handle either case. The serialization toolkits inside of the DRF are most powerful when paired with Django models, but they don’t have to be tied to a Django model. You can also serialize non-ORM based data. And to assist with your debugging, one of the payloads is a web-based interface.
01:24 Not surprisingly, the Django REST Framework is built on top of Django, so you’ll need both Django and the Django REST Framework installed to be able to follow along with this course. As is best practice in the Python world, it’s better if you do this inside of a virtual environment.
pip command to install both Django and the Django REST Framework. Note that
djangorestframework is all one word. Most Django
pip modules usually have underscores in them. For some reason, the DRF folks decided not to follow this convention. If you run this command, you’ll get a long list of output, as Django, DRF, and all of their dependencies gets installed.
I’ll be using the command line tool
curl to show you some of the results coming out of the DRF.
curl comes built-in with most operating systems, but in case it doesn’t come with yours, you can get it at curl.haxx.se.
02:18 Don’t forget that all the code that I show you inside of this course is available in the Supporting Material drop-down. It can save you a fair amount of typing if you just grab that ZIP file and follow along.
Because this is just for me, I’m going to cheat on the password so that I don’t have to type anything complicated in, and so Django warns me. Now that I’ve got the application and the superuser, I’m going to create an app inside of
I’m not showing you the entire
settings file here, just the sections that I need to change. First off, I’m going to modify the
ALLOWED_HOSTS listing to include
localhost so that I can hit it from my browser when I’m using the Django development server.
I’m adding both versions of
localhost. And secondly, I need to register the two apps. I need to register Django REST Framework, And the newly created
people app. First, the Django
"rest_framework", which oddly enough has the underscore (
_) in it even though the PyPI module doesn’t, and the newly created
I’m going to keep the model fairly simple here with three fields: first name, last name, and title. And then because I’m anal retentive and I don’t like
Persons showing up in the Django admin, I’m going to update the
Meta value to
05:07 Typically what happens is with every model you create, you also create a serializer. The serializer specifies how to turn the model into the payload data for REST. By convention, the serializers are named the same thing as the models.
So here on line 5, you see me declare a
PersonSerializer to serialize my
Person object from the
models file. Similar to how a
Person inherits from
Model, the serializer inherits from the
ModelSerializer classes do a whole bunch of work for you.
05:38 They automatically look at the model that’s associated with them and know how to serialize the different kinds of fields. There’s all sorts of control you can do here to get fancy, and I’ll show you that in later lessons.
But for now, all I want to do is serialize the model as it is. I have to do two things inside of the
Meta section: specify the model this is associated with, which in this case is
Person, and the fields that I am going to serialize—
So now I’m editing the
people/views file, and I’m going to create a new view. This is on line 9,
list_people(). What this is going to do is list all of the people in the database, serialize each one of them, and return a payload with a listing of all of the people.
Line 8 is a decorator from DRF that tells DRF that this is going to be associated with the HTTP
GET method. DRF supports all of the HTTP methods supported by REST, so I can create views using the
@api_view decorator tied to any one of those HTTP methods. Notice that it takes a list.
You can actually have it associated with multiple HTTP methods if you desire. On line 10, I get a queryset of all of my people. On line 11, I instantiate the
PersonSerializer defined in the previous file, passing in the queryset and the variable
many set to
serializer is capable of serializing more than one object at a time. By passing in the entire
people queryset with all the people objects in it and
many=True, I will get all the data serialized for every one of the people in the queryset.
Similar to an
HttpResponse object, DRF has its own
Response object. It takes a
content dictionary. In this case, I’m defining the
content to have a single key named
"people" and the
.data associated with the
Creating the payload is a two step process. The first step is instantiating a
Serializer with your queryset, and the second step is referencing the
.data property and putting it into the
The view I’ve just shown you is a Django view like any other, and as such, I need to register it inside of the
urls file. I’m going to do this by creating a
urls file inside of
people/, and I’m going to specify a path called
"list_people/", associating that with the view that I just created.
You’re going to need something to serialize, of course, otherwise your payload will just be empty. In order to make that easy, I’ve created a
PersonAdmin object with the
"title" fields so that I can go into the Django admin and create some data in the database. Okay.
I’m almost all set now. The last thing I need to do is just register the
people/urls with the global
Fedora/urls. There are a couple of things I have to do to this file. First off, I have to update line 3 to include the
include function, because I’m going to include all of the
people.urls. Secondly, I’m going to create a path called
"people/" and include all of the
I need to register the database changes with the
makemigrations command. It found
people and registered it. Now I need to migrate that. Great, the database is all set up. And in order to be able to demo, I’m going to have to actually have some data in the database.
The response that comes back is in JSON. It’s a dictionary with the single key
"people" and an array of the four people I created in the database. In the upper window, you can see the
GET that was executed.
Because that’s a little hard to see, I’m going to do that again for you, but this time in a full window. Here’s the
curl command. I’m using
-s so that I don’t get the progress bar as I go along. I’m hitting the same URL, port
What comes back is a dictionary with a single attribute of
"people" and the four people that I created in the dictionary. That kind of feels like a lot, but most of what I did there was just typical Django stuff.
Let me just quickly review what I had to do. First off, I created the project and the app inside the project. Secondly, I created a
Person model, no different than I would create any model inside of a Django application.
The first DRF-specific thing I did was create the
PersonSerializer, which maps the
Person model object to a REST payload. I then created a view that uses a DRF
Response object to send a serialization of the
Person.objects.all() queryset down in the payload of REST.
13:17 And finally, I had to register this view as a URL, like any other view in Django. If you’re new to Django, there was a lot to follow along there. If Django’s old hat for you, there was very little extra code that you had to do to take your typical Django application and make it a REST-capable one.
13:37 So far, I’ve shown you the simplest possible view. The ViewSets mechanism in DRF gives you a lot of power to do a lot of REST stuff with very little code. Next up, I’ll introduce you to ViewSets.
Become a Member to join the conversation.