Your SlideShare is downloading. ×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

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

1,514
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 …

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
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,514
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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.
  • Transcript

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