To continue exploring the design of a generic database user interface, let us turn our attention to a web interface. I’ll use the pattern of the Django admin application as the basis for specifying the behavior of a somewhat RESTful web interface for maintaining the movies database I’ve used in previous posts.
The home page (canonically at http://www.example.com/) is comparable to the menu displayed initially by the command line interface (CLI). It will consist of an HTML table listing the logical entities together with options to add a new record (New) or edit an existing one (Edit). For now, the table will include a single entity: a film.
The latter option (or the entity link itself) will take the user to the List Records Page (see below). The New option will go to the
Add Record Page
This will be presented at http://www.example.com/film/new and is comparable to the Add interactions in the CLI. It will have an HTML form with fields (HTML text input or textarea elements) for each attribute and a “Save” button (HTML submit input element). Pressing the button will POST the new data to http://www.example.com/film/create.
List Records Page
This is of course comparable to the CLI List display. It will feature an HTML table listing all films. This is the index page for the entity so its URL will be http://www.example.com/film/.
We’ll worry about pagination later, but when we do the URL will have a query string to select a given page, e.g., http://www.example.com/film/?p=123.
Each row of the HTML table will have a link that leads to the
Record Edit Page
This will have a URL that identifies the film being edited, e.g., http://www.example.com/film/23969, where 23969 corresponds to a value in the id column of the film table in our database. This is equivalent to the CLI Update option.
The Edit page will have the same HTML form as the Add Record page, including the “Save” button, but the POST will go to http://www.example.com/film/save/23969. It will also have a “Delete” link that goes to the
Record Delete Confirmation Page
This will be presented at http://www.example.com/film/delete/23969 and is comparable to the confirmation requested by the CLI Delete. It will display an “Are you sure?” message together with details of the record to be deleted and a button titled “Yes, I’m sure.” The POST will use the same URL as the GET.
Form and Error Handling
Both the Add and Edit pages will validate the data entered. If there are any errors, the respective page will be redisplayed with a message(s) indicating what needs to be corrected. If a “Save” operation succeeds, we’ll redisplay the film listing.
With this specification, if we translate each URL path above into a class method, we can outline a Python class that will act as the handler (or MVC controller, although Django calls this the view layer) for the HTTP requests. Note that the entity index URL (the listing) maps to the index method while the specific entity URL maps to the default method.
class FilmHandler(object): def new(self): "Displays a form to create a new film" pass def create(self, **formdata): "Saves the film submitted from ``new``" pass def index(self): "List all films" pass def default(self, id=None): "Displays a form for editing a film by id" pass def save(self, id=None, **formdata): "Saves the film submitted from ``default``" pass def delete(self, id=None): "Deletes an existing film by id" pass
There are many more details such as the “Model,” i.e., the interface to the database itself, and the MVC View (which Django calls the template layer). So visit again if you’re interested!
Update: Changed title and first paragraph to emphasize that the interface does not adhere strictly to the REST canon. See Oliver Charles’ detailed critique below.