Anatomy of a WebStack Application

The simplest way to think of a Web application is as just some code which gets run every time an HTTP request arrives at a specific network address and which produces an HTTP response. Without WebStack, such code often needs to be tailored to the software which causes it to be run, but with WebStack you just need to do this:

  1. Write some application code which uses the WebStack API - this code can be run within any of the supported environments.
  2. Write some simple adapter or "glue" code - this code makes the application work with each of the environments that you want to use and should be much smaller in size than the application code.

Most of the time, you need only to think about the first activity (writing against the WebStack API).

A Very Simple Example

In the simplest case, you just need to produce a Python class which takes this form:
class MyResource:

"This is a resource - something which defines the behaviour of an application."

def respond(self, trans):
[Examine the transaction, decide what the user wants to do.]
[Perform some kind of action with the information supplied.]
[Produce some kind of response which tells the user what happened.]

The parts of the pseudo-code in the above text which aren't valid Python (ie. the bits in square brackets) will use various WebStack API calls to look at what the user specified in the request and to send information back to the user in the response.

WebStack applications consist of resource classes which contain the application code. In the above example, the only thing we need to consider is what our code does, not how resource objects are created and invoked (that is done in the adapter code). In more complicated applications, there may be a need to create our own resource objects explicitly, but this is not particularly interesting to think about at this point - see "Treating the Path Like a Filesystem" for a discussion of multiple resource objects.

Design Considerations

When writing an application, we must consider a number of factors which have an impact on the code (and other things) that we will need to provide as part of the finished product or service.