Considerations For an API Strategy - Ronnie MItra API Architect Layer 7 London Workshop

2,384 views

Published on

API Management is becoming increasingly important as more and more organisations need to expose their data and application functionality to internal and external developers. Exposing APIs empowers these organisations to engage customers in innovative new ways, create new revenue opportunities and transform their businesses into platforms. But how do you ensure your APIs are exposed securely? How do you create, maintain and update different versions of your APIs? How do you throttle usage, meter requests and monitor API health?

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,384
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • Make a slide with an example
  • Make a slide with an example
  • Why are API publishers opening up their APIs? What are their motives? This will help us choose APIs that have reasonable business modelsNeed a better word for integration (trying to describe b2b scenarios driven by the business)[consider doing separate slides for each]
  • Why are API publishers opening up their APIs? What are their motives? This will help us choose APIs that have reasonable business modelsAlong with some simple examples that I came up with for your own business.
  • Really should be a DIRECT revenue sourceMake money per call Example: .02 per call, settle account at the end of term Tiered model: 50 pounds / month for 1000 calls. 100 pounds / month for 5000 calls. This motivation makes sense if you have a product that is worth buying. Are your data and services compelling enough to justify it? Charging for API usage has a detrimental impact on usage. Some organizations set a limit for free calls and charge for calls after that (rewarding success with a partnership of sorts) – tie this to lowering the barrier
  • Why are API publishers opening up their APIs? What are their motives? This will help us choose APIs that have reasonable business modelsAlong with some simple examples that I came up with for your own business.
  • Talk about taking over new markets.Talk about plethora of devices.Talk about apps as platforms. How do you reach a user who doesn’t know who you are?
  • Talk about taking over new markets.Talk about plethora of devices.Talk about apps as platforms. How do you reach a user who doesn’t know who you are?
  • Why are API publishers opening up their APIs? What are their motives? This will help us choose APIs that have reasonable business modelsAlong with some simple examples that I came up with for your own business.
  • Why are API publishers opening up their APIs? What are their motives? This will help us choose APIs that have reasonable business modelsAlong with some simple examples that I came up with for your own business.
  • Why are API publishers opening up their APIs? What are their motives? This will help us choose APIs that have reasonable business modelsNeed a better word for integration (trying to describe b2b scenarios driven by the business)[consider doing separate slides for each]
  • Why are API publishers opening up their APIs? What are their motives? This will help us choose APIs that have reasonable business modelsNeed a better word for integration (trying to describe b2b scenarios driven by the business)[consider doing separate slides for each]
  • Why are API publishers opening up their APIs? What are their motives? This will help us choose APIs that have reasonable business modelsNeed a better word for integration (trying to describe b2b scenarios driven by the business)[consider doing separate slides for each]
  • Why are API publishers opening up their APIs? What are their motives? This will help us choose APIs that have reasonable business modelsAlong with some simple examples that I came up with for your own business.
  • Why are API publishers opening up their APIs? What are their motives? This will help us choose APIs that have reasonable business modelsNeed a better word for integration (trying to describe b2b scenarios driven by the business)[consider doing separate slides for each]
  • Large amount of business generated through third party appsVery healthy app eco-system for end-users (lots of tooling)
  • Large amount of business generated through third party appsVery healthy app eco-system for end-users (lots of tooling)
  • Explain how this is important for Flickr’s business model (rapid growth?)
  • Developer = end user.
  • Copy and Paste from usability
  • They drive all of the technology that we use in our daily lives.
  • By our definition, a Web API includes SOAP, REST, HTTP, CSV… just about any type of interface deployed over the web.
  • By our definition, a Web API includes SOAP, REST, HTTP, CSV… just about any type of interface deployed over the web.
  • Hypermedia is like building a browser based web for computer programs.You can follow linksYou can provide input based on templatesRather than mapping to a resource + operations you can follow tasks.
  • Hypermedia is like building a browser based web for computer programs.You can follow linksYou can provide input based on templatesRather than mapping to a resource + operations you can follow tasks.
  • Hypermedia is like building a browser based web for computer programs.You can follow linksYou can provide input based on templatesRather than mapping to a resource + operations you can follow tasks.
  • Hypermedia is like building a browser based web for computer programs.You can follow linksYou can provide input based on templatesRather than mapping to a resource + operations you can follow tasks.
  • Hypermedia is like building a browser based web for computer programs.You can follow linksYou can provide input based on templatesRather than mapping to a resource + operations you can follow tasks.
  • Hypermedia is like building a browser based web for computer programs.You can follow linksYou can provide input based on templatesRather than mapping to a resource + operations you can follow tasks.
  • Copy and Paste from usability
  • Coined in the 1980sBut rooted in the design ideas of industrial age products and how users interact with technology
  • Our product is our API and our useris our developer.
  • Coined in the 1980sBut rooted in the design ideas of industrial age products and how users interact with technology
  • Lots of methodologies and terminology
  • We are not simply producing products that perform a funciton, but we consider how people (or users) will interact with the product.
  • They are intuitive, we spend less time understanding them, ultimately they are a pleasure.Conversely, poorly designed products are painful.
  • We talked about this, so highlight again.
  • Different identities
  • APIs are all about connectivity.
  • APIs are all about connectivity.
  • APIs are all about connectivity.
  • APIs are all about connectivity.
  • APIs are all about connectivity.
  • Different social conventions.Another form of this, is the question of RESTfulness.
  • APIs are all about connectivity.
  • APIs are all about connectivity.
  • [there was something else I realized after this pres. for Reason #4. – try to remember]Talk about when API dsigners don’t botyher with usability – selling to enterprises. (or do I leave this till later?)
  • APIs are all about connectivity.
  • APIs are all about connectivity.
  • Designer mental model vs. user mental model
  • Designer mental model vs. user mental model
  • APIs are all about connectivity.
  • APIs are all about connectivity.
  • Moneysupermarket.com example
  • Designer mental model vs. user mental model
  • Box.com example
  • APIs are all about connectivity.
  • There is a delay between
  • There is a delay between
  • There is a delay between
  • There is a delay between
  • Tie good design back to the business value we want
  • APIs are all about connectivity.
  • Why are API publishers opening up their APIs? What are their motives? This will help us choose APIs that have reasonable business modelsNeed a better word for integration (trying to describe b2b scenarios driven by the business)[consider doing separate slides for each]
  • APIs are all about connectivity.
  • APIs are all about connectivity.
  • APIs are all about connectivity.
  • Considerations For an API Strategy - Ronnie MItra API Architect Layer 7 London Workshop

    1. 1. Considerations for an API StrategyRonnie MitraPrincipal API Architect - EuropeLayer 7 API Academy
    2. 2. Business DriversThe Developer ExperienceAPI ArchitectureAgenda
    3. 3. Private or Closed APIs
    4. 4. Acme Corp.APIAcme Corp.App
    5. 5. Public or Open APIs
    6. 6. Acme Corp.APIThird PartyApp
    7. 7. Priority:Lower CostPriority:Increased Adoption
    8. 8. why build an API?
    9. 9. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
    10. 10. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
    11. 11. Revenue Source
    12. 12. Revenue Sourcehttp://www.flickr.com/photos/inside-south-africa/485356704£0.10 per API Call
    13. 13. Revenue Source1000 calls/month5000 calls/month
    14. 14. Revenue Source500 calls/month1000 calls/month5000 calls/month
    15. 15. Revenue SourceIs your content worth paying for?
    16. 16. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
    17. 17. Consumer Reach
    18. 18. Consumer Reach
    19. 19. Platforms are not forever!
    20. 20. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
    21. 21. MarketingAffiliate ProgramsSometimes you pay the developer.
    22. 22. MarketingDraw new visitors in.
    23. 23. Marketing
    24. 24. MarketingStay above the noise:New channelsInformation-centric marketing
    25. 25. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
    26. 26. InnovationLight Bulb designed by Jean-Philippe Cabaroc from The Noun ProjectInnovation from within
    27. 27. InnovationLight Bulb designed by Jean-Philippe Cabaroc from The Noun ProjectInnovation outside your borders
    28. 28. InnovationLight Bulb designed by Jean-Philippe Cabaroc from The Noun ProjectWhen does innovation happen?
    29. 29. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
    30. 30. IntegrationBusiness driven integrationRegulatory driven integration
    31. 31. Observational Learning:Five Famous Stories of Public APIs
    32. 32. 2000 – ebay
    33. 33. Started with a paid developer program in 2000Made it free in 2005
    34. 34. Consumer ReachMarketing
    35. 35. Large developer eco-systemLarge app eco-system
    36. 36. 25% of eBay listings come from their API!
    37. 37. salesforce2000 – salesforce
    38. 38. IntegrationRevenue Source
    39. 39. API as a cloud enabler
    40. 40. 2004 – Flickr
    41. 41. web 2.0 generationthe social evolution
    42. 42. Consumer ReachMarketing
    43. 43. The rise of self-serviceAnnounced 6 billion photos in August 2011
    44. 44. 2006 – Amazon Web Services
    45. 45. Started as an online book shop…Became a department store…now?
    46. 46. Jeff BezosConnect everythinghttp://www.flickr.com/photos/zippy/2430495092
    47. 47. 2004:Hey, why don’t we sell this?
    48. 48. Revenue Source
    49. 49. Estimated revenue:$1.5B in 2012http://wikibon.org/wiki/v/Cloud_Computing_2013%3A_The_Amazon_Gorilla_Invades_the_Enterprise
    50. 50. Twilio or stripe2007 - Twillio
    51. 51. Revenue Source
    52. 52. The API is the business
    53. 53. 100,000 developer milestone in 2012
    54. 54. Original APIs are still successfulNew business models have emergedKnow your drivers – design accordinglySummary
    55. 55. API Styles
    56. 56. What does a Web API look like?
    57. 57. Web APIsHTTP
    58. 58. Network Based APIsHTTPCOAP MQTTWebSocket?
    59. 59. Architectural Styles
    60. 60. Tunnel StyleURI StyleHypermedia StyleEvent Driven Style
    61. 61. Tunnel StyleExample: SOAP• transport agnostic• operation based• binding documents (WSDL)
    62. 62. Tunnel Style<RetrieveStudentRecords><StudentId>1213</StudentId></RetrieveStudentRecords>
    63. 63. Tunnel Style• lots of tooling• not restricted to HTTP• RPCAdvantages
    64. 64. Tunnel Style• inefficient for HTTP• increased learning curve• lack of tooling in mobileTrade-offs
    65. 65. URI StyleGETPUTPOSTDELETE+ URI
    66. 66. URI StyleGET /students/1232
    67. 67. URI Style• familiar to web developers• designed for HTTP• URIs are intuitiveAdvantages
    68. 68. URI Style• limited to four methods• URI design is not standard• can be ‘chatty’Trade-offs
    69. 69. Hypermedia Style
    70. 70. Hypermedia Style• links• templated input (forms)• task based
    71. 71. {links: [link {href: ‘…’ rel: ‘list’},link {href: ‘…’ rel: ‘add’}]collection: [{link: {rel:complete,href:‘…},id:42,text:‘Record 42}]}
    72. 72. Hypermedia Style• designed for HTTP• long lasting• no URI constructionAdvantages
    73. 73. Hypermedia Style• leading-edge• requires ‘smarter’ apps• less familiar to developersTrade-offs
    74. 74. Event Driven StyleExample: WebSockets• event based communication• server initiated events• full-duplex (websocket)
    75. 75. Event Driven Style• less overhead• better performanceAdvantages
    76. 76. Event Driven Style• not HTTP-based• resource intensive connections• inefficient for request-replyTrade-offs
    77. 77. API Styles Summary• Web API != standard• Four popular styles: Tunnel, URI,Hypermedia, Event• Choose a style that fits your constraintsand business goals
    78. 78. The Developer Experience
    79. 79. designing APIs can be difficult
    80. 80. http://www.flickr.com/photos/nirufe/3469696707?
    81. 81. UsabilityReliabilitySimplicitySecurityEtc…Software Qualities
    82. 82. Focus on the developer experience(dx)
    83. 83. Interaction DesignBill Moggridge
    84. 84. UsabilityHuman-Computer-InteractionUser Experience DesignGoal Oriented Design
    85. 85. http://www.flickr.com/photos/58754750@N08/5541472392/
    86. 86. A user-centric view of design.
    87. 87. Well designed products are easierto use.
    88. 88. Good design matters for Web APIstoo.
    89. 89. Priority:Lower CostPriority:Increased Adoption
    90. 90. PortalAPI
    91. 91. PortalAPIDeveloperEnd UserAdministrator
    92. 92. PortalAPI
    93. 93. This is obvious right?
    94. 94. Why is this difficult to do inpractice?
    95. 95. Reason #1We project our own perspective.
    96. 96. Reason #2We project our own biases.
    97. 97. Never use SOAP?Why?
    98. 98. Consider keyboards…
    99. 99. http://www.flickr.com/photos/yvettemn/139890573/
    100. 100. http://www.flickr.com/photos/jonathanpberger/7126054997/
    101. 101. http://www.flickr.com/photos/novemberborn/286773981/
    102. 102. OR
    103. 103. It doesn’t matter that you don’t likeSOAP.
    104. 104. What matters is what your developerbase thinks!(and what your objective is)
    105. 105. Reason #3We make bad assumptions.
    106. 106. API publishers are also developers.
    107. 107. “I built a mobile app once.”
    108. 108. Reason #4We lack the time, money orincentive for good design
    109. 109. “Best practices”, patterns andstandards become shortcuts
    110. 110. Am I RESTfull enough?
    111. 111. So, how can we do better?
    112. 112. Developer-centric design requireseffort and diligence.
    113. 113. Design with the developer in mind.
    114. 114. Ask them.
    115. 115. • Interviews• Surveys• Listen (blogs, presentations,tweets)
    116. 116. +
    117. 117. • Observe• Prototype• Historical Data
    118. 118. Consider all aspects of the DX:RegistrationSecurityTroubleshootingLearningInterface Style
    119. 119. A Good DX = A Good System
    120. 120. Tunnel StyleURI StyleHypermedia StyleEvent Driven Style
    121. 121. RegistrationLazy RegistrationSocial IntegrationPersonalization
    122. 122. Development Activity Cycle1. Learn2. Code3. Implement4. Test5. Fix
    123. 123. PortalAPILearnCodeTest
    124. 124. APILearnTest
    125. 125. API explorers and “livedocumentation” can shorten thegap between visibility andfeedback.
    126. 126. Troubleshooting and FeedbackProvide useful information at runtimeProvide useful post-run information
    127. 127. TLSOAuth 2Open ID Connect
    128. 128. SecuritySecurity can hurt UsabilityBut… security can also improve theoverall experience!We need to think about the system as awhole
    129. 129. Complexity• Sometimes complexity is necessary –that is ok• Enough features to meetrequirements• Don’t hurt the DX – use structureand modularity
    130. 130. Structure and ConsistencyDefine a consistent Message Structure{ “Response” : {“Errors” : {}}}
    131. 131. Structure and ConsistencyDefine consistent standards for:• Naming• Collection structure• Content negotiation• Links
    132. 132. ModularityPartition APIs into modules orproductsFrom a DEVELOPER perspective!
    133. 133. “Frictionless” integrationHigh rates of adoptionLow cost integrationWe want:
    134. 134. Behaviour DesignBJ Fogg
    135. 135. Visitor Invested Developer
    136. 136. Visitor Invested DeveloperJoy Joy Joy
    137. 137. A Sample DX Based Design Process
    138. 138. 1. Identify the problem space2. Learn about the audience3. Design Interactions4. Make API design choices thatare developer-centric5. Prototype and get feedback6. Iterate
    139. 139. The Problem SpaceWhy are we doing this?Who are we building it for?
    140. 140. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
    141. 141. Consider:PlatformsOrganizationsLanguagesWho is this for?
    142. 142. The Problem SpaceWhat are our:Assumptions?Constraints?Shared terms and jargon?
    143. 143. Data GatheringHow do we learn about our targetaudience?
    144. 144. Interaction ModelDefine requirements:What interactions will benefit thedeveloper?What information is required tosupport the interaction?
    145. 145. Interaction ModelAs a ___ I want to …
    146. 146. Map Interactions to an API DesignWhich style?Which formats?How do we translate interactions?
    147. 147. PrototypeDon’t bind to real data or backendUse something lightweight and easyto changeDo this early
    148. 148. Focus on the interactions that takeplace, rather than the interfaceswe expose
    149. 149. DX > Software Qualities
    150. 150. Great API design can thrive in adeveloper-centric environment
    151. 151. Usability Summary• Focus on the developer• Start by thinking in terms of interactions• Effective for public and private APIs
    152. 152. www.apiacademy.co
    153. 153. Considerations for an API StrategyRonnie MitraPrincipal API Architect - EuropeLayer 7 API Academy

    ×