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:
Most of the time, you need only to think about the first activity (writing
against the WebStack API).
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.
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.