Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future is Hypermedia APIs

emergentone.com

Post reply on HN
Print view View original

51–59 of 59 posts

Re: The Future is Hypermedia APIs

#51

Post by AffableSpatula »

steveklabnik wrote: post #48
mjs wrote: post #47

Earlier quoted context omitted.

Sorry, I don't get what you're responding to. Browsers don't understand hypermedia APIs (or even HAL)--they only grok HTML.

> Browsers don't understand hypermedia APIs (or even HAL)--they only grok HTML. HTML is a hypermedia media type. A server spits it out, the client (a browser) consumes it. A browser is a generic hypermedia API client, for services that expose HTML.

please can we not stretch the definition of hypermedia "API" to include HTML. HTML is a hypermedia type, but it's primarily for representing information for human consumption, so it's not an API in the sense most people understand.. why confuse things?

Re: The Future is Hypermedia APIs

#52

Post by AffableSpatula »

mjs wrote: post #15

A few thoughts: * Mike Kelly (the author of the HAL spec) is not aiming for a universal API client http://news.ycombinator.com/item?id=4949357 (and also seems to be under the impression that no-one else is either). * A universal client seems impossible because APIs will typically need to use service-specific link relations for all "interesting" relations (e.g. product, author). You might be able to share generic link…

Why would you want to write a dashboard from scratch every time? Foxycart used HAL for their API, and when they'd finished they pointed the browser at it and instantly had a browsable API.. for free.

Re: The Future is Hypermedia APIs

#53

Post by steveklabnik »

AffableSpatula wrote: post #51
steveklabnik wrote: post #48

Earlier quoted context omitted.

> Browsers don't understand hypermedia APIs (or even HAL)--they only grok HTML. HTML is a hypermedia media type. A server spits it out, the client (a browser) consumes it. A browser is a generic hypermedia API client, for services that expose HTML.

please can we not stretch the definition of hypermedia "API" to include HTML. HTML is a hypermedia type, but it's primarily for representing information for human consumption, so it's not an API in the sense most people understand.. why confuse things?

It's not stretching the definition: HTML and the web are where RESTful principles are defined from. They're the OG hypermedia API.

> it's not an API in the sense most people understand

Neither are hypermedia APIs in general.

Re: The Future is Hypermedia APIs

#54

Post by mjs »

steveklabnik wrote: post #49
mjs wrote: post #46

Earlier quoted context omitted.

Oh! If that's the sort of thing we're talking about, then I'm all for it. The proponents of Hypermedia APIs have been saying a lot of vague things about how it will enable automated clients, and I assumed that the clients they had in mind would be able to do something useful with arbitrary APIs. But it's clear from GitHub's API that it will do nothing of the sort: those link relations (and even concepts) are very muc…

> The proponents of Hypermedia APIs have been saying a lot of vague things about how it will enable automated clients, and I assumed that the clients they had in mind would be able to do something useful with arbitrary APIs. Consider a web browser, or an RSS reader. These are generic hypermedia clients that consumer standardized media types. > But it's clear from GitHub's API that it will do nothing of the sort: thos…

RSS is a great example, because about the most sophisticated link relation in RSS is a link. But there seems to be a big difference in kind between what's being suggested for hypermedia APIs and the example of RSS.

With RSS, the client doesn't need to know very much--only one method is supported (GET), it corresponds to a click, and you'll almost always get one media type back (text/html). The IANA define some other generic link relations, but there seems to be a very big gap between generic link relations ("self", "back", and so forth), and application-specific link relations that are necessary for non-trivial apps.

How is GutHub's API useful to hypermedia libraries? A "library" that could be shared between GitHub and a different endpoint would be maybe 10 lines of code? HAL has a bit more structure, but we're talking maybe 100 lines of code. (Versus URI templates, which must be hundreds of lines, and with much more complicated rules.)

Re: The Future is Hypermedia APIs

#55

Post by mjs »

AffableSpatula wrote: post #52
mjs wrote: post #15

A few thoughts: * Mike Kelly (the author of the HAL spec) is not aiming for a universal API client http://news.ycombinator.com/item?id=4949357 (and also seems to be under the impression that no-one else is either). * A universal client seems impossible because APIs will typically need to use service-specific link relations for all "interesting" relations (e.g. product, author). You might be able to share generic link…

Why would you want to write a dashboard from scratch every time? Foxycart used HAL for their API, and when they'd finished they pointed the browser at it and instantly had a browsable API.. for free.

Well, companies seem to like to brand their dashboards, emphasise different aspects and so on. But still, I agree it would be really cool if you could use the same API browser everywhere, to avoid crappy dashboards, and that HAL would could enable that.

