API Introduction - API Management Workshop Munich from Ronnie Mitra
•
5 likes•2,169 views
This document summarizes an API workshop presentation focused on key topics in API design including API styles, usability, security, and architecture. The presentation discusses common API styles like tunnel, URI, hypermedia, and event-driven and how to choose a style based on constraints and goals. It emphasizes the importance of usability and a developer-centric design approach. The presentation also covers securing APIs using standards like OAuth and TLS and designing layered API architectures with elements like representation, caching, and orchestration layers. It compares API management to traditional SOA governance approaches.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (7)
Similar to API Introduction - API Management Workshop Munich from Ronnie Mitra
Similar to API Introduction - API Management Workshop Munich from Ronnie Mitra (20)
More from CA API Management
More from CA API Management (20)
API Introduction - API Management Workshop Munich from Ronnie Mitra
- 1. API Workshop Ronnie Mitra Principal API Architect - Europe Layer 7 API Academy
- 4. API Academy Mike Amundsen Ronnie Mitra
- 6. Business of APIs API Styles Usability Security API Architecture SOA Governance
- 10. API All programmers are API designers Connections between modules Language Dependant APIs are constrained by the syntax of the language
- 11. … over the web
- 12. 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
- 13. Web of Documents Web of Apps Web of Services Web of Things
- 14. The web is ubiquitous And universally accessible
- 16. We are surrounded by Web APIs
- 17. Did you check the weather today?
- 22. Private or Closed APIs
- 25. Public or Open APIs
- 29. Business of APIs
- 30. why build an API?
- 31. Innovation Consumer Reach Revenue Source Marketing Integration Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project
- 32. Innovation Consumer Reach Revenue Source Marketing Integration Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project
- 33. Revenue Source
- 35. Revenue Source 1000 calls/month 5000 calls/month
- 36. Revenue Source 500 calls/month 1000 calls/month 5000 calls/month
- 37. Revenue Source Is your content worth paying for?
- 38. Innovation Consumer Reach Revenue Source Marketing Integration Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project
- 39. Consumer Reach
- 40. Consumer Reach
- 41. Head Long Tail Consumer Reach
- 42. Innovation Consumer Reach Revenue Source Marketing Integration Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project
- 43. Marketing Affiliate Programs Sometimes you pay the developer.
- 44. Marketing Draw new visitors in.
- 45. Marketing
- 46. Innovation Consumer Reach Revenue Source Marketing Integration Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project
- 47. Innovation Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project Innovation from within
- 48. Innovation Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project Innovation outside your borders
- 49. Innovation Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project When does innovation happen?
- 50. Innovation Consumer Reach Revenue Source Marketing Integration Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project
- 51. Integration Business driven integration Regulatory driven integration
- 52. Observational Learning: Five Short Stories of Public APIs
- 53. 2000 – ebay
- 54. Started with a paid developer program in 2000 Made it free in 2005
- 56. Large developer eco-system Large app eco-system
- 57. 25% of eBay listings come from their API!
- 60. API as a cloud enabler
- 61. 2004 – Flickr
- 64. The rise of self-service Announced 6 billion photos in August 2011
- 65. 2006 – Amazon Web Services
- 66. Started as an online book shop… Became a department store… now?
- 68. 2004: Hey, why don’t we sell this?
- 69. Revenue Source
- 70. Estimated revenue: $1.5B in 2012 http://wikibon.org/wiki/v/Cloud_Computing_2013%3A_The_Amazon_Gorilla_Invades_the_Enterprise
- 71. Twilio or stripe 2007 - Twillio
- 72. Revenue Source
- 73. The API is the business
- 74. 100,000 developer milestone in 2012
- 75. Original APIs are still successful New business models have emerged Different drivers have influenced API design Summary
- 76. Why make an API Public?
- 77. Unlock new markets External innovation Drive revenue “Free” development Crowdbased asset development
- 81. Don’t forget: More developers = Higher Costs
- 82. Bandwidth Technical Support Processing and Storage ?
- 83. Documentation Tools Evangelists and communities Supporting Developers Connector designed by R Chow from The Noun Project Notepad designed by Luis Prado from The Noun Project
- 84. API Management
- 85. To ensure failure, make your API: • difficult to understand • dangerous to use (unsafe) • unreliable and unstable • opaque (provides no visibility)
- 86. API management helps us: • Drive adoption • Lower costs • Keep existing users • Reduce friction
- 87. Innovation Consumer Reach Revenue Source Marketing Integration Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project
- 88. Without API management an API is naked.
- 89. Business of APIs Summary • Understand the business motivation • Choose a style that fits your constraints and goals
- 90. API Styles
- 91. What does a Web API look like?
- 92. Web APIs HTTP
- 95. Tunnel Style URI Style Hypermedia Style Event Driven Style
- 96. Tunnel Style Example: SOAP • transport agnostic • operation based • binding documents (WSDL)
- 98. Tunnel Style • lots of tooling • not restricted to HTTP • RPC Advantages
- 99. Tunnel Style • inefficient for HTTP • increased learning curve • lack of tooling in mobile Trade-offs
- 102. URI Style • familiar to web developers • designed for HTTP • URIs are intuitive Advantages
- 103. URI Style • limited to four methods • URI design is not standard • can be ‘chatty’ Trade-offs
- 104. Hypermedia Style
- 105. Hypermedia Style • links • templated input (forms) • task based
- 106. { links: [ link {href: ‘…’ rel: ‘list’}, link {href: ‘…’ rel: ‘add’} ] collection: [ {link: {rel:'complete',href:‘…'}, id:42, text:‘Record 42' } ] }
- 107. Hypermedia Style • designed for HTTP • long lasting • no URI construction Advantages
- 108. Hypermedia Style • leading-edge • requires ‘smarter’ apps • less familiar to developers Trade-offs
- 109. Event Driven Style Example: WebSockets • event based communication • server initiated events • full-duplex (websocket)
- 110. Event Driven Style • less overhead • better performance Advantages
- 111. Event Driven Style • not HTTP-based • resource intensive connections • inefficient for request-reply Trade-offs
- 112. API Styles Summary • Web API != standard • Four popular styles: Tunnel, URI, Hypermedia, Event • Choose a style that fits your constraints and goals
- 113. Usability
- 114. Interaction Design
- 115. Usability Human-Computer-Interaction User Experience Design Goal Oriented Design
- 116. A user-centric view of design.
- 118. Well designed products are easier to use.
- 119. Good design matters for Web APIs too.
- 120. “Frictionless” integration High rates of adoption Low cost integration We want:
- 121. Focus on the developer experience (dx)
- 122. Portal API
- 123. Why is this difficult?
- 124. Reason #1 We project our own perspective.
- 127. Your code is not your API. Your data model is not your API.
- 128. Reason #2 We project our own biases.
- 129. Never use SOAP? Why?
- 130. Consider keyboards…
- 134. It doesn’t matter that you don’t like SOAP.
- 135. What matters is what your developer base thinks!
- 136. Reason #3 We make bad assumptions.
- 137. API publishers are also developers.
- 138. Reason #4 We lack the time, money or incentive for good design
- 139. “Best practices”, patterns and standards become shortcuts
- 140. Am I RESTfull enough?
- 141. So, how can we do better?
- 142. Developer-centric design requires effort and diligence.
- 145. Is the answer an SDK?
- 146. An SDK shifts the design effort but does not resolve the usability challenge
- 147. Design with the developer in mind.
- 148. Ask them.
- 149. • Interviews • Surveys • Listen (blogs, presentations, tweets)
- 150. "If I had asked people what they wanted, they would have said faster horses.“ – Henry Ford?
- 151. • Observe • Prototype • Historical Data
- 152. Consider all aspects of the DX: Registration Security Troubleshooting Learning Interface Style
- 154. Development Activity Cycle 1. Learn 2. Code 3. Implement 4. Test 5. Fix
- 156. API Learn Test
- 157. API explorers and “live documentation” can shorten the gap between visibility and feedback.
- 158. 1. Identify a Target Audience 2. Learn about the audience 3. Make API design choices that are developer-centric 4. Prototype and get feedback 5. Iterate How?
- 159. Focus on the interactions that take place, rather than the interfaces we expose
- 160. Great API design can thrive in a developer-centric environment
- 161. Usability Summary • Focus on the developer • Start by thinking in terms of interactions • Effective for public and private APIs
- 162. Securing APIs
- 163. OWASP Top Ten (2010 Edition) Source: http://www.owasp.org/index.php/Top_10
- 164. The primary API management challenge: Balancing Control and Accessibility
- 167. TLS OAuth 2 Open ID Connect
- 168. OAuth provides a Delegated Authorization Framework
- 172. http://www.flickr.com/photos/grumbler/571106054/ http://www.flickr.com/photos/roboppy/238406811/ Your Money This Shop Needs Your Money You need to grant access to your money
- 175. Granting access to someone to act on your behalf.
- 176. Your resources This app needs to act on your behalf You need to grant access to your resources
- 177. Your google+ data This app needs to access your Google+ data You need to grant access to your resources
- 178. Hi Google. I’d like to have access to a user’s data.
- 179. Hang on, let me ask…
- 181. He said yes. Here is your access code.
- 182. Proprietary authorization implementations OAuth (2007) OWrap OAuth 2 History of OAuth
- 183. OAuth 2 Grant Types Grant Types: - Authorization Code - Implicit - Resource Owner Password Credentials - Client Credentials
- 184. OAuth 2 Challenges It is a framework
- 185. 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
- 186. 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
- 187. 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-user Client Application Resource Owner Authorization Server User Agent Send User Authentication Form ? Authenticate
- 188. OpenID Authentication can help the server authenticate the end-user OpenID Connect provides a mechanism for the application to learn about the end- user Open ID, Open ID Connect and OAuth 2 Client Application Resource Owner Authorization Server User Agent Send OpenID Authentication Form Authenticate Retrieve User Information OpenID Resource Server
- 192. Security Summary • Keep focus on usability • Utilize standards like OAuth and TLS • Danger in poor implementations
- 193. Designing an API Architecture
- 196. Representation Layer
- 198. Component Database File System Message Queue Transaction Manager Source Code
- 200. Connector Web Server Browser Agent Proxy Server Shared Cache
- 205. The Treachery of Images - René Magritte
- 206. 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
- 207. • Data and Interface Transformation • Focus on the interface (usability) Representation SOAP Legacy
- 208. Security Layer
- 209. Security implementations are difficult: • Mistakes are costly • Hard to understand specifications • Performance can suffer
- 210. Don’t implement security in the API Enforce security at the edge
- 211. Caching Layer
- 212. Caching Layer
- 213. 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.
- 214. Orchestration Layer
- 215. • Chaining multiple calls • Aggregating and enriching data • ‘mashup’ external data with internal data Orchestration:
- 217. Gateway Pattern Abstraction of multiple interfaces In Software Engineering: Façade Pattern Benefits: - Deliver a consistent experience - Centralize API functionality http://martinfowler.com/eaaCatalog/gateway.html
- 219. Restrict Access Improve Performance Focus on Usability
- 220. The gateway doesn’t solve all our problems
- 221. API portals Portal
- 223. We also apply this philosophy behind the firewall.
- 224. Architecture Summary • Use a layered architecture • Deploy a gateway for runtime • Deploy a portal for developers
- 225. SOA Governance vs. API Management
- 226. Web APIs: New and Exciting! http://www.flickr.com/photos/every1knows/4191971139
- 227. “Web APIs? I’ve been doing that for years.” Image courtesy of http://www.flickr.com/photos/en321/3902138429/
- 228. Web APIs offer us a new perspective http://www.flickr.com/photos/mugley/4407790613
- 229. The Modern Philosophy of the Web API: • self service • lower barriers and lower costs • developer-centric
- 230. All hail the developer kings!
- 231. SOA Governance Enforce access control Promote service usage Provide service discovery documents Provide service usage visibility
- 232. API Management Enforce access control Promote API usage Provide API documentation Provide API usage visibility
- 233. SOA Governance How do we make sure that these services are used properly?
- 234. API Management How do we get people to use our API without falling over?
- 236. Representing organizations is useful Complexity sucks Focus on the user What can we learn from SOA Governance?
- 237. Web APIs are acting on a planetary scale Service Service Service ESB ISB API API API
- 238. SOA Governance Summary • Different but converging • Developer based perspective • Based on success
- 239. API Workshop Ronnie Mitra Principal API Architect - Europe Layer 7 API Academy