3 ms·

Maybe you're right, I don't know. What do you think why are technologies like React, GraphQL and NextJS growing their communities while hypermedia seems to be a

Maybe you're right, I don't know. What do you think why are technologies like React, GraphQL and NextJS growing their communities while hypermedia seems to be a niche thing? These frameworks are bloated and add a lot of potentially unnecessary JavaScript to we apps. At the same time developers seem to like the developer experience and trade this with a better technology like e.g. hypermedia APIs. Is it the usability? Lack of tools? Your tool seems to be thought out well. What's preventing it from becoming mainstream?

recursivedoubts 5y ago
it's a complex story, but here are some reasons: - HTML by itself had usability issues that were addressable only with javascript - REST/HATEOAS got lost in the morass of JSON APIs, which isn't a natural hypermedia, and none of the thought leaders came out strongly for hypermedia or even really pointed out what was going wrong - Developers tend to prefer RPC over Hypermedia because it is closer to their natural way of thinking - FAANG-chasing - Developers generally don't like saying "this is too complicated" because it sounds close to "I am not smart enough." Hypermedia is too good an idea to die completely, and I think we'll see a swing back. But in the meantime, a huge amount of time and energy has been and is going to continue to be wasted on rube goldberg contraptions to make "forms talk to databases".
- dionian 5y ago
  Complication leads to higher cost of ownership, including training the junior devs who inevitably wind up maintaining the thing
- halostatue 5y ago
  I’ve implemented hypermedia APIs before. It was a lot of work for exactly zero benefit because none of the client developers wanted what they were given in those APIs, and we were forced to develop _additional_ APIs that gave the client developers something they felt comfortable working with.
  - recursivedoubts 5y ago
    Were the hypermedia APIs returning HTML or some other real hypermedia? I assume not. Were they consumed by a hypermedia client? I assume not, since there is nothing to complain about except compliance with the hypermedia specification in question. Hypermedia APIs never made sense once we flipped to JSON apis, it was all cargo cult. I've written some essays on this: https://intercoolerjs.org/2016/01/18/rescuing-rest.html https://intercoolerjs.org/2016/01/18/rescuing-rest.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...
    - halostatue 5y ago
      Your premise about “HTML or some other real hypermedia” is bunkum. There is nothing about REST or HATEOAS that depends on HTML at all. The whole _point_ of REST was to build on the semantics of HTTP without regard for the transport protocol or encoding format (and HTML, XML, and JSON are all encoding formats). What makes a RESTful API a HATEOAS API is that it provides you actionable hypermedia definitions. There is fundamentally no difference between: <link rel="self" href="https://my.server.example/api/customer/id/1"> and { "link": { "self": "https://my.server.example/api/customer/id/1" } } When you include child responses, you include reachable endpoints for them, too. { "link": { /* top-level item refs */ }, "posts": { "link": { /* post collection level refs */ }, "items": [ { "link": { /* post level refs */ }, /* the rest of the object */ }, /* more objects */ ] } } And yes, in fact, that is _exactly_ what the API that I developed did—so every application client that worked against the API was required to work based on that (and it made making Postman collections really interesting, because you could not just “guess” at the URL required, you had to look it up through the chain). It worked. While it felt nicer from a “purity” standpoint, it made the server slower, less agile to client requirements. We eventually abandoned it as a mistake in the next generation platform that we built. There are a lot of good things about REST, and I like the idea of having discoverable APIs as expected in HATEOAS. But the number of people who _get_ it on the client development side is vanishingly small, and there’s always unfortunate drift where you get people templating API URLs even though they are given the exact API URL required to perform an operation. These days, I’d much rather write up a good GraphQL API with Absinthe and just get the job done rather.

recursivedoubts 5y ago

it's a complex story, but here are some reasons: - HTML by itself had usability issues that were addressable only with javascript - REST/HATEOAS got lost in the morass of JSON APIs, which isn't a natural hypermedia, and none of the thought leaders came out strongly for hypermedia or even really pointed out what was going wrong - Developers tend to prefer RPC over Hypermedia because it is closer to their natural way of thinking - FAANG-chasing - Developers generally don't like saying "this is too complicated" because it sounds close to "I am not smart enough." Hypermedia is too good an idea to die completely, and I think we'll see a swing back. But in the meantime, a huge amount of time and energy has been and is going to continue to be wasted on rube goldberg contraptions to make "forms talk to databases".

dionian 5y ago
Complication leads to higher cost of ownership, including training the junior devs who inevitably wind up maintaining the thing
halostatue 5y ago
I’ve implemented hypermedia APIs before. It was a lot of work for exactly zero benefit because none of the client developers wanted what they were given in those APIs, and we were forced to develop _additional_ APIs that gave the client developers something they felt comfortable working with.
- recursivedoubts 5y ago
  Were the hypermedia APIs returning HTML or some other real hypermedia? I assume not. Were they consumed by a hypermedia client? I assume not, since there is nothing to complain about except compliance with the hypermedia specification in question. Hypermedia APIs never made sense once we flipped to JSON apis, it was all cargo cult. I've written some essays on this: https://intercoolerjs.org/2016/01/18/rescuing-rest.html https://intercoolerjs.org/2016/01/18/rescuing-rest.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...
  - halostatue 5y ago
    Your premise about “HTML or some other real hypermedia” is bunkum. There is nothing about REST or HATEOAS that depends on HTML at all. The whole _point_ of REST was to build on the semantics of HTTP without regard for the transport protocol or encoding format (and HTML, XML, and JSON are all encoding formats). What makes a RESTful API a HATEOAS API is that it provides you actionable hypermedia definitions. There is fundamentally no difference between: <link rel="self" href="https://my.server.example/api/customer/id/1"> and { "link": { "self": "https://my.server.example/api/customer/id/1" } } When you include child responses, you include reachable endpoints for them, too. { "link": { /* top-level item refs */ }, "posts": { "link": { /* post collection level refs */ }, "items": [ { "link": { /* post level refs */ }, /* the rest of the object */ }, /* more objects */ ] } } And yes, in fact, that is _exactly_ what the API that I developed did—so every application client that worked against the API was required to work based on that (and it made making Postman collections really interesting, because you could not just “guess” at the URL required, you had to look it up through the chain). It worked. While it felt nicer from a “purity” standpoint, it made the server slower, less agile to client requirements. We eventually abandoned it as a mistake in the next generation platform that we built. There are a lot of good things about REST, and I like the idea of having discoverable APIs as expected in HATEOAS. But the number of people who _get_ it on the client development side is vanishingly small, and there’s always unfortunate drift where you get people templating API URLs even though they are given the exact API URL required to perform an operation. These days, I’d much rather write up a good GraphQL API with Absinthe and just get the job done rather.