I deployed on v201101 last night and have a couple thoughts. Like most people I don't use every single service, but I use the bulk of them. The largest migration effort I had was dealing with the generic Selector. The ability to set the Predicates for filtering is very, very cool and opens the door for more efficient coding. However, to mandate setting the return fields doesn't provide any value to me, and will only lead to more troubleshooting and code maintenance in the future.
The largest issue I have with the change is there's no one single document that states what the field values are. Unless I missed a resource, I have to go through the API object docs one by one and look at what is "selectable". This is a hassle and leads to buggy code. Could there at least be static final variables in the object model we could code off rather than copy & pasting from the docs? I write wrappers around the Google services, and for my wrappers I'm requesting the same fields for every service call I make, regardless of what values I'm going to work with. I haven't seen a document stating "If you only request Id and Status your object will return in 5ms where as if you request a fully attributed object your return call will take 100ms". I don't see any value to not requesting the same fields every time and I've coded that way, reusing the same static string array of fields in all relative calls to cut down on bugs. To go along with the lack of aggregated selectable documentation, if I migrate to the next version of the API and one of those objects is no longer is selectable, I'll get Selector errors and have to modify code. I could either go through the ~50 documents one by one and double check what I'm currently setting for fields, or I could release, make a call, get Selector error, iterate ... a hassle either way Cross client reporting: where's it at? Lots of stuff is sunsetting in July, is that date going to be revised? I know it's annoying to give the same vague answer to the 10% of group postings that deal with this but we should be given a more solid answer for both questions. Are more campaign targets going to move to settings like NetworkSetting? I see that as an improvement. And last, the Sandbox continues to suck. It's not worth my time to get everything setup through it. It's not a reasonable mirrored environment of the live data and as has been discovered through a few postings to this group, even the services in the Sandbox don't always mirror what we're supposed to be coding against in the live environment. At the very least I would like a couple convenience methods to: wipeSandboxAccount, populateSandboxAccountFromLiveAccount so I can more easily test my code in a development environment I focused on the negatives, but the truth is most of the API continues to kick ass and is fun to work with. Pete -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog and discussion group: http://adwordsapi.blogspot.com http://groups.google.com/group/adwords-api =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To post to this group, send email to adwords-api@googlegroups.com To unsubscribe from this group, send email to adwords-api+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en
