Earlier quoted context omitted.
> You assert that "it's not consuming generic REST APIs" but that's exactly what it is doing as far as I can tell, unless you define "generic" to mean "HTML". It's not consuming a weather API or a storage API or a query API. It's consuming an API designed exactly for the singular application that is being designed. It's not distributed except in the sense that it is a client/server application but it's tightly couple…
But it isn't coupled, that's the whole point: hyperview provides a general, mobile-centric hypermedia that embeds hypermedia controls in exactly the manner that fielding describes. (sorry, I'm going to keep referring to that since that's where the definition comes from.) Until you can show me a REST constraint that it is violating, rather than vague assertions like "an API designed for the singular application", I'm…
I never said hyperview isn't RESTful. In fact, it's probably one of the few examples of a technology that follows the REST principles to the letter you're advocating for and thus why you used it as example.
Yet it's also an example of the lack of necessity of the uniform interface constraint. As the developer of everything in the application, I don't need metadata to describe the resources or self-descriptive messages. It describes everything, I as the developer, would already know. It's pointless.
Regular software clients that aren't "browsers" like hyperview, the self-description metadata don't help there either.
So I guess I'm saying the whole uniform interface constraint is completely misguided for any software that isn't some kind of browser. And then only if that browser is actually meant to be a browser.