> This kind of thing sounds great for exploratory development, but undesirable (for the reasons I outlined previously) for an actual production app.
We actually do this in our production app. The only URL we actually hardcode in the app is the root URL for the account currently logged into. (And a few other urls unrelated to the account, but that's honestly just pure laziness).
User logs in - we get the account (root resource)
Bootstrap the JS - we get a subresource of the account and request it, populating the initial UI
User interacts with UI - generates a GET to a URL we got from another resource, repopulates the UI with relevant data from that resource. Rince, repeat.
Doing this has made changing our API structure over the course of development a lot easier.
> I hope you're used to waiting :).
I am :). But I look at how much faster html5 went from concept to production because it was pushed by the browsers, and I experience an $optimism++. Things are moving in the right direction, IMO.
We actually do this in our production app. The only URL we actually hardcode in the app is the root URL for the account currently logged into. (And a few other urls unrelated to the account, but that's honestly just pure laziness).
User logs in - we get the account (root resource)
Bootstrap the JS - we get a subresource of the account and request it, populating the initial UI
User interacts with UI - generates a GET to a URL we got from another resource, repopulates the UI with relevant data from that resource. Rince, repeat.
Doing this has made changing our API structure over the course of development a lot easier.
> I hope you're used to waiting :).
I am :). But I look at how much faster html5 went from concept to production because it was pushed by the browsers, and I experience an $optimism++. Things are moving in the right direction, IMO.