I think the problem described in this article is more fundamental: these services don't have documented, stable APIs for clients to build on. Not HTTP APIs. Not

I think the problem described in this article is more fundamental: these services don't have documented, stable APIs for clients to build on. Not HTTP APIs. Not libraries either. In some cases they go out of their way to prevent third parties from using whatever internal API their own apps use. [edit to add: to combat abuse/spam, or because they have ads, or as deliberate lock-in.] But to answer your question: when an API exists, why have an SDK? One reason is to provide strong typing (and everything that goes with it, like IDE auto completion). A very thin layer over the HTTP requests is enough to provide this. Eg, in one of my projects [1] I wrapped a HTTP API with Go calls like this: Method(ctx context.Context, req *MethodRequest) (*MethodResponse, error) where each method call corresponds to exactly one HTTP request. It handles deadlines, cancellation, HTTP error checking, and using Go's built-in json marshalling/unmarshalling on structs. That's about all I want in an SDK. The unirest project you linked doesn't seem to offer strong typing so I wouldn't use it (even if it weren't dead). [1] https://github.com/scottlamb/luxor https://github.com/scottlamb/luxor