I agree for the most part, but I think another reason to use the SDK is bugs: for dirt-simple APIs and auth methods, this might not be a concern, but for anything else, you might write your own integration that seems to work properly, but fails in strange ways -- possibly intermittently -- later on.
Source: I've done this, and this happened, and it was a pain in the ass to track down the problem. Ultimately I'd wished I'd just used the official client library in the first place.
I find the first party SDK is likely to work without a lot of trouble but boy do you find people have weird ideas like "I don't know anybody who develops web sites who doesn't use .NET" or "it's no problem that it takes developers two hours to get up and running with our SDK even if they can get up and running with our competitors in five minutes".
It's fair to put a timebox in for a first party SDK and it ought to be a short timebox like 15 minutes because a bad SDK written by people who don't really care if it works properly can steal 15 hours from you pretty quickly.
I've experienced both of these -- Good SDK that save you time over the raw API and bad SDK that steals your time. In fact, sometimes both are created by the same organization targeting different platforms!
I don't think you have any hard and fast rules about this you have evaluate each product and each situation individually.
Yeah, have had to switch to home made sometimes because the SDK for instance didn't use connection pooling, and the server on their end was slow setting up new tcp connections.
Or that they have opaque logging in their own weird format and don't properly hook into a common log interface, so don't know what's going on inside the SDK. Which is bad if it's a big component of the app you're making.
Years ago, I did a trial of vision recognition APIs from roughly 8 vendors, some of which were tech giants and some of which were little startups you probably haven't heard of.
I got 7 of these up and running in less than 20 minutes each. Number 8 was Google which uses a Rube Goldberg machine like
to log in that somehow trashed the Python installation on my machine and forced me to reinstall Python. So I think messing around with SDK's from arrogant tech giants is like playing Russian roulette. Sure you survive most of the time but every so often you take a bullet.
This isn't always true, but one nice thing about using an HTTP API directly is the responses are usually documented well enough that creating mocks for testing can be easier than the SDK. Additionally, I find working in an HTTP tool like Postman or Insomnium easier than in a full dev environment when I'm in the exploratory phase.
I understand the desire to minimize dependencies and the impact of third-party code. In practice, I’m lazy. I don’t want to build my own integration if someone has already done it.
I also don’t always know how complex my integration will be, and would rather not go back and replace custom code with the SDK, so I start with the SDK.
Source: I've done this, and this happened, and it was a pain in the ass to track down the problem. Ultimately I'd wished I'd just used the official client library in the first place.