It's a fact that all of us who have done it know: writing native interfaces to work with web APIs is pretty much the most miserable programming job you can do. It's almost always worth it in the long run, but you have to wade through a sea of annoyances first.
1. Every API is different
And I don't mean that in a good way. Having different people around, with different viewpoints, values, and ideas is great - it gives you insight into topics you might not have thought about fully before. In comparison, the hundreds of different API styles out there just make it a pain to work with any one of them.
The vast differences between all the APIs means that not only do you have to keep track of the actual object model of the system you're working with, but you also have to keep track of how that object model actually relates to the HTTP endpoints of its API. It's rare to find a case where the relation is clear and clean-cut.
2. The documentation is awful
There are exceptions to the rule, but it's often the case that API documentation just doesn't get done very well. Companies just don't tend to put the time into writing clearcut documentation that makes their APIs easy to use for third parties. And why would they?
Not only do most platforms have a first-party interface that can be used to access their service, the API is often an afterthought. Often, companies throw their APIs together on-the-fly as they need them for their own purposes, and it's only miles down the road that they have the idea of putting together some documentation around them.
Essentially, APIs are often an afterthought, and API documentation becomes an afterthought of an afterthought.
3. It just sucks
Even if APIs were predictable in the way they worked; even if they had consistently good object structures; even if the documentation was clear and had stellar examples of each possible type of request, writing API wrappers would still suck.
At the end of the day, no one wants to be spending valuable coding time writing an interface. It's scut work that takes none of the creativity that's the entire reason we program. We want to make things that people will love using; we don't want to spend our time figuring out how to talk to an existing platform.
And the worst part of it is that once the coding work is done, none of it is of any value any more. If you're writing a new Twitter client based on a novel idea you had about how you could change the way interactions work, then the least valuable part of the application is the code that actually interfaces it to Twitter.
You differentiate your product, not in the quality of the way you interact with the API, but in the tangible, visible benefits that you present your users with. They don't care whether you converted the REST API to a beautiful structure that can be easily queried; they just want the app to work, and a working API interface is part of that.
We should write beautiful code. We should work to understand the APIs we're working with. We should ensure that the backends of our projects receive as much care as the fronts do. We should be able to do all these things... but we should also be able to do them without wading through the sea of ugliness that is developing code specifically to handle a particular REST API.