Their client library is decent, for PHP anyway so you mostly get SOAP abstracted away. Up until you get an error then the usual problems are there. The underlying code in the client library is super bloated though, like what you would imagine from visual studio endpoint type stuff in the article. It may be that the core adwords developers are using Java and an old school SOAP interface makes sense to them. They certainly had a chance to change it recently with the new version.

in Python, they make you chose between ZSI and a beta soappy release. Their site has a getting started video which mentions running a config script they no longer distribute. most docs are using a different module name. Oauth isn't implemented at all.

In JS, you have no client library so you're required to roll everything from scratch.

PHP has oauth, more demo code and better docs, I've recently been using it to build a JS lib for a work project.

The thing is, rather than maintain one client library, half maintain two others, and have a bunch of unofficial libraries, if they just made and documented a REST interface everyones lives would be easier.

Yeah, unfortunately I don't think it has a lot to do with the guys who have maintained the client library, I think they would agree.

Big problem is at the moment that PHP has Oauth for pretty much everything except report downloading, which is essentially separate from the rest of the API.

Hoping they fix this before I launch, as most of the good of OAuth is negated if I still have to collect a username and password for report downloading.