3 ms·

Having worked with hypermedia APIs recently I've come to appreciate how they feel more pragmatic and REST more pedantic. The hateos principle in particular lets

Having worked with hypermedia APIs recently I've come to appreciate how they feel more pragmatic and REST more pedantic. The hateos principle in particular lets you build thinner clients.

JimDabell 11y ago
Isn't "hypermedia API" just a new name some people came up with for "REST API" because the misunderstood non-HATEOAS mangling of REST is so common and they wanted to distinguish between the two? Real REST APIs use HATEOAS.
- steveklabnik 11y ago
  Yes. Strictly speaking, you can use hypermedia without REST, too. But that's the lineage of the last few years of what people are talking about.
  - encoderer 11y ago
    So I'm a so-called "full stack engineer" and the definition I've internalized is that a REST api is essentially about modeling the entities in your application and defining what actions can be taken on each (with consistent use of verbs). And a "hypermedia api" approach is more about modeling behavior. As an example, an api for AirBnB's mobile website might expose a /srp endpoint that can be used by a thin client to render the results recursively. Again, the way I've internalized it, to be a REST api I'd expect a client to request results from a /listings endpoint of some kind. I think there is a lot of confusion and misunderstanding and that precise language is better for everybody. What should we be calling these things? I'd love your thoughts on it.
    - steveklabnik 11y ago
      Your intuition is very good, and gets very close to the heart of the matter. I think that the true heart of the hypermedia approach is actually "how do I deal with change over long periods of time in a scalable fashion?" Everything else flows from this. Exposing behaviors instead of data is one facet of the approach. > What should we be calling these things? Which 'these' are you referring to?

3 ms·

Having worked with hypermedia APIs recently I've come to appreciate how they feel more pragmatic and REST more pedantic. The hateos principle in particular lets

by encoderer 11y ago

Having worked with hypermedia APIs recently I've come to appreciate how they feel more pragmatic and REST more pedantic. The hateos principle in particular lets you build thinner clients.

JimDabell 11y ago
Isn't "hypermedia API" just a new name some people came up with for "REST API" because the misunderstood non-HATEOAS mangling of REST is so common and they wanted to distinguish between the two? Real REST APIs use HATEOAS.
- steveklabnik 11y ago
  Yes. Strictly speaking, you can use hypermedia without REST, too. But that's the lineage of the last few years of what people are talking about.
  - encoderer 11y ago
    So I'm a so-called "full stack engineer" and the definition I've internalized is that a REST api is essentially about modeling the entities in your application and defining what actions can be taken on each (with consistent use of verbs). And a "hypermedia api" approach is more about modeling behavior. As an example, an api for AirBnB's mobile website might expose a /srp endpoint that can be used by a thin client to render the results recursively. Again, the way I've internalized it, to be a REST api I'd expect a client to request results from a /listings endpoint of some kind. I think there is a lot of confusion and misunderstanding and that precise language is better for everybody. What should we be calling these things? I'd love your thoughts on it.
    - steveklabnik 11y ago
      Your intuition is very good, and gets very close to the heart of the matter. I think that the true heart of the hypermedia approach is actually "how do I deal with change over long periods of time in a scalable fashion?" Everything else flows from this. Exposing behaviors instead of data is one facet of the approach. > What should we be calling these things? Which 'these' are you referring to?