API Introduction - API Management Workshop Munich from Ronnie Mitra

1,024 views

Published on

Ronnie Mitra's slides from the Layer 7 Munich API Management Workshop. This workshop will included talks from Softcon CTO Michel Dorochevsky and Layer 7 API Architect Ronnie Mitra.

The workshop Covered:
• Discover the latest trends in the API economy
• Understand why API Management is important
• Learn best practices for securely exposing your APIs
• Find out what other organizations are doing to manage their APIs

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

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

No notes for slide

API Introduction - API Management Workshop Munich from Ronnie Mitra

  1. 1. API WorkshopRonnie MitraPrincipal API Architect - EuropeLayer 7 API Academy
  2. 2. API Managementvirtual cloudon-premise
  3. 3. API AcademyMike Amundsen Ronnie Mitra
  4. 4. www.apiacademy.co
  5. 5. Business of APIsAPI StylesUsabilitySecurityAPI ArchitectureSOA Governance
  6. 6. What areWeb APIs?
  7. 7. Connecting things
  8. 8. Connecting computer programs
  9. 9. APIAll programmers are API designersConnections between modulesLanguage DependantAPIs are constrained by the syntax of thelanguage
  10. 10. … over the web
  11. 11. Web APIsLanguage IndependentAPIs are constrained by the syntax of the webMost API Design principles can be appliedSome design principles are unique to Web APIs
  12. 12. Web ofDocumentsWeb ofAppsWeb ofServicesWeb ofThings
  13. 13. The web is ubiquitousAnd universally accessible
  14. 14. Publishers retain control
  15. 15. We are surrounded by Web APIs
  16. 16. Did you check the weather today?
  17. 17. Private or Closed APIs
  18. 18. Acme Corp.APIAcme Corp.App
  19. 19. Public or Open APIs
  20. 20. Acme Corp.APIThird PartyApp
  21. 21. Priority:Lower CostPriority:Increased Adoption
  22. 22. Business of APIs
  23. 23. why build an API?
  24. 24. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
  25. 25. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
  26. 26. Revenue Source
  27. 27. Revenue Sourcehttp://www.flickr.com/photos/inside-south-africa/485356704£0.10 per API Call
  28. 28. Revenue Source1000 calls/month5000 calls/month
  29. 29. Revenue Source500 calls/month1000 calls/month5000 calls/month
  30. 30. Revenue SourceIs your content worth paying for?
  31. 31. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
  32. 32. Consumer Reach
  33. 33. Consumer Reach
  34. 34. Head Long TailConsumer Reach
  35. 35. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
  36. 36. MarketingAffiliate ProgramsSometimes you pay the developer.
  37. 37. MarketingDraw new visitors in.
  38. 38. Marketing
  39. 39. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
  40. 40. InnovationLight Bulb designed by Jean-Philippe Cabaroc from The Noun ProjectInnovation from within
  41. 41. InnovationLight Bulb designed by Jean-Philippe Cabaroc from The Noun ProjectInnovation outside your borders
  42. 42. InnovationLight Bulb designed by Jean-Philippe Cabaroc from The Noun ProjectWhen does innovation happen?
  43. 43. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
  44. 44. IntegrationBusiness driven integrationRegulatory driven integration
  45. 45. Observational Learning:Five Short Stories of Public APIs
  46. 46. 2000 – ebay
  47. 47. Started with a paid developer program in 2000Made it free in 2005
  48. 48. Consumer ReachMarketing
  49. 49. Large developer eco-systemLarge app eco-system
  50. 50. 25% of eBay listings come from their API!
  51. 51. salesforce2000 – salesforce
  52. 52. IntegrationRevenue Source
  53. 53. API as a cloud enabler
  54. 54. 2004 – Flickr
  55. 55. web 2.0 generation
  56. 56. Consumer ReachMarketing
  57. 57. The rise of self-serviceAnnounced 6 billion photos in August 2011
  58. 58. 2006 – Amazon Web Services
  59. 59. Started as an online book shop…Became a department store…now?
  60. 60. Jeff BezosConnect everythinghttp://www.flickr.com/photos/zippy/2430495092
  61. 61. 2004:Hey, why don’t we sell this?
  62. 62. Revenue Source
  63. 63. Estimated revenue:$1.5B in 2012http://wikibon.org/wiki/v/Cloud_Computing_2013%3A_The_Amazon_Gorilla_Invades_the_Enterprise
  64. 64. Twilio or stripe2007 - Twillio
  65. 65. Revenue Source
  66. 66. The API is the business
  67. 67. 100,000 developer milestone in 2012
  68. 68. Original APIs are still successfulNew business models have emergedDifferent drivers have influenced API designSummary
  69. 69. Why make an API Public?
  70. 70. Unlock new marketsExternal innovationDrive revenue“Free” developmentCrowdbased asset development
  71. 71. Promote Mutual Gain(Symbiosis)
  72. 72. http://upload.wikimedia.org/wikipedia/commons/f/ff/Aedes_albopictus_cdc.jpg
  73. 73. http://commons.wikimedia.org/wiki/File:Arothron_hispidus_is_being_cleaned_by_Hawaiian_cleaner_wrasses,_Labroides_phthirophagus_1.jpg
  74. 74. Don’t forget:More developers = Higher Costs
  75. 75. BandwidthTechnical SupportProcessing and Storage?
  76. 76. DocumentationToolsEvangelists and communitiesSupporting DevelopersConnector designed by R Chow from The Noun ProjectNotepad designed by Luis Prado from The Noun Project
  77. 77. API Management
  78. 78. To ensure failure, make your API:• difficult to understand• dangerous to use (unsafe)• unreliable and unstable• opaque (provides no visibility)
  79. 79. API management helps us:• Drive adoption• Lower costs• Keep existing users• Reduce friction
  80. 80. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
  81. 81. Without API management an API is naked.
  82. 82. Business of APIs Summary• Understand the business motivation• Choose a style that fits your constraintsand goals
  83. 83. API Styles
  84. 84. What does a Web API look like?
  85. 85. Web APIsHTTP
  86. 86. Architectural Styles
  87. 87. Tunnel StyleURI StyleHypermedia StyleEvent Driven Style
  88. 88. Tunnel StyleExample: SOAP• transport agnostic• operation based• binding documents (WSDL)
  89. 89. Tunnel Style<RetrieveStudentRecords><StudentId>1213</StudentId></RetrieveStudentRecords>
  90. 90. Tunnel Style• lots of tooling• not restricted to HTTP• RPCAdvantages
  91. 91. Tunnel Style• inefficient for HTTP• increased learning curve• lack of tooling in mobileTrade-offs
  92. 92. URI StyleGETPUTPOSTDELETE+ URI
  93. 93. URI StyleGET /students/1232
  94. 94. URI Style• familiar to web developers• designed for HTTP• URIs are intuitiveAdvantages
  95. 95. URI Style• limited to four methods• URI design is not standard• can be ‘chatty’Trade-offs
  96. 96. Hypermedia Style
  97. 97. Hypermedia Style• links• templated input (forms)• task based
  98. 98. {links: [link {href: ‘…’ rel: ‘list’},link {href: ‘…’ rel: ‘add’}]collection: [{link: {rel:complete,href:‘…},id:42,text:‘Record 42}]}
  99. 99. Hypermedia Style• designed for HTTP• long lasting• no URI constructionAdvantages
  100. 100. Hypermedia Style• leading-edge• requires ‘smarter’ apps• less familiar to developersTrade-offs
  101. 101. Event Driven StyleExample: WebSockets• event based communication• server initiated events• full-duplex (websocket)
  102. 102. Event Driven Style• less overhead• better performanceAdvantages
  103. 103. Event Driven Style• not HTTP-based• resource intensive connections• inefficient for request-replyTrade-offs
  104. 104. API Styles Summary• Web API != standard• Four popular styles: Tunnel, URI,Hypermedia, Event• Choose a style that fits your constraintsand goals
  105. 105. Usability
  106. 106. InteractionDesign
  107. 107. UsabilityHuman-Computer-InteractionUser Experience DesignGoal Oriented Design
  108. 108. A user-centric view of design.
  109. 109. http://www.flickr.com/photos/58754750@N08/5541472392/
  110. 110. Well designed products are easierto use.
  111. 111. Good design matters for Web APIstoo.
  112. 112. “Frictionless” integrationHigh rates of adoptionLow cost integrationWe want:
  113. 113. Focus on the developer experience(dx)
  114. 114. PortalAPI
  115. 115. Why is this difficult?
  116. 116. Reason #1We project our own perspective.
  117. 117. Your code is not your API.Your data model is not your API.
  118. 118. Reason #2We project our own biases.
  119. 119. Never use SOAP?Why?
  120. 120. Consider keyboards…
  121. 121. http://www.flickr.com/photos/yvettemn/139890573/
  122. 122. http://www.flickr.com/photos/jonathanpberger/7126054997/
  123. 123. http://www.flickr.com/photos/novemberborn/286773981/
  124. 124. It doesn’t matter that you don’t likeSOAP.
  125. 125. What matters is what yourdeveloper base thinks!
  126. 126. Reason #3We make bad assumptions.
  127. 127. API publishers are also developers.
  128. 128. Reason #4We lack the time, money orincentive for good design
  129. 129. “Best practices”, patterns andstandards become shortcuts
  130. 130. Am I RESTfull enough?
  131. 131. So, how can we do better?
  132. 132. Developer-centric design requireseffort and diligence.
  133. 133. Is the answer an SDK?
  134. 134. An SDK shifts the design effort butdoes not resolve the usabilitychallenge
  135. 135. Design with the developer in mind.
  136. 136. Ask them.
  137. 137. • Interviews• Surveys• Listen (blogs, presentations,tweets)
  138. 138. "If I had asked people what theywanted, they would have saidfaster horses.“ – Henry Ford?
  139. 139. • Observe• Prototype• Historical Data
  140. 140. Consider all aspects of the DX:RegistrationSecurityTroubleshootingLearningInterface Style
  141. 141. RegistrationLazy RegistrationSocial IntegrationPersonalization
  142. 142. Development Activity Cycle1. Learn2. Code3. Implement4. Test5. Fix
  143. 143. PortalAPILearnCodeTest
  144. 144. APILearnTest
  145. 145. API explorers and “livedocumentation” can shorten thegap between visibility andfeedback.
  146. 146. 1. Identify a Target Audience2. Learn about the audience3. Make API design choices thatare developer-centric4. Prototype and get feedback5. IterateHow?
  147. 147. Focus on the interactions that takeplace, rather than the interfaceswe expose
  148. 148. Great API design can thrive in adeveloper-centric environment
  149. 149. Usability Summary• Focus on the developer• Start by thinking in terms of interactions• Effective for public and private APIs
  150. 150. Securing APIs
  151. 151. OWASP Top Ten (2010 Edition)Source: http://www.owasp.org/index.php/Top_10
  152. 152. The primary API managementchallenge:BalancingControl and Accessibility
  153. 153. IdentityAuthenticationAuthorizationAvailabilityIntegrityPrivacy
  154. 154. TLSOAuth 2Open ID Connect
  155. 155. OAuth provides aDelegated Authorization Framework
  156. 156. An imperfect analogy….
  157. 157. http://www.flickr.com/photos/drewleavy/5587005480
  158. 158. http://www.flickr.com/photos/24oranges/5791460046/
  159. 159. http://www.flickr.com/photos/grumbler/571106054/http://www.flickr.com/photos/roboppy/238406811/Your MoneyThis Shop Needs Your MoneyYou need to grant accessto your money
  160. 160. http://www.flickr.com/photos/drewleavy/5587005480I won’t tell.I promise!
  161. 161. www.flickr.com/photos/auntiep/255249516
  162. 162. Granting access to someone to acton your behalf.
  163. 163. Your resourcesThis app needs to act on your behalfYou need to grant accessto your resources
  164. 164. Your google+ dataThis app needs to access yourGoogle+ dataYou need to grant accessto your resources
  165. 165. Hi Google.I’d like to haveaccess to auser’s data.
  166. 166. Hang on,let meask…
  167. 167. He said yes.Here is youraccesscode.
  168. 168. Proprietary authorization implementationsOAuth (2007)OWrapOAuth 2History of OAuth
  169. 169. OAuth 2 Grant Types Grant Types:- Authorization Code- Implicit- Resource Owner Password Credentials- Client Credentials
  170. 170. OAuth 2 ChallengesIt is a framework
  171. 171. OAuth 2 Challenges New attack surfaces Flexible, but complex for API publishers to implement Utilizes redirection URIs (should be validated with strong rules) Poor implementations will be exposed (see Facebook) Not a solution to user authentication
  172. 172. OpenID Connect Identity Access and Authentication (when combined with Open ID) Built on top of OAuth 2 Not tied to any single vendor or identity provider
  173. 173. Open ID, Open ID Connect and OAuth 2 OAuth 2 allows an end-user to grant an application access to protected resources However:- The authorization server must still authenticate the end-user- The client application is unable to determine information about the end-userClient ApplicationResource Owner Authorization ServerUser AgentSendUserAuthenticationForm?Authenticate
  174. 174.  OpenID Authentication can help the server authenticate the end-user OpenID Connect provides a mechanism for the application to learn about the end-userOpen ID, Open ID Connect and OAuth 2Client ApplicationResource Owner Authorization ServerUser AgentSendOpenIDAuthenticationFormAuthenticateRetrieve UserInformationOpenIDResourceServer
  175. 175. Security Summary• Keep focus on usability• Utilize standards like OAuth and TLS• Danger in poor implementations
  176. 176. Designing an API Architecture
  177. 177. http://www.flickr.com/photos/naomi_pincher/3306312873/Layered Pattern
  178. 178. Representation Layer
  179. 179. Component != Connector
  180. 180. ComponentDatabaseFile SystemMessage QueueTransaction ManagerSource Code
  181. 181. Components Are Private
  182. 182. ConnectorWeb ServerBrowser AgentProxy ServerShared Cache
  183. 183. Connectors Are Public
  184. 184. Client ServerConnectorsComponentsThe Web
  185. 185. The Treachery of Images - René Magritte
  186. 186. Representation Layer Representation happens in the Connector HTTP supports content negotiation- Accept- Content-Type Differing clients (user-agents) === differing representations- Desktop- Browser- Tablet- Smartphone Be prepared to support multiple representations
  187. 187. • Data and Interface Transformation• Focus on the interface (usability)RepresentationSOAPLegacy
  188. 188. Security Layer
  189. 189. Security implementations are difficult:• Mistakes are costly• Hard to understand specifications• Performance can suffer
  190. 190. Don’t implement security in the APIEnforce security at the edge
  191. 191. Caching Layer
  192. 192. Caching Layer
  193. 193. Caching Layer Caching happens EVERYWHERE HTTP supports Expiration Model and Validation Model Caching Expiration Model- Expires- Cache-Control: max-age Validation Model- Last-Modified- Etag, If-Match Be prepared to support caching for both client and server Squid, Varnish, Nginx, MemCacheD, NSURLConnection etc.
  194. 194. Orchestration Layer
  195. 195. • Chaining multiple calls• Aggregating and enriching data• ‘mashup’ external data with internal dataOrchestration:
  196. 196. Gateway Pattern Abstraction of multiple interfaces In Software Engineering: Façade Pattern Benefits:- Deliver a consistent experience- Centralize API functionalityhttp://martinfowler.com/eaaCatalog/gateway.html
  197. 197. API GatewayGatewayAPIAPI
  198. 198. Restrict AccessImprove PerformanceFocus on Usability
  199. 199. The gateway doesn’t solve all our problems
  200. 200. API portalsPortal
  201. 201. API ManagementPortalGatewayAPIAPI
  202. 202. We also apply this philosophy behind the firewall.
  203. 203. Architecture Summary• Use a layered architecture• Deploy a gateway for runtime• Deploy a portal for developers
  204. 204. SOA Governance vs. API Management
  205. 205. Web APIs: New and Exciting!http://www.flickr.com/photos/every1knows/4191971139
  206. 206. “Web APIs? I’ve been doing that for years.”Image courtesy of http://www.flickr.com/photos/en321/3902138429/
  207. 207. Web APIs offer us a new perspectivehttp://www.flickr.com/photos/mugley/4407790613
  208. 208. The Modern Philosophy of the Web API:• self service• lower barriers and lower costs• developer-centric
  209. 209. All hail the developer kings!
  210. 210. SOA GovernanceEnforce access controlPromote service usageProvide service discovery documentsProvide service usage visibility
  211. 211. API ManagementEnforce access controlPromote API usageProvide API documentationProvide API usage visibility
  212. 212. SOA GovernanceHow do we make sure that theseservices are used properly?
  213. 213. API ManagementHow do we get people to use our APIwithout falling over?
  214. 214. Controlled versus Organic
  215. 215. Representing organizations is usefulComplexity sucksFocus on the userWhat can we learn from SOAGovernance?
  216. 216. Web APIs are acting on a planetary scaleServiceServiceServiceESBISBAPIAPIAPI
  217. 217. SOA Governance Summary• Different but converging• Developer based perspective• Based on success
  218. 218. API WorkshopRonnie MitraPrincipal API Architect - EuropeLayer 7 API Academy

×