So far in our journey into Django everything has been contained within our Django project. Our data is stored in models, we use urls to configure routes, views to organize the logic of response-requests, and finally templates for the presentation of our actual web pages. This approach works well…but there are some limitations.

What happens if we want to add an iOS app? An Android app? Or what if we want to work with a cutting-edge front-end JavaScript framework like React, Vue, or Angular?

With our traditional approach we’re out of luck. This is why modern websites increasingly favor a separation of concerns: a backend that connects with separate, often multiple, frontends.

We can use Django Rest Framework to create an API (Application Programming Interface) to connect the backend with different frontends.

How the Internet Works

Now that we’re sending information over the internet between our backend and frontends, we need to understand a bit more about what’s happening under-the-hood.

Stated very concisely, the internet is a global network of millions of connected computers. They locate and communicate with one another via TCP/IP. The data that two computers send back and forth occurs via HTTP, which is a set of rules governing this interaction.


HTTP was invented by Tim Berners-Lee in the 1980s and is the basis for the modern World Wide Web. Computers had been communicating for decades before over the internet, but the invention of HTTP allowed for web pages, links, and the things we associate with modern websites.

HTTP is a protocol–a set of instructions–for how machines communicate with one another. It follows a request and response model between client and server. One computer (the “client”) requests information and the other computer (the “server”) sends it as a response.

Note: A server is just a computer, albeit a special one, that is connected to the internet all the time and optimized to handle HTTP requests. Servers usually live in server farms run by large companies like L3, Amazon, Google, Facebook, and so on.

For example, when you go to the website you want to get that webpage. Your browser sends a request which connects with an Instagram server; that server sends a response containing the HTML, CSS, JavaScript, images, and anything else needed to display the Instagram homepage.

When you upload an image or make a comment you are still communicating with an Instagram server, but in a different way. You want to post content to the Instagram server so that other users, when they view their homepage, can later get them.

I hope you can see that HTTP allows for different types of communication to take place. These are more formally known as HTTP request methods (or verbs).

The two most common HTTP methods are:

  • GET: retrieve data such as homepage or Instagram images
  • POST: send data such as login, post a picture, make a comment

In a way, a web browser is nothing more than a GUI (Graphical User Interface) for HTTP! Everything you do is either requesting or posting information in some form with a web server.


HTTP is a stateless protocol because each request/response pair is completely independent from the previous one. A server doesn’t need to remember any information, or state, between requests. Another way to think of this is that HTTP messages are like self-destructing notes that disappear after they’re read.

This stateless nature of the web is a big deal. Being stateless makes it easier for servers and clients to connect consistently. But it makes it much harder to manage state, a record of previous interactions.

Consider what happens when you login to a website like Instagram. If the web is stateless, how does Instagram know that you are a logged in user? Or how about shopping on Amazon: how does Amazon know what’s in your shopping cart? The answer is that your web browser (the client) is responsible for managing state and can do it via cookies, local storage, and other means.


The last piece of the puzzle is our actual API (Application Programming Interface) which is one more layer of meaning on top of HTTP. All communication happens through HTTP but our API sets the rules for the user interface. In other words, the API makes it easier to communicate with an application. The API will be how our backend communicates with our frontend via HTTP.

There are multiple types of API patterns but the most common on the web is known as REST (Representational State Transfer).

A RESTful APIs creates endpoints which are URLs that accept different HTTP requests. For example, Instagram has an external REST API. You can see the documentation here. If you want to interact with a comment, the URL pattern is:<media-id>/comments

If you pass in the <media-id> of an image then this URL lets you update the comments. Their API documentation states that it accepts three HTTP methods: GET, POST, and DEL. In other words you can either get the comment content, post a new content, or delete a content.

To do this you’d use the URL provided and attach the requisite HTTP method.

In response to this request, you’ll receive a status code indicating whether the HTTP request was successful (2xx), redirected (3xx), had a client error such as page not found (4xx), or a server error (5xx).


The final thing to note is that permissions are very important with APIs. You don’t want just anyone to have access to manipulate your database records! We’ll use Django Rest Framework to create an internal API that only we can access, but it’s also possible to add external permissions so other authenticated users can access the API, too.

This is what Instagram does. They have one API and use it internally to power their website and mobile apps. They also expose part of this same API to external developers. So you could conceivably use the Instagram API to login to to your account and then update a comment you’ve made on an image, assuming Instagram said it was ok.

The point is the same API will have multiple levels of permissions. But it’s the same API under-the-hood.


If you’re brand new to HTTP and APIs then you’re probably quite confused right now! That’s normal. It takes a long time to internalize and become comfortable with these concepts.

The main takeaway is that we’re going to be using Django Rest Framework to create a separate backend API that can communicate with multiple frontends (web, mobile). Computers communicate with one another over the internet via HTTP. We use HTTP methods to describe the type of interaction (often GET or POST) we want to take place. RESTful APIs describe how to interact with a server via HTTP by providing endpoints, which are available URLs and accepted HTTP methods. And finally permissions are very important with APIs!

Fortunately Django Rest Framework standardizes many of the common things we’d need to convert a Django application into a REST API. It’s amazing.

Continue on to the chapter Bonus: Todo List API with React to build the API for a todo list app and then display it with a React frontend.

I’m currently working on new chapters featuring Django Rest Framework. Sign up for the Django For Beginners newsletter to be updated when they’re ready!