How should a web application best model their urls when doing Ajax? That is a good question to ask when one wants to fully leverage the power of HTTP and REST. I will here summarize my thoughts so far on this. It is work in progress.
Traditionally the url you entered into a browser was pointing to a specific view onto your application. All that MVC thingie was really hidden into the server implementation (if it was there at all) and only the fully generated view was transmitted as HTTP resource to the client. When done carefully, the caching of HTTP could help you to scale your app in the presents of lots of users. The frequency of updates also is not that high (averaged per user), since new requests are only initiated by human interaction with the browser.
Now with Ajax the browser is active on its own, polling the server for updates and putting a lot more stress onto the whole architecture. If the app still wants to make good use of HTTP, it needs to shift its url design from course grained views for humans into finer grained resources usable to the software in the client.
So what is a good way to model the url space of the application in this scenario?
If you give each and every aspect of your model its own url, the client can poll very fine grained. The price you have to pay are many small requests and, since the requests are interleaved and serialized on the two connections most browser allow to the same server, you have the difficulty to maintain a consistent view a the client.
What do I mean by consistent in this scenario? Well, if the client (and ultimately the human) looks at page of his bank account, we'd want the view of the total money in the account and the view on the individual bookings to match each other. Otherwise you either think you are broke without seeing the latest purchase of your dear one or you see the purchase and think that there is still some money left. No good.
So given the nature of HTTP and its caching, you need all (sub) views of the account view to come from the very same HTTP resource. So a consistent view needs to come from a single resource.
But your web app has multiple pages, each consisting of different sub views and some will most likely use the same views (and related code). So reuse of these sub views is clearly desirable. Ideally, since nothing is as much in flux as a user interface, we would like to make pages by mixing them from a set of well working sub views. Mashing them.
Now there is the catch. If you have one uri U1 which hands out all the data to view A, B and C and another uri U2 which was made for the combination of view X, Y and Z, what do you do if the user interface guys now want to have A, B and Z on the same page? You don't want to touch your application model for that and the cool uris U1 and U2 should not change as well. Do you make a uri U3 which just gives the data for A, B and Z? And if you know that some day you will need U3 and U4 etc., what can you do about it now?
Did someone say indirection
? Well, we could make a url template UT which can generate urls for all possible combination. So UT(A,B,Z) would give the url U3, only that we design for it right from the start. For example http://example.com/model?{aspects} could be the template, so U3 would be something like http://example.com/model?A+B+Z.
Does that makes sense to anyone?