Would it be possible to, say, write a definition for the Twilio API in this API description format? That sounds like it would be a wonderful example of its utility.
Show HN: Given an API, Generate client libraries in Node, Python, PHP, Ruby
61–70 of 76 posts
Re: Show HN: Given an API, Generate client libraries in Node, Python, PHP, Ruby
#62Earlier quoted context omitted.
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 t…
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 wheel" in which case the differences between this project and WSDL are an also an obvious defense of it.
Re: Show HN: Given an API, Generate client libraries in Node, Python, PHP, Ruby
#63I 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 cross language library problem.
Re: Show HN: Given an API, Generate client libraries in Node, Python, PHP, Ruby
#64fwiw, I experimented along this line, dynamically generating python wrappers from yaml: https://github.com/reklaklislaw/rest_easy
It lacks documentation, a bunch of features, and parts smell pretty bad, but since the topic came up I thought maybe someone would find it interesting, if only vaguely.
Re: Show HN: Given an API, Generate client libraries in Node, Python, PHP, Ruby
#65oh man you just killed a major feature of mashape.com
Client library generation is something that mashape supports, but currently they generate libraries for:
Java, Node, PHP, Python, Objective-C, Ruby, and .NET
It looks like alpaca supports:
Java, Go, Perl, Clojure, Scala, Obj-C
Re: Show HN: Given an API, Generate client libraries in Node, Python, PHP, Ruby
#66Earlier quoted context omitted.
How do you differ from Swagger, Blueprint, I/O Docs, RAML and all these API endpoint descriptions?
I tried searching for a program which generates client libraries in different programming languages and failed. Could you please link if something does it? From what I gather, the above mentioned sites only provide methods of describing the API and/or Automating the API on the server side. Nothing is said about client libraries. Thanks
There's this utility called swig(http://www.swig.org/) which let you create wrappers for C/C++ libraries to a number of different target languages (dynamic and static), though often time languages offer ffi on their own.
The code generated by this tool is rather heavy weight though. Also I'm not quite sure if this is what you're looking for.
Re: Show HN: Given an API, Generate client libraries in Node, Python, PHP, Ruby
#67Does this use the Json Schema spec or have you reinvented the wheel?
JSON Schema is too complex for this project. I just chose the fields which needs to be populated so that I can generate the code.
Not that I would defend JSON Schema, but yes, you did just reinvent the wheel, and it was also not a new idea. I thought that despite the verbosity of XML, WSDL and associated technologies solved this problem rather better. I have the misfortune to develop in PHP, so pardon the example, but the client-side code went something like this:
$PayPal = new SoapClient($WSDLLocation); $PayPal->SomeMethod();
Yes, you can get away with having a less verbose description language if your needs are simpler, but that to me just ends up moving the problem when your needs become less simple. It's not like you can avoid validating your requests in some way, and required/not required is where that starts -- but, I maintain, not sufficient. I most definitely fail to see client code generation as being a necessary step.
You could say I've made this mistake myself; the thought process that leads to code like this must not be unique. Web services need documentation if they are to be used, and since that code will only ever talk to other code, it makes sense to have a machine-parseable description. Language agnosticism follows as a matter of course. I'm willing to entertain that XML was a bad idea and JSON Schema is not an improvement, but I still feel that if one must reinvent the concept of a language-agnostic machine-parseable web services description language, one should thoroughly understand the prior art. It may be complex for a reason, and like it or not all that SOAP stuff actually tends to work pretty well. I'm sure I have every reason for wanting to see a better technology suite which is JSON based, and I wish this were it. At the moment I don't think you're headed in quite the right direction.
Re: Show HN: Given an API, Generate client libraries in Node, Python, PHP, Ruby
#68Very cool, but why come up with a new API schema rather than use an open standard like OData (http://www.odata.org/)? Then Alpaca would be compatible with a bunch of APIs that already exist today. In fact, something like this (generating client libraries from APIs) may exist for OData already, but if it does, I've only seen it for .NET and OData (Visual Studio 'Add Service Reference').
This is actually pretty similar to a side project I've been working on called Gargl (Generic API Recorder and Generator Lite) (https://github.com/jodoglevy/gargl). Haven't gotten around to doing a Show HN post yet, but would love any feedback or to combine efforts. Basically it lets you generate an API for websites that don't have APIs publically available, by looking at how a web page / form submission of that web site interacts with the web server. You record web requests you make while normally browsing a website via a chrome extension, parameterize them as needed, and then output your "API" to a template file. Then this template file can be converted to a client library in a programming language of your choosing.
Re: Show HN: Given an API, Generate client libraries in Node, Python, PHP, Ruby
#69I 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...
Re: Show HN: Given an API, Generate client libraries in Node, Python, PHP, Ruby
#70Earlier quoted context omitted.
How do you differ from Swagger, Blueprint, I/O Docs, RAML and all these API endpoint descriptions?
I tried searching for a program which generates client libraries in different programming languages and failed. Could you please link if something does it? From what I gather, the above mentioned sites only provide methods of describing the API and/or Automating the API on the server side. Nothing is said about client libraries. Thanks
https://github.com/wordnik/swagger-codegen
does javascript, scala, java, objective-c, php, python (3), ruby, android, and even flash
Also has the benefit of a commercial backer (https://helloreverb.com) and a real app depending on it