3 ms·

> Never having to build a URL by hand is great! Being able to just grab a field from a resource, and go do a GET on its value is very easy to code, even if that

by notJim 14y ago

> Never having to build a URL by hand is great! Being able to just grab a field from a resource, and go do a GET on its value is very easy to code, even if that process involves finding a link with a certain relation. You speak of complexity, and I'm speaking of convenience. This kind of thing sounds great for exploratory development, but undesirable (for the reasons I outlined previously) for an actual production app. > That sounds like a great day to me. I hope you're used to waiting :).

steveklabnik 14y ago
> This kind of thing sounds great for exploratory development, but undesirable (for the reasons I outlined previously) for an actual production app. For example production apps, see this comment, and the one it links to: http://news.ycombinator.com/item?id=4950877 http://news.ycombinator.com/item?id=4950877 (Ohhh, hypermedia. ;) )
Milagre 14y ago
> 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.

by notJim 14y ago

steveklabnik 14y ago

> This kind of thing sounds great for exploratory development, but undesirable (for the reasons I outlined previously) for an actual production app. For example production apps, see this comment, and the one it links to: http://news.ycombinator.com/item?id=4950877 http://news.ycombinator.com/item?id=4950877 (Ohhh, hypermedia. ;) )

Milagre 14y ago

> 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.