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

71–76 of 76 posts

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

#71

Post by dsl »

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…

If you have programmatically generated code, generating tests is almost completely useless (especially if the same code is generating the tests as well).

A bunch of passing tests shouldn't make you feel comfortable able releasing something to production. Proper code review and monitoring of client failures on your servers should make you confident.

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

#72

Post by dsl »

CCs wrote: post #69
kimmel wrote: post #63

I like the SPORE (Specification to a POrtable Rest Environment) approach better. You create a description file in JSON and each native language client can use that file to access the HTTP API. https://github.com/SPORE/specifications SPORE already has clients for Clojure, Javascript, Lua, NodeJS, Perl, Python, and Ruby. I have used SPORE in a few projects and I was not disappointed. Another approach to solving the cro…

Looks promising. Too bad the last commit was 2 years ago...

Maybe it is finished?

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

#73

Post by biot »

boomlinde wrote: post #62
biot wrote: post #59

Earlier quoted context omitted.

You're being downvoted because this project is a generator program which, as input, takes a specification of the API in JSON format. This JSON specification is what is being compared to WSDL because they serve the same purpose: to define the endpoints, arguments, and return values for a given API.

I agree with that, but I am correct in pointing out that the scope of this project covers things that WSDL does not, and in that sense it isn't like WSDL. When someone asks a question that can easily be answered in terms of differences I think it's completely reasonable to point those out. Perhaps my parent intended for the question to be rhetorical, with the implied answer being "Yes, I'm silly for reinventing the w…

The comment you replied to said:

  > Right, the format affords generic description documents
  > from which to generate client code. This seems very
  > similar in spirit to WSDL. No?
The word "this" in the second sentence clearly refers to "the format". To reword the parent:

  > The JSON format used by this project seems very similar
  > in spirit to WSDL. No?
So while you're correct that the entirety of the project (JSON format + code generation) is greater in scope than just WSDL, you took exception to a claim the parent did not make. You could equally have said:

  > The JSON format used by this project 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 [the project's code-generating client]
  > decides how to deal with it.
I don't think anyone thought otherwise.

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

#74

Post by rhizome31 »

gamache wrote: post #50
rhizome31 wrote: post #38

Earlier quoted context omitted.

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

Thank you and Steve for your replies.

You both seem to recommend HAL over other Hypermedia formats. In their book, Richardson & Amundsen mention that HAL doesn't allow to tell the client which HTTP methods to use when doing state transitions. They say that HAL is therefore only suited for read-only APIs. What do you think of that?

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

#75

Post by darrelmiller »

rhizome31 wrote: post #74
gamache wrote: post #50

Earlier quoted context omitted.

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

Thank you and Steve for your replies. You both seem to recommend HAL over other Hypermedia formats. In their book, Richardson & Amundsen mention that HAL doesn't allow to tell the client which HTTP methods to use when doing state transitions. They say that HAL is therefore only suited for read-only APIs. What do you think of that?

Link relations can be designed that indicate which HTTP methods are allowed. HAL is heavily dependent on conveying semantics via link relations, which is something that some people don't like doing.

Consider the oauth2-token link relation defined here[1]. The definition of this link relation refers to RFC 6749 [2] which states that it is necessary to pass a application/x-www-form-urlencoded body using POST.

[1] https://tools.ietf.org/html/draft-wmills-oauth-lrdd-07#secti... [2] https://tools.ietf.org/html/rfc6749#section-4.1.3

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

#76

Post by gamache »

rhizome31 wrote: post #74
gamache wrote: post #50

Earlier quoted context omitted.

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

Thank you and Steve for your replies. You both seem to recommend HAL over other Hypermedia formats. In their book, Richardson & Amundsen mention that HAL doesn't allow to tell the client which HTTP methods to use when doing state transitions. They say that HAL is therefore only suited for read-only APIs. What do you think of that?

Formally, they're absolutely right. Information like that is out of band with HAL.

In practice, I deal with it by sticking to HTTP verb conventions and specifying what to do in the documentation.

It's not automatic -- it'd be e.g. rsrc.somelink.post(params) instead of rsrc.somelink(params) in HyperResource's case -- but it works, and any human who knows what the 'somelink' rel is supposed to do might also be expected to know how to use it.

Post reply on HN