But what I really see as the main advantage is the decoupling of server and UI, kind of like Android Intents on steroids. By using standard formats and dynamic routes between them, the user is no longer tied to a silo with a window through which they can interact with their data; they can know use his own chosen software to handle the different types of information, jumping through them as needed, without ever being locked-in to a particular provider.
And for the developers, why are we building the same crap again and again using the API du-jure, when 90% of it uses the same concepts as existing software? Why do we need thousands of libraries and middleware that provides a "single API to many services"? We spend so much effort building these rickety integrations, just because the providers insist on using different names for the same things.
The issue is that most vendors don't want to converge on a standard. Stuff would be fine if that standard wasn't properly RESTful, as long as it was a standard, but many arguments towards RESTful IMHO present the benefits we would get from any standard as the benefits we would (only) get from a RESTful standard.
I agree that the current situation is crappy. I agree that HATEOAS/REST ideas implemented properly and with the intend to cooperate would help a lot, and that there are many worse candidates for a standard.
I disagree that HATEOAS/REST would matter that much, compared to the "implemented properly and with the intend to cooperate".
