Here are resources for curl and Django Rest framework:
DRF Serialization and Views
00:00 In the previous lesson, I gave you an overview of REST. In this lesson, I’ll give you an introduction to the Django REST Framework, concentrating on the serialization and view mechanisms.
00:12 The Django REST Framework is a toolkit for developing web APIs built on top of the Django platform. It integrates with Django models, views, and URL patterns.
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:08 You can use the web to interact with the API, examine the payloads that come back, and initiate the different HTTP calls to manipulate objects on the server.
01:18 Full documentation and tutorials can be found at django-rest-framework.org.
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.
I’m going to start by setting up a sample Django project, which I’ll then use to demonstrate the DRF. First off, I’m going to use the Django command to start a new project called
Go into the
Fedora/ directory, and you’ll see the clean installation of the
Fedora/ directory with
urls, et cetera, as well as the
Next thing that I want to do is create a superuser. Before I do that, I need to deal with the database so that the
auth tables are built, so I’m going to run
03:03 And now that that is done, I’m going to create a superuser.
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
Here’s what the directory looks like now. I’ve got the
Fedora/ directory, I’ve got a database, I’ve still got the
manage.py, and the newly created
Now that I have the project created and the
people app created, I need to update the
Fedora/settings.py file to make a couple small changes.
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
That’s all the changes for the
settings file. Now that everything’s set up, let’s start writing some code. First off, I’m going to create a
Person object for the database using a Django model.
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
Here’s the first bit of DRF code. Create a file called
serializers.py inside of the
people app. This file is the pair of the model.
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—
06:09 And that’s all I need to do. Serialization’s now ready to go, the DRF will take care of the rest of turning the model into a payload.
06:21 Serializers themselves are only responsible for turning models into payloads. They don’t actually create the views or map to the URLs. The DRF uses the same kind of patterns as Django.
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
Now you’ll be able to hit the development server with the path
people/list_people/, included from the app’s
09:33 Okay, all the code’s set up. Almost ready to go.
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.
10:00 I’m going to run the Django development server and show you the admin right now.
Offscreen, I’m running the Django development server, and here in my trusty web browser, I’m going to open up the
/admin URL. That’s
I’m going to log in with
admin and the super secret five-letter password I created earlier that begins with
a and rhymes with
10:25 And here I am inside of the Django admin. I’m going to add a few people by clicking on the Add button.
10:58 And here are my four people for the database.
Or, if you don’t feel like doing all of that, I managed to save all of that in a fixture for you so you can run the
11:13 Either way, you’ve now got some data in the database with some people. I’m running the Django server,
and then I’m going to switch to the lower window and hit that server with
curl. First off,
localhost:8000/people/list_people/, the view that I just created a few minutes ago.
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.
/people/list_people/ was hit, and that translated into the
list_people() view that I created in the
views.py file in the
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
And then as I did in the previous lesson, I’m going to pipe this through Python using the
json.tool module to pretty print the result. Let me just scroll up here for you.
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.
Short answer is the installation instructions for DRF say you should :)
Longer answer is third party apps are apps just like the ones you write. For Django to see them they have to be in INSTALLED_APPS. The DRF includes views and templates that your project wouldn’t be able to see unless they’ve been registered with Django.
Can you please let me know what is the theme used for VS Code in this tutorial?
Hi B S K Karthik,
I don’t personally use VS Code, some of the other course creators do. We’ve recently (after this course was published) started to standardize on a colour theme, we based it closely on “Dainty - Material Theme Ocean”. It isn’t the same as what is here, but not that far off.
If you’re really interested, message back and I can send you the exact colour codes used here and you could adopt them to your own theme.
IIRC, I based them on Vim’s color scheme called “desert”
But I may have mucked with them over the years.
Hi there. I got the admin running fine through python3 manage.py runserver and then adding /admin. When I try to do the curl command I get the following: curl: (7) Failed to connect to 127.0.0.1 port 8000: Connection refused
I am using gitpod Thanks Anders
I’ve never used gitpod so I’m not sure off the top of my head. My guess is that you’ve got a network exposure or firewall issue. Given that gitpod is built on K8, are you sure that the dev server inside is exposed and bound to the same IP address?
Are you able to run this outside of gitpod in a shell and have the same problem?
When running in gitpod are you able to see the output? Can you see the django server running? It should look something like this:
Django version 3.1.2, using settings 'Fedora.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
Keep in mind that 127.0.0.1 is a local IP address and isn’t exposed to the outside world. If I run it on machine A, machine B won’t see it. Kubernetes tends to set up a little world similar to its own machine so likely isn’t exposing localhost to the outside world. It has been over a year since I played with K8, but IIRC, you would have to tell it to map an outside IP address to the thing happening in the container. I don’t know how much gitpod does for you when setting this kind of thing up.
Maybe someone else on the forum who has experience with gitpod can point you in the right direction.
Hi Christopher. Thanks for your response. I am afraid 127.0.0.1 refused to conntect and I have tried everything. I also tried using VS Code but had the same problem.. very strange. If I $ python3 -m http.server I get Serving HTTP on 0.0.0.0 port 8000 (0.0.0.0:8000/) … I have another Django app that I completed where I can access /admin/ Thanks Anders
That is truly strange. Are you able to hit other URLs on localhost besides /admin/? Are you seeing anything on the server side at all when you hit the URL, or is curl just refusing? Have you tried a browser instead of curl?
Double check the URL itself. Any chance you’re accidentally using https instead of http?
I’m reaching in the dark at this point. Maybe copy-and-paste both the django server terminal window text and the curl session so I can take a look.
OOPPSS.... Schoolboy error I am afraid. I was in the wrong directory. Now that I run Pyhton manage.py runserver it works. I appreciate that you job here I not to provide tuition and I thank you for your respones. I had just been looking for every single answer out there except the obvious one…:-) Have a great day.
Happens to all of us. Nothing like looking at a problem the next day to get that “uh-duh” moment. Glad you figured it out. …ct
Become a Member to join the conversation.
apurvakunkulol on Jan. 29, 2021
What is the need to add the
INSTALLED_APPSsection? Since we’re already installing it before using. I can understand about the
peopleapp but why