add client libraries

[aaronsnow]

"client libraries are a true force multiplier" - @adelevie

[adelevie]

:+1:

The "crawl" version of this is just a set of snippets in different languages that you can copy+paste.

Some of my favorite examples of ployglot client libs + docs are:

• Parse
• Iron.io

For Iron.io, also take a look at this page and look at the "Code Samples" section. Horizontal tabs to toggle language, and vertical tabs to toggle the task. If/when you go through the Parse docs, you'll notice something similar: all the code samples tell you how to do the same thing, just in different languages. If you need to jump from Ruby to Javascript, for example, you'll understand the Javascript docs that much better because you know that FBOpen.new.foo in Ruby does the same thing as new FBOpen().foo() in Javascript (I know the example is a bit contrived, but speaking for myself, this strategy has been super helpful to me when I've worked with different APIs.).

Another point to consider: use cases, use cases, use cases.

Think in terms of where and how a 3rd party dev would integrate this API. Could it be used in a Rails app? Then build a Rails plugin etc etc

[marks]

For a slightly different approach, you can take a look at http://unirest.io/. It's a basic HTTP-requesting client library by the folks at @Mashape.

[marks]

The README at https://github.com/Mashape/unirest-website is a better one-page explanation

[adelevie]

Unirest looks really, really interesting. It seems to be a middle ground between things like Swagger (write a spec, generate libraries) and hand-writing everything from scratch. It gives library authors a common interface/semantics. Library authors who know Ruby, and just used Unirest to write the Ruby library, could have a much easier time writing an Objective-C library, even if they know very little about the language.

@marks, that [link[(https://github.com/Mashape/unirest-website#lets-see-some-code) is excellent. If an API provider can see the benefit of Unirest for him/herself, then he/she should certainly be able to see how API users will benefit from that same concept.

[marks]

As a dev, I definitely agree with this type of middle-ground approach. It lessens the burden on this project's team but also makes it easy for complete programming newbies to start and not deal with the more complicated language-specific libraries.