I sometimes think of microapps in terms of functional programming. URLs can act as functions, with the params passed to them as their arguments. A URL that responds to a GET request idempotently can be thought of as a side-effect free function. Like any good functional programming language, with microapps, functions are first class and composable. Since a URL is conveniently just a string, you can pass it as an argument to other URLs. As long as you're sticking to GET requests where the parameters get stuck onto the URL, you can basically create new "partials", or URLs with some of their parameters already specified that can be passed around in the same way.
The metaphor does sort of break down in one significant way: the microapp/URL model doesn't really have any equivalent to anonymous functions or lambdas. However, the ability of URLs to be constructed fairly arbitrarily often allows some of the same functionality. Instead of having a true lambda, a unique URL can be constructed automatically from a simple pattern or rule (eg, using an autogenerated database row id somewhere in it), which is then pretty close in functionality.
Stepping outside GET requests and pure functional programming, it can still be useful to think of URLs as callbacks. Eg, for a request that's expected to take a long time, instead of making a request and waiting (and blocking) for it to finish, the calling application could instead specify a unique callback URL that it sends along to the server. The server returns immediately with no value but continues to process the request in the background. When it has finished processing the request, it calls the callback URL passing along the result as an argument. (This is basically the Deferred pattern of twisted/mochikit/etc.)