4 ms·

Because it's doesn't have general access to a broad network of different sites/applications it's not a hypermedia client. It's a client for a single service th

Because it's doesn't have general access to a broad network of different sites/applications it's not a hypermedia client. It's a client for a single service that uses hypermedia is an implementation detail. An HTML client that can only view Facebook is not a browser, it's a Facebook client. The point of the article is about how REST should contain all the information needed to traverse a service. But hyperview is for a building a single client/server application where the developers always know the entire interface. So that is the way that it's irrelevant to the discussion.

recursivedoubts 4y ago
I dunno man, I don't see anything about "a broad network of different sites" requirement here: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_7 https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... A hyperview-based application has the exact same defining characteristic of a RESTful web application: there is a single URL that is entered, and beyond that all actions are afforded through hypermedia controls. All the information needed to traverse the service is encoded in responses, and no knowledge of the entire interface is needed by the client. Seems relevant to me. I certainly agree it isn't a general purpose browser, but web browsers are only an instance of a hypermedia client, not the definition of one.
- wvenable 4y ago
  If, instead of text markup, the server just sent an image of the entire UI remote-desktop style how would it be any different? You could still have a single URL that is entered, all information needed to traverse the service can be encoded in the request/responses, and no knowledge of the entire interface is needed by the client. But we have diverged pretty far from the point. Software clients using REST APIs cannot use the self-describing nature of REST so to claim they're all using it incorrectly I don't believe is a valid criticism. Browser-like clients, and you can include hyperview in that, can use the self-describing nature because they're pushing all the understanding to the user. But that is such a niche experience (outside of HTML browsers) that it isn't even worth discussing. For hyperview, it's not consuming generic REST APIs -- it's just acting as mobile-specific browser for a single service. That's why I said it's not really interesting.
  - recursivedoubts 4y ago
    I don't understand why something being "niche" or "not really interesting" has any relevance when asking if it is a hypermedia technology. 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". I dunno, I'm probably not smart enough to understand what you mean. In my mind, if it satisfies the constraints outlined by Fielding in Chapter 5 of his dissertation, it's a RESTful network architecture, and, as far as I can see, hyperview satisfies those constraints. Maybe you can simplify it for me and point to the specific constraint in there that hyperview doesn't satisfy? Again, I'm sorry to be so dense.
    - wvenable 4y ago
      > 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.
      - recursivedoubts 4y ago
        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_transfer 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.

recursivedoubts 4y ago

I dunno man, I don't see anything about "a broad network of different sites" requirement here: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_7 https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... A hyperview-based application has the exact same defining characteristic of a RESTful web application: there is a single URL that is entered, and beyond that all actions are afforded through hypermedia controls. All the information needed to traverse the service is encoded in responses, and no knowledge of the entire interface is needed by the client. Seems relevant to me. I certainly agree it isn't a general purpose browser, but web browsers are only an instance of a hypermedia client, not the definition of one.

wvenable 4y ago
If, instead of text markup, the server just sent an image of the entire UI remote-desktop style how would it be any different? You could still have a single URL that is entered, all information needed to traverse the service can be encoded in the request/responses, and no knowledge of the entire interface is needed by the client. But we have diverged pretty far from the point. Software clients using REST APIs cannot use the self-describing nature of REST so to claim they're all using it incorrectly I don't believe is a valid criticism. Browser-like clients, and you can include hyperview in that, can use the self-describing nature because they're pushing all the understanding to the user. But that is such a niche experience (outside of HTML browsers) that it isn't even worth discussing. For hyperview, it's not consuming generic REST APIs -- it's just acting as mobile-specific browser for a single service. That's why I said it's not really interesting.
- recursivedoubts 4y ago
  I don't understand why something being "niche" or "not really interesting" has any relevance when asking if it is a hypermedia technology. 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". I dunno, I'm probably not smart enough to understand what you mean. In my mind, if it satisfies the constraints outlined by Fielding in Chapter 5 of his dissertation, it's a RESTful network architecture, and, as far as I can see, hyperview satisfies those constraints. Maybe you can simplify it for me and point to the specific constraint in there that hyperview doesn't satisfy? Again, I'm sorry to be so dense.
  - wvenable 4y ago
    > 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.
    - recursivedoubts 4y ago
      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_transfer 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.