Reaching 1 Million APIs and what to do when we get there


Published on

Gluecon 2012 Talk on API growth and how to automate API creation as well as how to handle a world with millions of APIs.

Published in: Technology

Reaching 1 Million APIs and what to do when we get there

  1. 1. Reaching 1 Million APIs and what to do when we get there Steven Willmott
  2. 2. 6000 APIs on Programmable Web Today
  3. 3. Probably 4-5x that number out there 100% Annual Growth1million APIs by 2017?
  4. 4. Topics• Getting to 1 Million APIs• The “Millionth” API• Things we’ll need when we get there
  5. 5. Preliminaries
  6. 6. Took 6 years to go from 1 Web Site to 1 Million ~ approx May 1997
  7. 7. Big Step Changes in Web Growth Text >> CGI >> PHP >> Geocities & Co…
  8. 8. Today’s API World is “Artisan”Craft rather than a science (sidenote : check out theexcellent api-craft mailinglist / managed by Apigee)
  9. 9. Artisan is Good but…• Expensive• Doesn’t scale• Fragile• Every API is Different and works in unexpected / suprising ways
  10. 10. To Grow, theWeb Automated APIs are starting to do the same?
  11. 11. API “Mass Production” How to reach 1 Million APIs
  12. 12. Two Key Trends in API Automation1. Code Frameworks2. Hosted Platform Environments
  13. 13. 1: Code Frameworks • APIs for Free • Or by DefaultJAX-RS • Much easier to write APIs • APIs are much more standard • Big Adoption Driver
  14. 14. 2: Platforms• The Web is build on • API Platforms are platforms: emerging – Mobile backends – Infochimps – Factual – 3scale, Apigee, Mashery – … • And web platforms are going API
  15. 15. Impact of Mass Production
  16. 16. No doubt we have the capacity tocreate as many APIs are Web sites… Commercial pull is almost unbounded – B2B, Mobile, HTML5 are all major drivers
  17. 17. The Millionth API Micro View
  18. 18. What was Millionth Web Site? (Donald Rumsfeld might call it a known unkown)
  19. 19. Launched in May 1997• Belvidere, NJ• Barnes and Noble• Thousands More.. "Im very excited for it," Mayor Linda Stettler said. "Belvidere is moving in the right direction."
  20. 20. The Millionth API?Don’t know much about it yet but…
  21. 21. But we can guess some things• Niche• Probably in the United States• Probably in the “non-tech” economy• Probably powered by a platform• Probably launched by a small company or individual
  22. 22. Few Technical Changes are really needed… We’re way ahead of where the Web was
  23. 23. API Anatomy Meta Data: Publically Listed Code Libraries: Auto Generated Data Models: Standardized API Pattern: e.g. REST (++) Identity & Auth: e.g. oAuth Code: e.g. PHP App Framework: e.g. Drupal PAAS: Cloud Managed IAAS: Cloud Deployed
  24. 24. But most technical change willdriven by dealing with the sheer number of APIs
  25. 25. Dealing with Millions Macro View
  26. 26. Topics1. Discovery2. Selection3. Reuse4. Engagement5. Monitoring
  27. 27. #1: Discovery • Q: Where are all the service descriptions? • A: Not quite there yet…
  28. 28. Discovery API Google Discovery Format (Also see SWAGGER, WADL)
  29. 29. Discovery Who Provides It Functionality Offered Data Models Used Performance Parameters API SLAs and Guarantees Cost and Terms … Description must be locatable
  30. 30. Discovery • New Formats needed API • But also adoption and linking/indexing
  31. 31. #2: Selection • Amongst million APIs - how do you know which ones to API trust? API • On the Web: API – Domains API – SSL API – Brand Visuals – Google/Alex Rankings
  32. 32. Selection • In an API World many of these don’t work (e.g. no browser SSL root certs) API • Need: API API – 3rd party monitoring & ranking – Transparency by providers API – “Web of Trust” for APIs API • Identity of providers just as much an issue as that of users
  33. 33. #3: Reuse • Today: ? – Semantics are HTTP, REST Principles, MIME Data Types, Developer Intuition – Operational Semantics baked into client code • This is like writing a new browser for every website
  34. 34. (we’re getting pretty good at writing them – but hey, it’s still dumb!) Huge Barrier to Re-usability
  35. 35. Reuse – Two Big Trends ? 1. Better Specifications 2. Convergence
  36. 36. Reuse - Specifications • More Rigid Semantics ? • Data Ontologies • Interlinking Ontologies • HATEOS Principles for Spec exploration Principle: use derivation from primitives to write / generate code
  37. 37. Reuse - Convergence • Similar Interfaces and Logical Choices ? • Conventions • Already Happening • Platforms will be a huge driver Y • How to Foster Good Conventions? X Principle: stick to conventions to help people use your stuff
  38. 38. But… – what happens if you can copyright interfaces? Need: interface commons
  39. 39. #4: Engagement • Today: API – – Agree Terms – Get Credentials – Write App – Get Stuff Done • Frankly…
  40. 40. This is Nuts! (at scale)
  41. 41. #4: Engagement • Need to be able to: – Be able to discover the software you need automatically API – identify yourself and the provider – engage a service contract – generate credentials – begin using the service • All without human intervention of any sort
  42. 42. #4: Engagement Need a Focus on SimplifiedContract First OWL-S Contract Establishment ebXML • Identity is Critical • Standard Terms are WSMO Critical Design By Contract • APIs for Contracting • How to setup up APIBPML Open Grid Forum usage with code rather than web All Contain elements interactions Mostly Focus on Coordination
  43. 43. #5: Monitoring • Quality of Service Will be Key X API • Using any API introduces an API API outside dependency • More complex than Web API Monitoring X API • Like Distributed Integration Testing
  44. 44. Summary: Macro IssuesTransparency Description FormatsShared Infrastructure Description UsageIntegration Like Testing Description Referencing Monitoring Discovery Engageme Selection nt Indicators of Trust Indicators of Quality Identity Identity Reuse Common Terms Simple Protocols Specifications Convergence
  45. 45. Closing Thoughts
  46. 46. Todays APIs are very special –need unique, care and attention
  47. 47. But to get further we need toAutomate – and deal with scale
  48. 48. Conclusions• Platforms will begin to drive massive API growth• Much of the challenge is in meta- data, discovery and engagement• API Consumer will need just as much help as the API provider• Need a new discipline – “Machine Interface Design”
  49. 49. Final Thought • Today: we focus on making it easier for developers to use our APIs • Tomorrow: we’ll need to make it easier for machines to use our APIs
  50. 50. Thank you & Q/A @njyx, @3scale
  51. 51. Credits• Cover Image: / flickr of AI WeiWei’s sunflower exhibit at the Tate Modern, License CC.• Anatomical Heart: wikimedia / wikipedia• API-CRAFT Mailing list:
  52. 52. Licenses• Original Content: Creative Commons Attribution-ShareAlike 3.0• Included Images: – Licensed terms determined by originator