Responding to comments from earlier posts, here are some qualities I think are part of being "on the web".
"hypertext and hyperlinking" - yes. And so Flex/Apollo applications can get resources that have links, can display resources that have links, and can respond to the results of following those links. So that is part of what makes them able to be "on the web".
Flex is a library of Actionscript. Apollo is an extension of that. Those libraries include the ability to do these "on the web" things. These things (and the web itself) can, and will, go *far* beyond what the current browsers can do. Don't get locked into thinking the only true web client is this unfortunately limited web browser you've been using for a decade or so. So yeah, ok.
"bookmarkability" - I don't put this in the "on the web" category per se. Although since Flex/Apollo apps can do linking and link-following then being able to save and recall these in various cirumstances would be useful. And so since they can be "on the web" then they can use bookmarking services that are also "on the web". Other kinds of bookmarking are possible as well, up to and including Apollo's ability to use a local (or other, really) file system. So yeah, ok.
"hypertext as the engine of state" - yes, well this gets back to linking, but the emphasis in this comment seems to be on the "engine" part. Flex/Apollo apps can provide an "engine" very much like a browser is an HTML "engine" or they could be used to implement other kinds of "engines". HTML is not the only fuel for "engines on the web". So yeah, ok.
"view source" - I don't put this in the "on the web" category per se, but it certainly helps the web evolve, so let's include it. Flex/Apollo apps are compiles to binary, but can also provide a "view source" capability if the developer desires. So yeah, ok. I would recommend using this in almost all cases.
But this is similar to "meaningful URIs" - are these required for the web? In some cases opaque URIs are more desirable. The developer gets to choose.