1 / 29

Launching the Google AdWords API

This article provides an overview of the Google AdWords API and discusses the use cases, goals, features, and success stories of the API. It also explores the use of SOAP, WSDL, and ReST web services in the API and compares their advantages and disadvantages.

bcarpenter
Télécharger la présentation

Launching the Google AdWords API

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Launching the Google AdWords API Nelson Minar March 2005

  2. Outline • Product overview • SOAP, WSDL, and ReST • Lessons from experience

  3. Product overview

  4. AdWords product • AdWords: those little ads on the side of Google’s page • Same ads also show on other sites (AdSense) • Campaign management done via web application • Some advertisers have many thousands of keywords! • Hierarchical data model • Campaign: budget, targeting options, etc • Adgroups: CPC, enabled/paused/deleted, etc • Keywords: text, match type, CPC

  5. AdWords API goals • Enable developers to integrate with the AdWords platform • Use cases • Technical bid management • ROI optimization • Keyword and campaign optimization • Creative new user interfaces • Integration of advertising with backend systems • Create a third party developer community

  6. AdWords API features • Campaign management functions • Keywords, Creatives, AdGroups, Campaigns, Account • Reporting functions • Traffic estimator functions • SOAP + WSDL + SSL • Quota system • Multiple authentication mechanisms

  7. Success stories • Retailers managing campaign spending • Manage CPCs to meet seasonal goals • WebmasterWorld user testimonial • $100 / day to $200 / day • CPCs and Conversions up 20% • Fewer keywords • On the way to fully automating his account • Third party developers • Consultants and toolkits are popping up

  8. SOAP, WSDL, and ReST

  9. Web service buzzwords • SOAP: (formerly) Simple Object Access Protocol • XML protocol for creating web services • WSDL: Web Services Definition Language • Standard for formally describing SOAP services • Uses XML Schema as a type system • WS-I Basic Profile • Best practices / standards for SOAP and WSDL • WS-*: web services technologies • WS-Transfer WS-Enumeration WS-Choreography WS-Security WS-Addressing WS-Trust WS-Transactions WS-Federation WS-SecureConversation WS-Reliability WS-Eventing … • ReST: Representational State Transfer • Alternative style of creating web services

  10. Why SOAP and WSDL? • Goal: make this simple program work: adwords = makeProxy(‘http://.../KeywordService’, ‘nelson’, ‘ossifrage’) adwords.setKeywordMaxCpc(53834, ‘flowers’, $0.05) • No XML, no HTTP, just function calls • WSDL enables this (in theory)

  11. What is SOAP, really? • XML over HTTP / HTTPS • Standard way to add metadata (SOAP headers) • Standard way to signal errors (SOAP faults) • “Standard” ways to do fancy WS-* things • Jury is still out on this one • Document/literal SOAP • WS-I Basic Profile

  12. Document / literal SOAP example <?xml version='1.0' encoding='UTF-8'?> <soap:Envelope> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns="http://adwords.google.com/api/adwords/v2/"> <soap:Header> <username>nelson</username> <password>ossifrage</password> </soap:Header> <soap:Body> <setKeywordMaxCpc> <adgroupId>53834</adgroupId> <keyword>flowers</keyword> <cpc>50000</cpc> </setKeywordMaxCpc> </soap:Body> </soap:Envelope>

  13. Document / literal SOAP • Stop thinking of API as function calls • Think of it as passing XML documents around • Data model is center of design • Use XML fully (beware: interop) • Larger requests, more structure • Beware: no good solution for versioning • XML data bindings are the key technology • Get rid of SOAP toolkits entirely? • But then the simple program isn’t simple

  14. SOAP and WSDL in reality • Interoperability is still very hard • WSDL support varies by toolkit • SOAP document/literal support varies by toolkit • Good: .NET, Java (Axis) • OK: C++ (gSOAP), Perl (SOAP::Lite) • Not good: Python (SOAPpy, ZSI), PHP (many options)

  15. Interop example: sending nothing is hard Use case: a foo, which is an integer (xsd:int) <foo>3</foo> How do you indicate the absence of foo? <foo xsi:nil=“true”/> <foo/> nothing <foo>-1</foo>

  16. Interop example: sending nothing is hard <foo xsi:nil=“true”/> Axis sends by default, .NET fails <foo/> not valid (empty string is not an integer) nothing Can make Axis send, .NET understands it <foo>-1</foo> Weak! But may be easiest.

  17. SOAP interop hazards • Nested complex objects • Polymorphic objects • Optional fields • Overloaded methods (WS-I forbids this) • xsi:type considered harmful • WS-* is all over the map • Document/literal support is weak in many languages • Only real choice now • You can always give up and parse the XML directly

  18. So why not just use ReST? • Low ReST: use GETs everywhere, they’re easy! • Friendly hackability • Can tinker in a browser • Note: GETs must not have side effects. • High ReST: use HTTP semantics to build APIs • Use HTTP verbs GET, POST, PUT, DELETE • Use URL path meaningfully • Use XML if you need it, but only as documents • Metadata in HTTP headers

  19. ReST example POST http://adwords.google.com/adgroups/53834/flowers/cpc Content-Type: text/plain Authorization: Basic 5hq5ADSTZgwt0vWS 50000

  20. ReST limitations • Less advantage for lots of state changing calls • End up not using GET much • PUT, DELETE not implemented uniformly • No standard structured fault mechanism • URLs have practical length limits • No WSDL, no data binding tools • For complex data, the XML is what really matters • Will be the same whether ReST or doc/lit SOAP • For mostly read-only APIs, ReST is good • Would love to see more ReST tools, conventions

  21. Lessons from experience

  22. Things that went right • Switch to document/literal • Stateless design • Developer reference guide • Developer tokens • Thorough interoperability testing • Private beta period • Excellent technical support group

  23. Things that went right: bulk methods • getAdGroup(342343) • getAdGroups([342343, 342344, 834325]) • Bulk calls up to 25x more efficient • Less HTTP overhead • Batch the work in the database • Problems • Handling errors in bulk edit methods • Larger messages

  24. Things that went wrong • Switch to document/literal • Lack of a common data model • Dates and time zones • What day is 2005-03-09T00:00:00Z? • No gzip encoding • Quota confusion and anxiety • No developer sandbox

  25. Things that went wrong: SSL • Helping users debug SOAP is hard • SSL means you can’t easily use sniffer tools • No SOAPScope, no Ethereal • Plaintext passwords mean SOAP is secret • Can’t simply post XML dumps to the public • SSL is not fast • Is WS-Security the solution? • Message level security, not transport • Looks good, but can we rely on it?

  26. Be sure to get right: SOAP • Use document/literal • Don’t use multirefs • Don’t send xsi:type attributes • Validate everything: SOAP, WSDL • Follow WS-I Basic Profile • SOAPScope is a useful tool • Test in every language you care about • Must test every kind of data type • Consider distributing client libraries

  27. Be sure to get right: developer support • High quality reference docs • Sample programs and XML • Best practices • Support plan with quick answers to questions • Debugging instructions • Developer community

More Related