Login

Build a Django RESTful API on Fedora.

<div style="margin: 5px 5% 10px 5%;"><img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/01/build-a-django-restful-api-on-fedora.png" width="750" height="421" title="" alt="" /></div><div>With the rise of kubernetes and micro-services architecture, being able to quickly write and deploy a RESTful API service is a good skill to have. In this first part of a series of articles, you’ll learn how to use Fedora to build a RESTful application and deploy it on Openshift. Together, we’re going to build the back-end for a “To Do” application.
 
The APIs allow you to Create, Read, Update, and Delete (<a href="https://en.wikipedia.org/wiki/Create%2C_read%2C_update_and_delete">CRUD</a>) a task. The tasks are stored in a database and we’re using the Django ORM (Object Relational Mapping) to deal with the database management.
<h3>Django App and Rest Framework setup</h3>
In a new directory, create a Python 3 virtual environment so that you can install dependencies.
<pre class="wp-block-preformatted">$ mkdir todoapp && cd todoapp $ python3 -m venv .venv $ source .venv/bin/activate</pre>
After activating the virtual environment, install the dependencies.
<pre class="wp-block-preformatted">(.venv)$ pip install djangorestframework django</pre>
<a href="https://www.django-rest-framework.org/">Django REST Framework</a>, or DRF, is a framework that makes it easy to create RESTful CRUD APIs. By default it gives access to useful features like browseable APIs, authentication management, serialization of data, and more.
<h4>Create the Django project and application</h4>
Create the Django project using the django-admin CLI tool provided.
<pre class="wp-block-preformatted">(.venv) $ django-admin startproject todo_app . # Note the trailing '.' (.venv) $ tree . . ├── manage.py └── todo_app     ├── __init__.py     ├── settings.py     ├── urls.py     └── wsgi.py 1 directory, 5 files</pre>
Next, create the application inside the project.
<pre class="wp-block-preformatted">(.venv) $ cd todo_app (.venv) $ django-admin startapp todo (.venv) $ cd .. (.venv) $ tree . . ├── manage.py └── todo_app ├── __init__.py ├── settings.py ├── todo │ ├── admin.py │ ├── apps.py │ ├── __init__.py │ ├── migrations │ │ └── __init__.py │ ├── models.py │ ├── tests.py │ └── views.py ├── urls.py └── wsgi.py</pre>
Now that the basic structure of the project is in place, you can enable the REST framework and the todo application. Let’s add rest_framework and todo to the list of INSTALL_APPS in the project’s settings.py.
<pre class="wp-block-preformatted">todoapp/todo_app/settings.py</pre>
<pre class="wp-block-preformatted"># Application definition INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'rest_framework', 'todo_app.todo', ]</pre>
<h3> Application Model and Database</h3>
The next step of building our application is to set up the database. By default, Django uses the SQLite database management system. Since SQLite works well and is easy to use during development, let’s keep this default setting. The second part of this series will look at how to replace SQLite with PostgreSQL to run the application in production.
<h4>The Task Model</h4>
By adding the following code to todo_app/todo/models.py, you define which properties have a task. The application defines a task with a title, a description and a status. The status of a task can only be one of the three following states: Backlog, Work in Progress and Done.
<pre class="wp-block-preformatted">from django.db import models class Task(models.Model): STATES = (("todo", "Backlog"), ("wip", "Work in Progress"), ("done", "Done")) title = models.CharField(max_length=255, blank=False, unique=True) description = models.TextField() status = models.CharField(max_length=4, choices=STATES, default="todo") </pre>
Now create the database migration script that Django uses to update the database with changes.
<pre class="wp-block-preformatted">(.venv) $ PYTHONPATH=. DJANGO_SETTINGS_MODULE=todo_app.settings django-admin makemigrations</pre>
Then you can apply the migration to the database.
<pre class="wp-block-preformatted">(.venv) $ PYTHONPATH=. DJANGO_SETTINGS_MODULE=todo_app.settings django-admin migrate</pre>
This step creates a file named db.sqlite3 in the root directory of the application. This is where SQLite stores the data.
<h3>Access to the data</h3>
<h4>Creating a View</h4>
Now that you can represent and store a task in the database, you need a way to access the data.  This is where we start making use of Django REST Framework by using the <a href="https://www.django-rest-framework.org/api-guide/viewsets/#modelviewset">ModelViewSet</a>. The ModelViewSet provides the following actions on a data model: list, retrieve, create, update, partial update, and destroy.
Let’s add our view to todo_app/todo/views.py:
<pre class="wp-block-preformatted">from rest_framework import viewsets from todo_app.todo.models import Task from todo_app.todo.serializers import TaskSerializer class TaskViewSet(viewsets.ModelViewSet): queryset = Task.objects.all() serializer_class = TaskSerializer</pre>
<h4>Creating a Serializer</h4>
As you can see, the TaskViewSet is using a <a href="https://www.django-rest-framework.org/api-guide/serializers/">Serializer</a>. In DRF, serializers convert the data modeled in the application models to a native Python datatype. This datatype can be later easily rendered into JSON or XML, for example. Serializers are also used to deserialize JSON or other content types into the data structure defined in the model.
Let’s add our TaskSerializer object by creating a new file in the project todo_app/todo/serializers.py:
<pre class="wp-block-preformatted">from rest_framework.serializers import ModelSerializer from todo_app.todo.models import Task class TaskSerializer(ModelSerializer): class Meta: model = Task fields = "__all__"</pre>
We’re using the generic <a href="https://www.django-rest-framework.org/api-guide/serializers/#modelserializer">ModelSerializer</a> from DRF, to automatically create a serializer with the fields that correspond to our Task model.
Now that we have a data model a view and way to serialize/deserialize data, we need to map our view actions to URLs. That way we can use HTTP methods to manipulate our data.
<h4>Creating a Router</h4>
Here again we’re using the power of the Django REST Framework with the <a href="https://www.django-rest-framework.org/api-guide/routers/#defaultrouter">DefaultRouter</a>. The DRF DefaultRouter takes care of mapping actions to HTTP Method and URLs. 
Before we see a better example of what the DefaultRouter does for us, let’s add a new URL to access the view we have created earlier. Add the following to todo_app/urls.py:
<pre class="wp-block-preformatted">from django.contrib import admin from django.conf.urls import url, include from rest_framework.routers import DefaultRouter from todo_app.todo.views import TaskViewSet router = DefaultRouter() router.register(r"todo", TaskViewSet) urlpatterns = [ url(r"admin/", admin.site.urls), url(r"^api/", include((router.urls, "todo"))), ]</pre>
As you can see, we’re registering our TaskViewSet to the DefaultRouter. Then later, we’re mapping all the router URLs to the /api endpoint. This way, DRF takes care of mapping the URLs and HTTP method to our view actions (list, retrieve, create, update, destroy).
For example, accessing the api/todo endpoint with a GET HTTP request calls the list action of our view. Doing the same but using a POST HTTP request calls the create action.
To get a better grasp of this, let’s run the application and start using our API.
<h3>Running the application</h3>
We can run the application using the development server provided by Django. This server should only be used during development. We’ll see in the second part of this tutorial how to use a web server better suited for production.
<pre class="wp-block-preformatted">(.venv)$ PYTHONPATH=. DJANGO_SETTINGS_MODULE=todo_app.settings django-admin runserver Django version 2.1.5, using settings 'todo_app.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C.</pre>
Now we can access the application at the following URL: http://127.0.0.1:8000/api/
<figure class="wp-block-image"><img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/01/build-a-django-restful-api-on-fedora.png" alt="" class="wp-image-24543" /></figure>
DRF provides an interface to the view actions, for example listing or creating tasks, using the following URL: http://127.0.0.1:8000/api/todo
<figure class="wp-block-image"><img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/01/build-a-django-restful-api-on-fedora-1.png" alt="" class="wp-image-24544" /></figure>
Or updating/deleting an existing tasks with this URL: http://127.0.0.1:8000/api/todo/1
<figure class="wp-block-image"><img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/01/build-a-django-restful-api-on-fedora-2.png" alt="" class="wp-image-24545" /></figure>
<h3>Conclusion</h3>
In this article you’ve learned how to create a basic RESTful API using the Django REST Framework. In the second part of this series, we’ll update this application to use the PostgreSQL database management system, and deploy it in OpenShift.
The source code of the application is available on <a href="https://github.com/cverna/django-rest-framework-todo">GitHub</a>. 

</div>

xSicKxBot