Hacker News Reader

Or, in a rather less condescending tone, you might have built the SDK for Busy Bob, who is using your API, which is is important but peripheral, to the problem he is writing software to solve.

If his solution works, and is widely adopted, then he will revisit and add all those things that the OP mentions, but right now he is just trying to get something working.

An SDK is great for that.

View on HN

I agree. I would just add that there are lots of Busy Bobs, all of whom just want to consume your service, and don't want to have to bother with creating their own JSON/XML/EDN/etc marshaling/unmarshaling code, translating HTTP error codes to whatever idiomatic error-handling construct is used for the language at hand, etc.

When I build an app that needs to consume some REST API, if the REST API provider doesn't already provide an SDK, I'll create my own in each programming language that is useful to me (Objective-C to build an iOS app; Java to build an Android app; etc). To me its the logical thing to do, especially if I intend to create more than 1 app that consumes the REST API in the same language (iOS POC app 1, iOS POC app2, ...).

Wow, what a pain.

However, creating your own SDK is pretty much what the OP suggests--it gives him the level of control that he needs.

Reply on news.ycombinator.com