I was obviously being flippant, but a long story short is that going to a JSON-based, RPC-style SPA app gives up a lot of the advantages of the original RESTful web network architecture, not the least of which being simplicity.
Long-suffering HN readers can skip all of this (sorry guys) but I expand on this in the following blog posts:
All of these seem to imply discoverability and queries are the biggest pain point in web apps. For me, in creating specific purpose business apps, the biggest headaches are presenting the data in ways that minimize the user's unnecessary actions and, even more of a pain, wiring things up so an event in one location triggers the proper client display changes in another location.
For my use cases, discoverability and ad hoc queries just don't apply.
Mmm, this is probably a long conversation, but I don't disagree with what you are saying. I think discoverability (in API terms) is different than the flexibility that HATEOAS, with a proper hypertext gives you.
The query issue just depends on how complex your data consumption needs are. The closer they get to levels requiring SQL-levels of expressivity, the more you will need to either churn your API or expose expressivity (and security risk) on the browser side.
In the old days, the way we dealt with changing the UI in another location was by simply replacing the whole page. This actually works pretty well, except for those FOUCs, and we are heading back that way, but now people are starting to do DOM diffs to avoid the blinky-blink. intercooler has a few options for solving it as well (either expanding your replacement target or using dependencies.) I imagine eventually I'll end up adding DOM-merging as an option as well.
> I imagine eventually I'll end up adding DOM-merging as an option as well.
This will be nice. I was playing with some of the examples on the site and noticed a number of them tended to "jump" a bit when the response was returned.
For my use cases, discoverability and ad hoc queries just don't apply.