“MoundMusic” REST API
Source: GitHub Repository
Live At: AWS EC2 instance
An implementation of a RESTful API using django and django-rest-framework, this self-teaching exercise is designed to serve as a backend to a discography website akin to discogs.com and musicbrainz.org. It’s backed by a Postgres database, and it mediates CRUD access to that db through 5 endpoint collections: /albums, /artists, /songs, /genres and /users.
Each endpoint collection supports creation, reading, updating and deletion of records. The first four also support associating records of other types. The /users endpoint also supports password authentication, and subordinate buyer_account and seller_account endpoint collections backing a used CD marketplace akin to discogs.com.
The package was containerized using Docker, and composed alongside a postgres 14.5 image and a pgadmin image. The project comes 1,356 sloc of Python 3 not counting tests, migrations, or boilerplate. Implementation details below. Some screencaps:
The / endpoint of the API, which lists all the endpoints, the methods they accept, and a brief docstring for each
The output of GET /albums
The output of POST /users/19/password
The output of DELETE /albums/380
moundmusic.views
The / endpoint of the API accepts the GET method, and returns a lengthy JSON object associating all the endpoints in the API with documentary objects. (See 1st screencap, above.)
Each endpoint property associates to an object that associates all the HTTP methods that endpoint accepts with documentary strings that describe in brief that endpoint’s behavior when addressed using that HTTP method.
moundmusic.viewutils
To avoid copying & pasting code between a large number of samey endpoints handling different record types in the same way, I implemented a collection of higher-order functions which I stored in this module file.
Each accepts one or more model classes and their associated primary key columns, optionally plus a bridge table model class. It returns a closure: a cookie-cutter endpoint function that handles those data types. The large majority of endpoints are implemented using such closures, enabling code reuse throughout the application.
Dockerfile, docker-compose.yml
The package is containerized using docker, and is running as a container on AWS (see link in header). The containerization of the django app is based on a python:3.9-slim-buster image, and apt-get installs libpq-dev gcc postgresql-common to support the psycopg2 needed by django to address the postgres instance.
The docker-compose.yml file brings in a postgres:14.5 image and a pgadmin image to support the database. To initialize the db and load the testing data (generated using faker), the scripts in the postgres directory are loaded as initialization scripts.