4 ms·

Wouldn't it be wiser to choose a hypermedia format for the API, and then use a generic hypermedia client on whichever platform you like? Then you write just as

by gamache 13y ago

Wouldn't it be wiser to choose a hypermedia format for the API, and then use a generic hypermedia client on whichever platform you like? Then you write just as many client libraries (zero), but the problem of pushing updates to your clients is solved as well. Full disclosure: I wrote such a library for Ruby, called HyperResource. https://github.com/gamache/hyperresource https://github.com/gamache/hyperresource

sunkarapk 13y ago
I agree its nice to do it that way. But I found that not all APIs use hypermedia format. So, I did it this way. :)
- gamache 13y ago
  Ah, that makes more sense. I was under the impression that Alpaca was targeted at people writing the APIs. Neat tool!
scarmig 13y ago
At risk of writing a vacuous comment but as a supporter of more HN positivity... Damn, HyperResource looks sexy.
- gamache 13y ago
  I appreciate it -- that was kind of the point. :)
rhizome31 13y ago
I've read most of the book RESTful Web APIs, which advocates Hypermedia as a way to stop having to create client-specific libraries for each and every Web API. But the book doesn't say much about creating such clients. Is there such a generic Hypermedia client for Python? How does this affects performance? Navigating through the maze of a Hypermedia API requires many more requests than just hitting a known endpoint, doesn't it? Do hypermedia clients provide client-side caching? My other concern is that those APIs might be harder to learn than ad hoc fiat standard. The reason why RESTful-ish APIs have been successful is because they don't add any overhead on top of the things they're representing. At first glance, stuff like JSON-LD, Siren, HAL, etc. seem to be bringing back the complexity of things like SOAP that people have fled from.
- steveklabnik 13y ago
  Yup, this is largely the year of the client. > Python? There are some libraries, expect more to spring up soon. > How does this affect performance? This kind of question is incredibly broad. In ways it's more efficient, in ways it's less. It Depends. That said, as you alluded to, caching should be very prevalent, so that helps. Also, it's not like you have to make 5 requests any time you want to do anything: the point is that you follow the application's state along. Just one request per transition. A maze is a pretty decent analogy, actually... > harder to learn than an ad hoc fiat standard They may _seem_ harder to learn, but you have to re-learn every single ad-hoc standard over and over and over and over. If you learn HAL, you can speak to any number of APIs that use HAL. Plus, you say 'complexity,' I say, 'no surprises.' Everything is actually enumerated for you, so it should be easier to learn. No hidden assumptions. Furthermore, as you're more familiar with the format, the details fade into the background. I'm sure you don't read RFC 4627 every time you want to deal with a JSON-based API, either.
- gamache 13y ago
  The client space is slowly filling in. There are a bunch of clients which still leave the plumbing exposed (a couple good ones are HyperClient.rb[1] and HyperAgent.js[2]) -- it still feels like you're making HTTP requests. One of the things I like most about hypermedia is that the hyperlinks can represent a complete set of functions which can be applied to an object. In other words, each object contains its own method list. This fits well in languages which get to implement catch-all methods, like Ruby, and I couldn't resist coding up a client that worked that way. (There's room for this sort of trickery in near-future ECMAScript too, with Proxy[3]. I would really like someone to do this and I would kind of like it to not be me.) When you lay out your API according to that philosophy, and cache a few "stepping-stone" objects you'll be traversing often, hypermedia APIs don't seem so inefficient at all. As to your last point: take a look at HAL[4]. It sits alongside a "traditional" API layout very nicely, essentially adding "_links" and "_embedded" which can be safely ignored by non-hypermedia clients. The HAL spec is extremely sane. [1] https://github.com/codegram/hyperclient https://github.com/codegram/hyperclient [2] http://weluse.github.io/hyperagent/ http://weluse.github.io/hyperagent/ [3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [4] http://stateless.co/hal_specification.html http://stateless.co/hal_specification.html

by gamache 13y ago

sunkarapk 13y ago

I agree its nice to do it that way. But I found that not all APIs use hypermedia format. So, I did it this way. :)

gamache 13y ago
Ah, that makes more sense. I was under the impression that Alpaca was targeted at people writing the APIs. Neat tool!

scarmig 13y ago

At risk of writing a vacuous comment but as a supporter of more HN positivity... Damn, HyperResource looks sexy.

gamache 13y ago
I appreciate it -- that was kind of the point. :)

rhizome31 13y ago

I've read most of the book RESTful Web APIs, which advocates Hypermedia as a way to stop having to create client-specific libraries for each and every Web API. But the book doesn't say much about creating such clients. Is there such a generic Hypermedia client for Python? How does this affects performance? Navigating through the maze of a Hypermedia API requires many more requests than just hitting a known endpoint, doesn't it? Do hypermedia clients provide client-side caching? My other concern is that those APIs might be harder to learn than ad hoc fiat standard. The reason why RESTful-ish APIs have been successful is because they don't add any overhead on top of the things they're representing. At first glance, stuff like JSON-LD, Siren, HAL, etc. seem to be bringing back the complexity of things like SOAP that people have fled from.

steveklabnik 13y ago
Yup, this is largely the year of the client. > Python? There are some libraries, expect more to spring up soon. > How does this affect performance? This kind of question is incredibly broad. In ways it's more efficient, in ways it's less. It Depends. That said, as you alluded to, caching should be very prevalent, so that helps. Also, it's not like you have to make 5 requests any time you want to do anything: the point is that you follow the application's state along. Just one request per transition. A maze is a pretty decent analogy, actually... > harder to learn than an ad hoc fiat standard They may _seem_ harder to learn, but you have to re-learn every single ad-hoc standard over and over and over and over. If you learn HAL, you can speak to any number of APIs that use HAL. Plus, you say 'complexity,' I say, 'no surprises.' Everything is actually enumerated for you, so it should be easier to learn. No hidden assumptions. Furthermore, as you're more familiar with the format, the details fade into the background. I'm sure you don't read RFC 4627 every time you want to deal with a JSON-based API, either.
gamache 13y ago
The client space is slowly filling in. There are a bunch of clients which still leave the plumbing exposed (a couple good ones are HyperClient.rb[1] and HyperAgent.js[2]) -- it still feels like you're making HTTP requests. One of the things I like most about hypermedia is that the hyperlinks can represent a complete set of functions which can be applied to an object. In other words, each object contains its own method list. This fits well in languages which get to implement catch-all methods, like Ruby, and I couldn't resist coding up a client that worked that way. (There's room for this sort of trickery in near-future ECMAScript too, with Proxy[3]. I would really like someone to do this and I would kind of like it to not be me.) When you lay out your API according to that philosophy, and cache a few "stepping-stone" objects you'll be traversing often, hypermedia APIs don't seem so inefficient at all. As to your last point: take a look at HAL[4]. It sits alongside a "traditional" API layout very nicely, essentially adding "_links" and "_embedded" which can be safely ignored by non-hypermedia clients. The HAL spec is extremely sane. [1] https://github.com/codegram/hyperclient https://github.com/codegram/hyperclient [2] http://weluse.github.io/hyperagent/ http://weluse.github.io/hyperagent/ [3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [4] http://stateless.co/hal_specification.html http://stateless.co/hal_specification.html