It is time to upgrade Django Packages. If you are using the site's APIs in any way, this affects you.
This site, maintained by myself and Audrey Roy Greenfeld, is the directory of reusable apps, sites, and tools for Django-powered projects. And the site has been running on Django 1.4.x for about 2.5 years. Which in internet years is forever. It's time to upgrade!
Alas, we have a problem.
# The Problem
The first REST API for the project, APIv1 is running on a very old version of django-tastypie (0.9.7) which blocks upgrading the Django version, even to Django 1.5. While we could do a lot of work to migrate upwards to modern django-tastypie, that would require a lot of time that we would rather spend adding new features or making other stuff. More importantly, there are elements to the APIv1's design that we want to change.
While we are on the subject of legacy APIs, the second REST API for the project, the mostly undocumented APIv2, is powered by a relatively old version of Django Rest Framework (2.3.8). The design of APIv2 was a bit of an experiement in architectural design, one whose novel approach (API views mixed into standard HTML views instead of seperated out) was unweildy and ultimately annoying. One might even call it an anti-pattern. That's fine, as sometimes you have to try things in order to determine better approaches for later, but it's time for this version of the API to die.
Our eventual goal is to get Django Packages running on Django 1.8 as well as implementing a brand-new REST API powered by Django Rest Framework. Getting there is the trick. Hence, we've created "The Plan".
# The Plan
We have a four-stage plan for migrating the site upwards:
- On April 2, 2015 we will be turning off APIv1. All endpoints will redirect to APIv3.
- On April 3, 2015, we will be turning off APIv2. All endpoints will stop working.
- On April 4, we commence work on migrating the project to Django 1.8.
- Whenever we finish #3, we start work on APIv4, powered by Django Rest Framework.
# About APIv3
Already implemented, this version of the API is powered by very simple JSON-powered views. Since both APIv1 and APIv2 only have GET endpoints, it was easy to roll something out that provided nearly all the data generated by both previous APIs.
Update 2014/03/01: Clarified the design mistake of APIv2.