undefined | Better HN

0 pointswvenable3y ago0 comments

> 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 coupled to a singular implementation. A completely different environment to what the entire paper is about.

You've responded to literally the least interesting part of my comment as even accepting hyperview as a hypermedia technology doesn't negate any of the criticism of "by the book" REST. I may be guilty of caring more about whether REST as described is practical and possible then appealing to the authority of Fielding's definitions.

0 comments

3 comments · 1 top-level

recursivedoubts3y ago· 2 in thread

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 not going to grant you that the technology isn't RESTful. Any web app can have "an API designed for that singular application." I can link out to other sites, but it doesn't have to, and the fact that it does or doesn't isn't material to whether or not it is ReSTful. If it has identification of resources, manipulation of resources, self-descriptive messages and uses Hypermedia As The Engine of Application State, it's RESTful.

Here you go:

https://en.wikipedia.org/wiki/Representational_state_transfe...

Pretty simple, just show me the constraint violated by hyperview and I'll agree with you. I don't know if HyperView provides Code On Demand, but that's an optional constraint of REST, if I understand correctly.

wvenableOP3y ago

You make a good argument but it's unfortunately not in response to anything I'm saying.

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.

recursivedoubts3y ago

OK, then that's the core disagreement: I think the uniform interface and the benefits of a RESTful network architecture are useful even if the software you are using isn't a "browser". In the case of hyperview, a major benefit is that you can update your mobile application without redeploying the client, exactly because of that uniform interface. That's why the creator went with the RESTful approach over a more traditional mobile app network architectures.

1 more reply

j / k navigate · click thread line to collapse