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.<p>Full disclosure: I wrote such a library for Ruby, called HyperResource.
<a href="https://github.com/gamache/hyperresource" rel="nofollow">https://github.com/gamache/hyperresource</a>
Author here. I covered almost everything in the documentation. And there is also a small example which is hosted at <a href="https://github.com/alpaca-api" rel="nofollow">https://github.com/alpaca-api</a>.<p>Please ask if you have any questions. Thanks
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.<p>Overall, I'm not sure that the time savings is as big as it first appears, but I think it's great for quick projects.<p>[0] <a href="http://thrift.apache.org/" rel="nofollow">http://thrift.apache.org/</a>
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. <a href="https://github.com/SPORE/specifications" rel="nofollow">https://github.com/SPORE/specifications</a><p>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.
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.)<p>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!<p>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.<p>Neato!<p>[1] <a href="http://json-schema.org/" rel="nofollow">http://json-schema.org/</a>
I have to admit, this is very reminiscent of "Add Service Reference" in Visual Studio, a capability to which I have grown to despise over the years. The code was almost always incomprehensible. I cannot tell you how much I loath seeing the comment at the top of a file "This was generated by a tool".<p>Having said that, this tool does look interesting. I hope that a goal is to always make sure that the generated code is as readable, and maintainable, as possible. Also, as mentioned by others, adding generated tests to the generated client libraries is extremely important.
Describing an API is not hard, but the API authentication method is. How do you think you will do it?<p>Edit : If you don't make oauth consumption simpler, you don't really solve the problem
Very cool, but why come up with a new API schema rather than use an open standard like OData (<a href="http://www.odata.org/" rel="nofollow">http://www.odata.org/</a>)? 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').<p>This is actually pretty similar to a side project I've been working on called Gargl (Generic API Recorder and Generator Lite) (<a href="https://github.com/jodoglevy/gargl" rel="nofollow">https://github.com/jodoglevy/gargl</a>). 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.
So, this is markedly similar to the project I've been working on in grad school, only without static typing.
<a href="http://research.cs.vt.edu/vtspaces/realtimeweb/" rel="nofollow">http://research.cs.vt.edu/vtspaces/realtimeweb/</a>
Also, mine is explicitly geared towards education purposes. I'm about one third of the way thru version two, but I wonder if we can cross pollinate our code bases to get something even better.
That looks fantastic, and seems to be in alignment with some things I have been doing lately (generating the server side controller of the API in Clojure + a set of documentation, from a set of definitions of API methods).
Good job!
Well done!<p>Know what I think would be really neat? If it could be pointed at an instance of Swagger-UI, or use the same discoverUrl that Swagger-UI would use, and spit out the libraries from that.<p>If you're not familiar..
<a href="https://github.com/wordnik/swagger-ui" rel="nofollow">https://github.com/wordnik/swagger-ui</a>
I did something similar for Go and Java. It's simpler if you don't need the whole API, but of course not as powerful.
<a href="https://github.com/bashtian/jsonutils" rel="nofollow">https://github.com/bashtian/jsonutils</a>
fwiw, I experimented along this line, dynamically generating python wrappers from yaml: <a href="https://github.com/reklaklislaw/rest_easy" rel="nofollow">https://github.com/reklaklislaw/rest_easy</a><p>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.