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

Show HN: Given an API, Generate client libraries in Node, Python, PHP, Ruby

github.com

Post reply on HN
Print view View original

41–50 of 76 posts

Re: Show HN: Given an API, Generate client libraries in Node, Python, PHP, Ruby

#41

Post by memset »

This is cool. I would suggest that it would be very useful to have this kind of thing for JSON Schema [1], which is what I use with Python code to validate incoming JSON. (I was originally hesitant to using that, but since getting into it, I have yet to run into a use case which it cannot handle.)

There is also an RFC for "JSON Hyper Schema" which is intended to describe REST APIs. It doesn't have much library support in much of everything, but I am surprised that it hasn't taken off!

I like that this library is fairly opinionated (options for how to authenticate, supported formats, etc.) Though I worry that that creates a bit of inflexibility - for what exactly does "oauth" actually mean, there are always vagaries.

Neato!

[1] http://json-schema.org/

Re: Show HN: Given an API, Generate client libraries in Node, Python, PHP, Ruby

#43

Post by steveklabnik »

rhizome31 wrote: post #38
gamache wrote: post #25

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

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,…

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.

Re: Show HN: Given an API, Generate client libraries in Node, Python, PHP, Ruby

#44

Post by jxf »

Robin_Message wrote: post #35
jxf wrote: post #15

Just tried this out and Alpaca is an awesome tool. However, I'd never want to release this in production without tests. Alpaca doesn't generate tests, so you're back to maintaining the tests for your N different platforms/languages. But you'd have the same problem with its competitors, too; Thrift [0], for instance, doesn't generate tests either. Overall, I'm not sure that the time savings is as big as it first appea…

I'm confused by this comment. What would the tests test? My thinking is that, if trusted to output a library that matches the API spec, there is no need to test that API. However, that does require that Alpaca is well-tested enough to be trusted - would you be happy with tests in Alpaca itself, or should it generate tests too?

I guess it depends on whether you view Alpaca as (a) "it's a starting point for generating your API", or (b) "it's the authoritative source and the only way to generate your API". If you use it like (b) you don't need tests, but Alpaca does. If you use it like (a) Alpaca still needs tests, but the buck stops with you.

Re: Show HN: Given an API, Generate client libraries in Node, Python, PHP, Ruby

#49

Post by boomlinde »

mikekekeke wrote: post #14
sunkarapk wrote: post #12

Earlier quoted context omitted.

Being a WSDL is not the aim here. Generating client libraries in multiple programming languages is. But, to do that I need a format using which people can define their API. I used JSON and only supported the elements that I needed to generate the client libraries.

Right, the format affords generic description documents from which to generate client code. This seems very similar in spirit to WSDL. No?

WSDL is not a method in itself for actually generating the client code, though. It's simply a (barely) machine readable description of the API from which clients decide how to deal with it.

EDIT: Since I was down-voted for whatever reason, I'd like to rephrase. WSDL is a standardized language for defining web services. It's not a tool in itself for generating client code, and what I said was meant to point out that that's the obvious difference between this and WSDL. A description written in WSDL can both be used to generate client APIs and skeleton code for the server itself, but isn't the generator itself, just like C isn't gcc.

Re: Show HN: Given an API, Generate client libraries in Node, Python, PHP, Ruby

#50

Post by gamache »

rhizome31 wrote: post #38
gamache wrote: post #25

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

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,…

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

[2] http://weluse.github.io/hyperagent/

[3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[4] http://stateless.co/hal_specification.html

Post reply on HN