REST over Django

When I read about web-servers the last time, they were different. Back then, a page in the web root (usually the '/var/www' directory) mapped to one URL. For instance a page called "abc.php" mapped to "http://www.example.com/abc.php". For more complicated URLs, you had to tweak your httpd.conf. But that was in the times of PHP. These days, things have changed!


Meet Django - the web-server written in Python. Django brings along a Model-View-Template framework on the server side. The framework can be hooked up with Apache for deployment and also contains a lightweight single threaded web-server for development purpose.

Unlike PHP, a file does not map to a URL here. Instead, a user has to explicitly define all the URLs that the server will respond to in a file called "urls.py". The same file, "urls.py" also maps each URL to a corresponding python function that gets the HTTP-request object coming from the client and returns a HTTP-response object that the user will receive. This function is called a View. So a Hello-World Django setup has one URL mapped to one view function. The function creates a HttpResponse object with "Hello World" and returns it.

Sophisticated web apps have huge responses! One response may include HTML, CSS and a lot of JavaScript. No one would like to keep HTML, CSS or JS files embedded into Python files. Hence Django offers Templates. Templates are special files. Along with HTML or CSS or JS or anything, they can contain embedded "variables" that can be changed by Django at the runtime. For instance, a simple file template.html, containing "Today is {{my_date}}", changes dynamically with values of "my_date". So in the view function, one can call a function similar to:

getResponseFromTemplate ( 'template.html', {"my_date" : datetime.now()})

Not just variables, templates are much more powerful!

A database is another key aspect of a web application. Django abstracts databases behind Models. It requires the user to create the entire database structure (relational or non-relational) in terms of Python classes. It asks the credentials of the actual database to be used in a configuration file and on executing one python file, it populates the database by its own. The beautiful part is that changing from one database to another (say mysql to postgresql) is just a matter of changing the database type! Django hides all the database specific queries behind the model. Yet, if one needs more power, it provides access to raw SQL as well!

So, I have been writing a RESTful web server over Django for the past few days. REST, or Representational State Transfer, is a system design with the following important characteristics:

1. Client-server model: resources required by clients are served by a server
2. A uniform interface between the client and the server; i.e. no coupling
3. A stateless server
4. Cacheable responses

There are a few more traits but we can safely ignore them for now. Unlike SOAP, it's not a protocol. It's just an architecture with guidelines. Implementation of such an architecture is most commonly seen over HTTP.

Django makes it very easy to create a RESTful server. Individual resources that the client is trying to access are configured in urls.py as separate URLs. Each URL is then mapped to a view function which generates the response using templates and the model. Since a REST server is stateless, there is no need for interaction between view functions of multiple URLs. Responses which are not prone to changing very frequently are marked cacheable.

Django gives a lot more power by allowing organisation into hierarchical views, allowing globs in URLs, breaking multiple functionalities into apps, branch and loop constructs in templates, providing ORM over relational and non-relational databases and much more!