How can I point the HAL browser at foxycart's API? Or even see Foxycart's browser? I can only find standard hand-written documentation.

Re: The Future is Hypermedia APIs

#56

Post by steveklabnik »

mjs wrote: post #54
steveklabnik wrote: post #49

Earlier quoted context omitted.

> The proponents of Hypermedia APIs have been saying a lot of vague things about how it will enable automated clients, and I assumed that the clients they had in mind would be able to do something useful with arbitrary APIs. Consider a web browser, or an RSS reader. These are generic hypermedia clients that consumer standardized media types. > But it's clear from GitHub's API that it will do nothing of the sort: thos…

RSS is a great example, because about the most sophisticated link relation in RSS is a link. But there seems to be a big difference in kind between what's being suggested for hypermedia APIs and the example of RSS. With RSS, the client doesn't need to know very much--only one method is supported (GET), it corresponds to a click, and you'll almost always get one media type back (text/html). The IANA define some other…

> But there seems to be a big difference in kind between what's being suggested for hypermedia APIs and the example of RSS.

Well, RSS is just a simple example: its domain is small. Which is why it's nice to talk about. If you need bigger and more powerful things, than stuff gets complicated.

> With RSS, the client doesn't need to know very much--only one method is supported (GET),

I should have said ATOM and ATOMpub; it has a slightly more complex edit/delete workflow as well.

> The IANA define some other generic link relations, but there seems to be a very big gap between generic link relations ("self", "back", and so forth), and application-specific link relations that are necessary for non-trivial apps.

Right. The idea is that you use app specific ones at first, then, as you find they're useful and stable, you make them a generic one.

> How is GutHub's API useful to hypermedia libraries?

This is backwards. It's more like "how are hypermedia libraries useful for implementing the GitHub API."

Re: The Future is Hypermedia APIs

#57

Post by AffableSpatula »

steveklabnik wrote: post #53
AffableSpatula wrote: post #51

Earlier quoted context omitted.

please can we not stretch the definition of hypermedia "API" to include HTML. HTML is a hypermedia type, but it's primarily for representing information for human consumption, so it's not an API in the sense most people understand.. why confuse things?

It's not stretching the definition: HTML and the web are where RESTful principles are defined from. They're the OG hypermedia API. > it's not an API in the sense most people understand Neither are hypermedia APIs in general.

I know where REST came from, my point is that - as far as normal people are concerned - HTML web apps are.. apps.. not APIs.

Re: The Future is Hypermedia APIs

#58

Post by mjs »

steveklabnik wrote: post #56
mjs wrote: post #54

Earlier quoted context omitted.

RSS is a great example, because about the most sophisticated link relation in RSS is a link. But there seems to be a big difference in kind between what's being suggested for hypermedia APIs and the example of RSS. With RSS, the client doesn't need to know very much--only one method is supported (GET), it corresponds to a click, and you'll almost always get one media type back (text/html). The IANA define some other…

> But there seems to be a big difference in kind between what's being suggested for hypermedia APIs and the example of RSS. Well, RSS is just a simple example: its domain is small. Which is why it's nice to talk about. If you need bigger and more powerful things, than stuff gets complicated. > With RSS, the client doesn't need to know very much--only one method is supported (GET), I should have said ATOM and ATOMpub;…

> Right. The idea is that you use app specific ones at first, then, as you find they're useful and stable, you make them a generic one.

Ok, but do you think there will will ever be a generic definition of "user" or "product" or "photo" that can access the full experience of e.g. Amazon, Google, Facebook, Flickr and GitHub?

Regarding Atom, Google adopted a extended version of Atom in for some (but not all) of their products, but no-one else adopted it in almost a decade, and Google are now deprecating it. (I'm sort of blurring the difference between link relations and media types, but they seem entwined.)

URIs and shared media types are great for interoperability, but my guess (we'll see if it comes true) is that pretty much anything beyond that isn't going to get traction. Hypertext was around before the web, but I think a big reason it took off is because had very loose interoperability demands. (e.g. links can break.)

Re: The Future is Hypermedia APIs

#59

Post by BerislavLopac »

steveklabnik wrote: post #50
BerislavLopac wrote: post #45

Earlier quoted context omitted.

"The developers I was working with also had a lot of trouble with REST. I had to explain repeatedly what PUT, DELETE, GET and POST were (they weren't really familiar with HTTP at all), and that they weren't doing RPC calls." You should try using the SQL analogy instead of RPC, as this is much closer to what a "traditional" developer might expect. With REST, one is not doing a procedure call, but one is querying to cr…

HTTP verbs do not map exactly to CRUD.

Of course they don't; but that's good enough for giving an intro to a "traditional" developer.
Post reply on HN