Yesterday I did a massive post about separating HTML layout from user data and then using a JavaScript templating engine to bind up JSON data object which contains user-specific information. I also talked about setting the HTTP expiration policy on the HTML files and using CDNs to scale out your web tier without lots of additional hardware.
In thinking about the solution a little bit further it occurred to me that this could facilitate a RESTful layout of both HTML and JSON URLs. Specifically, a sample HTML URL would look like the following:
/account/history
While the corresponding JSON data file would have the following URL:
/account/history.js
Then, through URL rewriting, the JSON file would use the session state identifier in the request to map the a directory on the file system, e.g.:
/
/account/history.js
which would use hard links to map to the real (but hidden) user directory on the server:
/
/account/history.js
I know this sounds like way too much overhead, but as I said before, this solution is not mutually exclusive. You can do this where it makes sense and when you have significant load on certain pages. Elsewhere you can do your traditional request that goes all the way to the server, hits a database, and renders a page.
The last thought that I had was that the JSON files need not be stored on the file system. You could simply expose a cluster of CouchDB instances (with appropriate security controls, of course). The CouchDB instance(s) would be responsible for handling the raw request, mapping the session state to the underling user ID, and then pushing out the appropriate JSON file for the requested view. In this way, you could potentially index the JSON files and make them queryable if you desire.