Building a RESTful Ajax App using Dojo and Python Werkzeug (part 1)

In the next series of posts I'll describe the complete process of creating a small RESTful Ajax application. The web application developed is a minimalistic task list - check it out here. The process is decomposed into three steps:

• defining the architecture;
• implementing a RESTful back-end web service; and
• implementing a front-end Ajax web service client

Why choose a a RESTful Ajax architecture?

Traditionally, in server-side Web applications, a client's request results in a server crafting and returning an HTML page. Ajax, however, allows for putting the logic of crafting web pages on the client, and lets the server handle pure business logic. The approach has several advantages:

• the server is relieved of compositioning web pages;
• the presentation of data at the client is separated from the producer of it;
• the web application can be made more rich and responsive; and
• it's possible to apply an optimal caching strategy for each type of component.

Most server-side applications that customize pages violate the REST architectural style of statelessness: application state - facilitated by cookies - is put on the server in order to create customized pages. In addition, customized pages apply a lowest common denominator caching strategy in terms of components on the page to avoid stale content. A significant advantage of Ajax is that it can circumvent the problem of customization by placing application state where it belongs in terms of REST: in the client!

To recap, there are many benefits when an application adher to the Ajax architectural style. On the flip side, usually, the complexity of the code is a lot higher when using Ajax. The next two blog post shows how to reduce that complexity by leveraging the Dojo Toolkit, for the front-end, and Werkzeug, for the back-end. However, first a look at the architecture of the sample application.

Defining the architecture

The application will be a very simple task list that has options to input new tasks, and edit and delete existing ones. Underneath, is depicted a view on the architecture, from, what I call, the resource viewpoint on the architecture.

Resource URI	Action	Business Logic
/tasks/	GET	fetch all tasks.
/tasks/	POST	create a new task from the given representation.
/tasks/{id}	GET	fetch a representation of the specific task.
/tasks/{id}	PUT	replace the the task resource with the given representation.
/tasks/{id}	DELETE	delete the specific task.

The format of representations is JSON - a natural choice since it fits right into JavaScript (and Dojo). An example of a representation for the /tasks/ resource is depicted underneath.

[{
 "id": "1",
 "name": "task 1",
 "startdate": "2011-02-03T12:00:00Z",
 "endtime":   "1970-01-01T12:00:00Z",
 "enddate":   "2011-02-03T12:00:00Z",
 "starttime": "1970-01-01T11:00:00Z"
}]

The start(date|time) and end(date|time) fields in the resource representation are timestamps in ISO 8601 format. Dates in that format are seamlessly parsed by the JavaScript Date constructor. The extra redundant time fields are included to ease interaction with Dojo - the third post in this series shows why.

Good planning is 1/3 of the job done. In the next post we'll look at the implementation of the back-end.