Considerations For an API Strategy - Ronnie MItra API Architect Layer 7 London Workshop
7 likes2,769 views
The document outlines key considerations for developing an effective API strategy, emphasizing the importance of understanding business drivers such as innovation, consumer reach, and revenue sources. It discusses different API styles, the significance of the developer experience in API design, and strategies for improving usability and adoption. Ultimately, successful API development requires a developer-centric approach, iterative design, and attention to interaction models.
![{
links: [
link {href: ‘…’ rel: ‘list’},
link {href: ‘…’ rel: ‘add’}
]
collection: [
{link: {rel:'complete',href:‘…'},
id:42,
text:‘Record 42'
}
]
}](https://image.slidesharecdn.com/considerationsforanapistrategy-130613113646-phpapp01/85/Considerations-For-an-API-Strategy-Ronnie-MItra-API-Architect-Layer-7-London-Workshop-75-320.jpg)
Considerations For an API Strategy - Ronnie MItra API Architect Layer 7 London Workshop
- 1. Considerations for an API Strategy Ronnie Mitra Principal API Architect - Europe Layer 7 API Academy
- 2. Business Drivers The Developer Experience API Architecture Agenda
- 4. Private or Closed APIs
- 7. Public or Open APIs
- 11. why build an API?
- 12. Innovation Consumer Reach Revenue Source Marketing Integration Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project
- 13. Innovation Consumer Reach Revenue Source Marketing Integration Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project
- 14. Revenue Source
- 15. Revenue Source http://www.flickr.com/photos/inside-south-africa/485356704 £0.10 per API Call
- 16. Revenue Source 1000 calls/month 5000 calls/month
- 17. Revenue Source 500 calls/month 1000 calls/month 5000 calls/month
- 18. Revenue Source Is your content worth paying for?
- 19. Innovation Consumer Reach Revenue Source Marketing Integration Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project
- 20. Consumer Reach
- 21. Consumer Reach
- 22. Platforms are not forever!
- 23. Innovation Consumer Reach Revenue Source Marketing Integration Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project
- 24. Marketing Affiliate Programs Sometimes you pay the developer.
- 25. Marketing Draw new visitors in.
- 26. Marketing
- 27. Marketing Stay above the noise: New channels Information-centric marketing
- 28. Innovation Consumer Reach Revenue Source Marketing Integration Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project
- 29. Innovation Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project Innovation from within
- 30. Innovation Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project Innovation outside your borders
- 31. Innovation Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project When does innovation happen?
- 32. Innovation Consumer Reach Revenue Source Marketing Integration Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project
- 33. Integration Business driven integration Regulatory driven integration
- 34. Observational Learning: Five Famous Stories of Public APIs
- 35. 2000 – ebay
- 36. Started with a paid developer program in 2000 Made it free in 2005
- 38. Large developer eco-system Large app eco-system
- 39. 25% of eBay listings come from their API!
- 42. API as a cloud enabler
- 43. 2004 – Flickr
- 44. web 2.0 generation the social evolution
- 46. The rise of self-service Announced 6 billion photos in August 2011
- 47. 2006 – Amazon Web Services
- 48. Started as an online book shop… Became a department store… now?
- 50. 2004: Hey, why don’t we sell this?
- 51. Revenue Source
- 52. Estimated revenue: $1.5B in 2012 http://wikibon.org/wiki/v/Cloud_Computing_2013%3A_The_Amazon_Gorilla_Invades_the_Enterprise
- 53. Twilio or stripe 2007 - Twillio
- 54. Revenue Source
- 55. The API is the business
- 56. 100,000 developer milestone in 2012
- 57. Original APIs are still successful New business models have emerged Know your drivers – design accordingly Summary
- 58. API Styles
- 59. What does a Web API look like?
- 60. Web APIs HTTP
- 61. Network Based APIs HTTP COAP MQTT WebSocket?
- 64. Tunnel Style URI Style Hypermedia Style Event Driven Style
- 65. Tunnel Style Example: SOAP • transport agnostic • operation based • binding documents (WSDL)
- 67. Tunnel Style • lots of tooling • not restricted to HTTP • RPC Advantages
- 68. Tunnel Style • inefficient for HTTP • increased learning curve • lack of tooling in mobile Trade-offs
- 71. URI Style • familiar to web developers • designed for HTTP • URIs are intuitive Advantages
- 72. URI Style • limited to four methods • URI design is not standard • can be ‘chatty’ Trade-offs
- 73. Hypermedia Style
- 74. Hypermedia Style • links • templated input (forms) • task based
- 75. { links: [ link {href: ‘…’ rel: ‘list’}, link {href: ‘…’ rel: ‘add’} ] collection: [ {link: {rel:'complete',href:‘…'}, id:42, text:‘Record 42' } ] }
- 76. Hypermedia Style • designed for HTTP • long lasting • no URI construction Advantages
- 77. Hypermedia Style • leading-edge • requires ‘smarter’ apps • less familiar to developers Trade-offs
- 78. Event Driven Style Example: WebSockets • event based communication • server initiated events • full-duplex (websocket)
- 79. Event Driven Style • less overhead • better performance Advantages
- 80. Event Driven Style • not HTTP-based • resource intensive connections • inefficient for request-reply Trade-offs
- 81. API Styles Summary • Web API != standard • Four popular styles: Tunnel, URI, Hypermedia, Event • Choose a style that fits your constraints and business goals
- 83. designing APIs can be difficult
- 86. Focus on the developer experience (dx)
- 88. Usability Human-Computer-Interaction User Experience Design Goal Oriented Design
- 90. A user-centric view of design.
- 91. Well designed products are easier to use.
- 92. Good design matters for Web APIs too.
- 94. Portal API
- 96. Portal API
- 97. This is obvious right?
- 98. Why is this difficult to do in practice?
- 99. Reason #1 We project our own perspective.
- 102. Reason #2 We project our own biases.
- 103. Never use SOAP? Why?
- 104. Consider keyboards…
- 108. OR
- 109. It doesn’t matter that you don’t like SOAP.
- 110. What matters is what your developer base thinks! (and what your objective is)
- 111. Reason #3 We make bad assumptions.
- 112. API publishers are also developers.
- 113. “I built a mobile app once.”
- 114. Reason #4 We lack the time, money or incentive for good design
- 115. “Best practices”, patterns and standards become shortcuts
- 116. Am I RESTfull enough?
- 117. So, how can we do better?
- 118. Developer-centric design requires effort and diligence.
- 121. Design with the developer in mind.
- 122. Ask them.
- 123. • Interviews • Surveys • Listen (blogs, presentations, tweets)
- 124. +
- 125. • Observe • Prototype • Historical Data
- 126. Consider all aspects of the DX: Registration Security Troubleshooting Learning Interface Style
- 127. A Good DX = A Good System
- 128. Tunnel Style URI Style Hypermedia Style Event Driven Style
- 131. Development Activity Cycle 1. Learn 2. Code 3. Implement 4. Test 5. Fix
- 133. API Learn Test
- 134. API explorers and “live documentation” can shorten the gap between visibility and feedback.
- 135. Troubleshooting and Feedback Provide useful information at runtime Provide useful post-run information
- 136. TLS OAuth 2 Open ID Connect
- 137. Security Security can hurt Usability But… security can also improve the overall experience! We need to think about the system as a whole
- 138. Complexity • Sometimes complexity is necessary – that is ok • Enough features to meet requirements • Don’t hurt the DX – use structure and modularity
- 141. Structure and Consistency Define a consistent Message Structure { “Response” : { “Errors” : {} }}
- 142. Structure and Consistency Define consistent standards for: • Naming • Collection structure • Content negotiation • Links
- 143. Modularity Partition APIs into modules or products From a DEVELOPER perspective!
- 144. “Frictionless” integration High rates of adoption Low cost integration We want:
- 147. Visitor Invested Developer Joy Joy Joy
- 148. A Sample DX Based Design Process
- 149. 1. Identify the problem space 2. Learn about the audience 3. Design Interactions 4. Make API design choices that are developer-centric 5. Prototype and get feedback 6. Iterate
- 150. The Problem Space Why are we doing this? Who are we building it for?
- 151. Innovation Consumer Reach Revenue Source Marketing Integration Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project
- 153. The Problem Space What are our: Assumptions? Constraints? Shared terms and jargon?
- 154. Data Gathering How do we learn about our target audience?
- 155. Interaction Model Define requirements: What interactions will benefit the developer? What information is required to support the interaction?
- 156. Interaction Model As a ___ I want to …
- 157. Map Interactions to an API Design Which style? Which formats? How do we translate interactions?
- 158. Prototype Don’t bind to real data or backend Use something lightweight and easy to change Do this early
- 159. Focus on the interactions that take place, rather than the interfaces we expose
- 160. DX > Software Qualities
- 161. Great API design can thrive in a developer-centric environment
- 162. Usability Summary • Focus on the developer • Start by thinking in terms of interactions • Effective for public and private APIs
- 163. www.apiacademy.co
- 164. Considerations for an API Strategy Ronnie Mitra Principal API Architect - Europe Layer 7 API Academy
Editor's Notes
- #5: Make a slide with an example
- #8: Make a slide with an example
- #13: 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]
- #14: 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.
- #15: 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
- #20: 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.
- #21: 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?
- #22: 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?
- #24: 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.
- #29: 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.
- #30: 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]
- #31: 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]
- #32: 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]
- #33: 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.
- #34: 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]
- #39: Large amount of business generated through third party appsVery healthy app eco-system for end-users (lots of tooling)
- #40: Large amount of business generated through third party appsVery healthy app eco-system for end-users (lots of tooling)
- #45: Explain how this is important for Flickr’s business model (rapid growth?)
- #56: Developer = end user.
- #59: Copy and Paste from usability
- #60: They drive all of the technology that we use in our daily lives.
- #61: By our definition, a Web API includes SOAP, REST, HTTP, CSV… just about any type of interface deployed over the web.
- #62: By our definition, a Web API includes SOAP, REST, HTTP, CSV… just about any type of interface deployed over the web.
- #74: 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.
- #75: 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.
- #77: 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.
- #78: 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.
- #79: 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.
- #80: 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.
- #83: Copy and Paste from usability
- #86: Coined in the 1980sBut rooted in the design ideas of industrial age products and how users interact with technology
- #87: Our product is our API and our useris our developer.
- #88: Coined in the 1980sBut rooted in the design ideas of industrial age products and how users interact with technology
- #89: Lots of methodologies and terminology
- #91: We are not simply producing products that perform a funciton, but we consider how people (or users) will interact with the product.
- #92: They are intuitive, we spend less time understanding them, ultimately they are a pleasure.Conversely, poorly designed products are painful.
- #93: We talked about this, so highlight again.
- #96: Different identities
- #98: APIs are all about connectivity.
- #99: APIs are all about connectivity.
- #103: APIs are all about connectivity.
- #104: APIs are all about connectivity.
- #110: APIs are all about connectivity.
- #111: Different social conventions.Another form of this, is the question of RESTfulness.
- #112: APIs are all about connectivity.
- #115: APIs are all about connectivity.
- #116: [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?)
- #118: APIs are all about connectivity.
- #119: APIs are all about connectivity.
- #120: Designer mental model vs. user mental model
- #121: Designer mental model vs. user mental model
- #122: APIs are all about connectivity.
- #123: APIs are all about connectivity.
- #124: Moneysupermarket.com example
- #125: Designer mental model vs. user mental model
- #126: Box.com example
- #127: APIs are all about connectivity.
- #131: There is a delay between
- #132: There is a delay between
- #136: There is a delay between
- #138: There is a delay between
- #145: Tie good design back to the business value we want
- #150: APIs are all about connectivity.
- #152: 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]
- #160: APIs are all about connectivity.
- #161: APIs are all about connectivity.
- #162: APIs are all about connectivity.