
If Web APIs are so simple why do we need SDKs? - allthingsapi
http://www.apiful.io/intro/2016/06/10/why-apis-need-sdks.html
======
krsyoung
I agree with this post. I very rarely consider using a service's API without a
client library. Taking the load off authentication and marshaling is
incredibly valuable in my development workflow. Granted, sometimes simple REST
endpoints are OK if they are public / don't need complicated authentication.

I think the major benefits of client libraries is the ability for a developer
to stay within their programming language / business domain and not stray into
the fun of HTTP and JSON.

Curious how much burden this makes for providers though and what people have
done to streamline the testing of the various client libraries with different
versions of the service.

~~~
smt88
> _Curious how much burden this makes for providers though_

If those providers document their APIs using the Swagger format, there are
tools that will automatically generate SDKs in tons of popular languages. The
burden is nearly zero.

~~~
allthingsapi
Does that count as an SDK? - simple code generation out of a spec? - Most SDKs
exist because the provider is hiding some ugly code or making a number of
primitive API calls to assemble the response. Aren't we falling back into the
old "software" practices and now have to maintain code for anyone that users
our service? - wasn't it supposed to be a service?

~~~
smt88
> _Does that count as an SDK?_

A lot of big companies publish what they call an SDK, which is really just a
thin, idiomatic wrapper on top of HTTP calls. Most of the AWS SDKs are like
this, and sometimes the wrapper is way too thin (see: the disastrous mess that
is the Dynamo JS library).

Should SDK mean more than that? I don't know. Is that kind of SDK useful?
Definitely! HTTP is untyped, slow, and potentially tricky to use (like with
OAuth 1.2), so it's nice to have some native code that abstracts that stuff
away.

