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

1. Reaching 1 Million APIs
and what to do when
we get there
Steven Willmott
http://www.3scale.net

2. 6000 APIs on Programmable
Web Today

3. Probably 4-5x that number out there
100% Annual Growth
1million APIs by
2017?

4. Topics
• Getting to 1 Million APIs
• The “Millionth” API
• Things we’ll need when we get there

5. Preliminaries

6. Took 6 years to go from 1 Web
Site to 1 Million
~ approx May 1997

7. Big Step Changes in Web Growth
Text >> CGI >> PHP >> Geocities & Co…

8. Today’s API
World is
“Artisan”
Craft rather than a science
(sidenote : check out the
excellent api-craft mailing
list / managed by Apigee)

9. Artisan is Good but…
• Expensive
• Doesn’t scale
• Fragile
• Every API is Different and works in
unexpected / suprising ways

10. To Grow, the
Web Automated
APIs are
starting to do
the same?

11. API “Mass Production”
How to reach 1 Million APIs

12. Two Key Trends in API Automation
1. Code Frameworks
2. Hosted Platform Environments

13. 1: Code Frameworks
• APIs for Free
• Or by Default
JAX-RS
• Much easier to write
APIs
• APIs are much more
standard
• Big Adoption Driver

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. Impact of Mass Production

16. No doubt we have the capacity to
create as many APIs are Web sites…
Commercial pull is almost
unbounded – B2B, Mobile, HTML5
are all major drivers

17. The Millionth API
Micro View

18. What was Millionth Web Site?
(Donald Rumsfeld might call it a
known unkown)

19. Launched in May 1997
• Belvidere, NJ
• Barnes and Noble
• Thousands More..
"I'm very excited for it," Mayor Linda Stettler
said. "Belvidere is moving in the right direction."
http://www.belvidere-nj.us/

20. The Millionth API?
Don’t know much about it yet but…

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. Few Technical Changes are really
needed…
We’re way ahead of where the Web
was

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. But most technical change will
driven by dealing with the sheer
number of APIs

25. Dealing with Millions
Macro View

26. Topics
1. Discovery
2. Selection
3. Reuse
4. Engagement
5. Monitoring

27. #1: Discovery
• Q: Where are all the service
descriptions?
• A: Not quite there yet…

28. Discovery
API
Google
Discovery
Format
(Also see SWAGGER, WADL)

29. Discovery
Who Provides It
Functionality Offered
Data Models Used
Performance Parameters
API
SLAs and Guarantees
Cost and Terms
…
Description must be locatable

30. Discovery
• New Formats needed
API • But also adoption and
linking/indexing

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. 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. #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. (we’re getting pretty good at writing
them – but hey, it’s still dumb!)
Huge Barrier to Re-usability

35. Reuse – Two Big Trends
?
1. Better Specifications
2. Convergence

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. 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. But… – what happens if you can
copyright interfaces?
Need: interface commons

39. #4: Engagement
• Today:
API – http://developer.xyz.com/
– Agree Terms
– Get Credentials
– Write App
– Get Stuff Done
• Frankly…

40. This is Nuts!
(at scale)

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. #4: Engagement
Need a Focus on Simplified
Contract First OWL-S Contract Establishment
ebXML • Identity is Critical
• Standard Terms are
WSMO Critical
Design By Contract • APIs for Contracting
• How to setup up API
BPML Open Grid Forum usage with code
rather than web
All Contain elements interactions
Mostly Focus on Coordination

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. Summary: Macro Issues
Transparency Description Formats
Shared Infrastructure Description Usage
Integration 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. Closing Thoughts

46. Todays' APIs are very special –
need unique, care and attention

47. But to get further we need to
Automate – and deal with scale

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. 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. Thank you & Q/A
steve@3scale.net
@njyx, @3scale
http://www.3scale.net/

51. Credits
• Cover Image: appelogen.be / flickr of AI
WeiWei’s sunflower exhibit at the Tate
Modern, License CC.
• Anatomical Heart: wikimedia / wikipedia
• API-CRAFT Mailing list:
https://groups.google.com/group/api-craft

52. Licenses
• Original Content:
Creative Commons Attribution-ShareAlike 3.0
• Included Images:
– Licensed terms determined by originator