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

API Workshop Amsterdam presented by API Architect Ronnie Mitra


Published on

This workshop with Ronnie Mitra, Layer 7's Principal API Architect, will examine the key foundational elements necessary for a solid API implementation strategy. …

This workshop with Ronnie Mitra, Layer 7's Principal API Architect, will examine the key foundational elements necessary for a solid API implementation strategy.

Building great APIs is about more than just design; it requires detailed, thoughtful execution. Your API strategy needs to meet the business requirements of your organisation but it must also be flexible enough to meet your developer community’s diverse needs.

Published in: Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Building an API Strategy:Introduction and the Business of APIsRonnie MitraPrincipal API Architect - EuropeLayer 7 API Academy
  • 2. API Managementvirtual cloudon-premise
  • 3. API AcademyMike Amundsen Ronnie Mitra
  • 4.
  • 5. Business DriversAPI Styles-- Break --The Developer ExperienceAPI ArchitectureSecuring APIs-- Break --Principles of URI DesignAgenda
  • 6. What areWeb APIs?
  • 7. Connecting things
  • 8. Connecting computer programs
  • 9. APIAll programmers are API designersConnections between modulesLanguage DependantAPIs are constrained by the syntax of thelanguage
  • 10. … over the web
  • 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. Web ofDocumentsWeb ofAppsWeb ofServicesWeb ofThings
  • 13. The web is ubiquitousAnd universally accessible
  • 14. Publishers retain control
  • 15. Private/Partner or Closed APIs
  • 16. Acme Corp.APIAcme Corp.App
  • 17. Public or Open APIs
  • 18. Acme Corp.APIThird PartyApp
  • 19. Priority:Lower CostPriority:Increased Adoption
  • 20. why build an API?
  • 21. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
  • 22. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
  • 23. Revenue Source
  • 24. Revenue Source£0.10 per API Call
  • 25. Revenue Source1000 calls/month5000 calls/month
  • 26. Revenue Source500 calls/month1000 calls/month5000 calls/month
  • 27. Revenue SourceIs your content worth paying for?
  • 28. RevenueSourceInternal Revenue (chargeback)Cost Reduction
  • 29. Revenue SourceStrategy Implications:• Maximize uptime andreliability• Target high revenue consumers• Competitive differentiatorsare a must
  • 30. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
  • 31. Consumer Reach
  • 32. Consumer Reach
  • 33. Platforms are not forever!
  • 34. Consumer ReachStrategy Implications:• UX driven interfaces• Specialization may berequired• Difficult to updateapplications
  • 35. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
  • 36. MarketingAffiliate ProgramsSometimes you pay the developer.
  • 37. MarketingDraw new visitors in.
  • 38. Marketing
  • 39. MarketingStay above the noise:New channelsInformation-centric marketing
  • 40. MarketingStrategy Implications:• Terms and Services are veryimportant• Identify and reward topperformers• Limit calls and restrictaccess when needed
  • 41. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
  • 42. InnovationLight Bulb designed by Jean-Philippe Cabaroc from The Noun ProjectInnovation from within
  • 43. InnovationLight Bulb designed by Jean-Philippe Cabaroc from The Noun ProjectInnovation outside your borders
  • 44. InnovationLight Bulb designed by Jean-Philippe Cabaroc from The Noun ProjectWhen does innovation happen?
  • 45. InnovationLight Bulb designed by Jean-Philippe Cabaroc from The Noun ProjectStrategy Implications:• Design interface for generaluse• Identify success stories• Eliminate misuse
  • 46. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
  • 47. IntegrationBusiness driven integrationRegulatory driven integration
  • 48. IntegrationStrategy Implications:• Reduce cost• Reduce cost• Reduce cost
  • 49. Observational Learning:Five Famous Stories of Public APIs
  • 50. 2000 – ebay
  • 51. Started with a paid developer program in 2000Made it free in 2005
  • 52. Consumer ReachMarketing
  • 53. Large developer eco-systemLarge app eco-system
  • 54. 25% of eBay listings come from their API!
  • 55. salesforce2000 – salesforce
  • 56. IntegrationRevenue Source
  • 57. API as a cloud enabler
  • 58. 2004 – Flickr
  • 59. web 2.0 generationthe social evolution
  • 60. Consumer ReachMarketing
  • 61. The rise of self-serviceAnnounced 6 billion photos in August 2011
  • 62. 2006 – Amazon Web Services
  • 63. Started as an online book shop…Became a department store…now?
  • 64. Jeff BezosConnect everything
  • 65. 2004:Hey, why don’t we sell this?
  • 66. Revenue Source
  • 67. Estimated revenue:$1.5B in 2012
  • 68. Twilio or stripe2007 - Twillio
  • 69. Revenue Source
  • 70. The API is the business
  • 71. 100,000 developer milestone in 2012
  • 72. Web API Modern Timeline2000Salesforce APIebay API2002Amazon API2004Flickr API2006Twitter APIFacebook APIGoogle (Maps) has7144registeredAPIsSources: apievangelist.comprogrammableweb.cominternetarchive.comSteve Yegge Rantoreilly.com2005ebay makesAPIs free2004First Web 2.0Conference2010Salesforce addsHTTP has1000registeredAPIs2005Programmableweb.comlaunched54 APIsregistered.
  • 73. Original APIs are still successfulNew business models have emergedKnow your drivers – design accordinglySummary
  • 74. Building an API Strategy:Introduction and the Business of APIsRonnie MitraPrincipal API Architect - EuropeLayer 7 API Academy
  • 75. Building an API Strategy:URI Style Design TipsRonnie MitraPrincipal API Architect - EuropeLayer 7 API Academy
  • 77. URI StyleGET /students/1232
  • 78. URI Style• familiar to web developers• designed for HTTP• URIs are intuitiveAdvantages
  • 79. URI Style• limited to HTTP methods• URI design is not standard• can be ‘chatty’Trade-offs
  • 80. What is ‘good’ API Design?• Easy to learn• Easy to use, even w/o documentation• Hard to misuse• Easy to read and maintain code that uses it• Sufficiently powerful to satisfy requirements• Easy to extend• Appropriate to audienceJoshua Bloch, Principal Software Engineer, Google.
  • 81. Principles of URI Style API Design• URIs should be intuitive and ‘hackable’• The interface should adhere to standards(RFC 2616 and RFC 3986)• The design should be extendable
  • 82. Naming URIs• Names matter!• Establish reserved words and keywords• Names should be meaningful (to theapplication developer)
  • 83. Naming URIs – ExamplesBad:• /Core_Items_DSTSM_1Good:• /charges
  • 84. Defining Resources• Translate interactions into nouns• Build a resource model• Avoid RPC/Tunnel style names• Not everything fits well into theCRUD + Object space
  • 85. Map InteractionsInteraction:“retrieve all my user’s messages”Object:Message
  • 86. Resource ModelMessageTitleAuthorBodyRecipientnnn1n1nn
  • 87. Avoid RPC NamesInteraction:“Retrieve newest messages”RPC-style Name:getNewMessages
  • 88. Not Always EasyInteraction:“Perform a spell-check on thismessage”Object:Message?What method is ‘spell-check’?
  • 89. Not Always EasyInteraction:“Perform a spell-check on thismessage”Object:SpellChecker
  • 90. Types of ResourcesLots of nounsA few operators or controllers
  • 91. Relationshipsmyapi/messagesmyapi/messages/14myapi/messages/
  • 92. RelationshipsDon’t expose relationships unless theyare useful to the developerEach path segment should beactionable
  • 94. GET• Retrieve a representation• ‘safe’ method according to RFC• no user-requested side effects• won’t impact data• ‘Conditional GET’ is supported withcaching• Don’t abuse for non-read operations
  • 95. PUT• Write a representation• Store the entity (full replacement)• Idempotent• Example:PUT /myapi/messages/14{Message}
  • 96. IdempotenceNo side-effects on identical callsPUT /myapi/messages/14Result: Message ReplacedPUT /myapi/messages/14Result: Message Replaced
  • 97. Full ReplacementPUT /myapi/messages/14{ “title”: “Welcome”}{“id”:”14”“title”:”Wlecome”“author”:”Ronnie”“body”: “Hi Glen, welcome to the team!”}On the Server:{“title”:”Wlecome”}
  • 98. Why not use PUT for partial update?• Breaks HTTP specification• No defined semantic – can produceunexpected results from a devperspective
  • 99. PATCH (Partial Update)• RFC 5789 (HTTP Patch)• Partially update an identifiedresource with the supplied entity• Example:PATCH /myapi/message/14{Partial Message}
  • 100. Patch Media Type• RFC 6902 – JSON Patch• Content-Type: application/json-patch+jsonPATCH /myapi/message/14 HTTP/1.1[{ "op": “replace", "path": "/subject", "value": “new" },{ "op": “add", "path": "/tags", "value": “urgent" }]
  • 101. Challenges with PATCH• Not part of HTTP 1.1 spec• Not widely adopted inimplementations• May not be familiar to developeraudience
  • 102. How do I implement PATCH inan environment that doesn’tsupport it?
  • 103. PATCH WorkaroundsTurn the target data into a URI object:HTTP PUT /myapi/messages/14/title
  • 104. PATCH WorkaroundsTunnel the patch with a custom header:X-HTTP-Method-Override: PATCH
  • 105. PATCH WorkaroundsUse a unique URL:HTTP POST /myapi/patches/messages/14HTTP POST /myapi/messages/14/patchesHTTP POST /myapi/messages/14;patch
  • 106. PATCH WorkaroundsUse PUT and break the specification
  • 107. POST• Write/Process an entity• Accept entity as sub-ordinateresource• Not Idempotent• No identifier specified (factorypattern):POST /myapi/messages
  • 108. Non-IdempotentPOST /myapi/messagesResult: Message #14 CreatedPOST /myapi/messagesResult: Message #15 Created
  • 109. DELETE• Delete identified resource• Example:DELETE /myapi/messages/14• Idempotent
  • 110. Method Tunneling• Older platforms may not support allverbs• Need to resort to embedding theverb in a header or parameter• Example:GET myapi/shops?method=POST• Avoid doing this
  • 111. RepresentationsExpose object properties that arerelevant to the developerEmbed child objects and properties,but need to decide on granularityDesign structures that are extensible –be careful when implementingschema
  • 112. Representations - Granularity{“id” : “14”“title” : “Welcome”“body” : “Hello!”“author” : “38820”}
  • 113. Representations - Granularity{“id” : “14”“title” : “Welcome”“body” : “Hello!”“author” : [ “id” : “38820”,“firstName” : “Ronnie” ]}
  • 114. Representations – GranularityConsiderationsChattiness vs. LatencyFrequency of changeInteraction (what data is needed?)
  • 115. Retrieve a Collection of Data• Example: “Retrieve all storelocations”• GET /shops
  • 116. Retrieve a Filtered Collection of Data• Filter by requesting children• GET /shops/london• GET /shops/amsterdam• Limited to objects and sub-objects• Difficult to retrieve unions/joins of data
  • 117. Retrieve a Filtered Collection of Data• Example: “Retrieve all store locations inLondon”• Use query parameter from URI spec• GET /shops?location=London• GET /shops?location=London,Amsterdam• GET /shops?location=London&sort=distance
  • 118. Complex Queries“retrieve all shops within a radius of 10 kmfrom a specific location that are openwithin specified hours and sell specificphones, devices and account plans”GET/shops?radius=10&location=8882,28832&open_time=38882034&close_time=23882343&phones=iphone,blackberry,samsung&plans=monthly_3GB,monthly_4GB,pay_go_2GB
  • 119. Complex QueriesURI space may be limitedLong queries can become difficult tomanageUse POST on an operator resource:POST /shopsquery{“radius” : “10”, “location” : “388203,838200”,“phones” : [“blackberry”, “iphone”]}
  • 120. Returning Collections• array of results• all properties and child elements?• collection responses can be BIG!
  • 121. Pagination• Just like websites – break data upinto manageable ‘pages’
  • 122. Pagination• data page mechanism/api/resource?page=3• fixed page sizePage 1 Page 2 Page 3 Page 4 Page 5 Page 6• easy to navigate
  • 123. Pagination• offset + count mechanism/api/resource?offset=10&count=20• client app dictates page size10 30• client calculates offset and count forpages
  • 124. Pagination• use links to navigate{“href”:“/api/resource?offset=11&count=20”,“rel”:“next”}• client doesn’t have to calculatelocation• easier to navigate through pages
  • 125. Pagination• use defaults to reduce ‘friction’• reduces learning curve for newdevelopers/api/resource?offset=10&count=20/api/resource/api/resource?offset=10&count=10
  • 126. Field Projection•‘property selection’, ‘zooming’• Collections can be too big for someclient• Allow client to select properties inrepresentations
  • 127. Field Projection - ExampleGET /myapi/messages?fields=title,body{[{“id”: “1”, “title” : “hi!”, “body” :“hello”}…]}
  • 128. Linking• Use links as identifiers{[{“id”: “/myapi/messages/13”},{“id”: “/myapi/messages/14”}]}
  • 129. LinkingAdvantages:• Developer doesn’t need to constructURI• URIs can change!Trade-offs:• Query parameters increasecomplexity
  • 130. Implementing LinkingLots of Standards:• HAL• SIREN• Collection + JSON• ATOM• XML LINKING• HTML
  • 131. Implementing LinkingLots of APIs just do this:{“link_name” : “link”}
  • 132. Implementing Versioning• myapi/v1/path• Try to extend instead of version• Don’t break what is already there• Clients should ignore what theydon’t understand• Introduce breaking changes if youwant to drive developers away.
  • 133. Content Types• XML• JSON• HTML
  • 134. XML• Not the same as SOAP / Tunnel Style• Widely used (AJAX, mobile, server)• W3C Standard, RFC 3023
  • 135. JSON• Usage rising• Popular amongst next-gen developers• JavaScript everywhere• RFC 4627
  • 136. XML vs. JSON?• Not very different• ‘<‘ vs. ‘{‘• Similar performance overhead• Most clients support both (XMLmore widely supported)• What do your developer’s prefer?
  • 137. HTML• Hypermedia content type• Web Form: application/x-www-form-urlencoded• Useful for simple name/value pairinput• Easy for developers to implement
  • 138. Selecting a Representation• Content Negotiation• HTTP Accept Header• URI based• /myapi/messages.xml
  • 139. Status Codes• 1xx: Informational• 2xx: Success• 3xx: Redirection• 4xx: Client Error• 5xx: Server Error
  • 140. Status Codes• You MUST use the correct category• The second part of the code (xx) islargely informational, but stillimportant• Reason phrases can be customized
  • 141. Status CodesClient libraries should handle statuscodes and act in an expected manner
  • 142. Error Handling• You might include an applicationlevel error code• Definitely Include a human readableerror message
  • 143. A Few Interactions
  • 144. Asynchronous RequestClient Resource202 AcceptedFire and Forget
  • 145. Asynchronous RequestClient Resource202 Accepted<link href=“…” rel=“status”/>StatusResource200 OK<status>complete</status><link href=“…” rel=“result”/>
  • 146. Server CallbackClient ResourceRegister200 OK200 OKNotify
  • 147. Server Event (Long Poll)Client ResourceBlock and Wait200 OKHTTP Abuse
  • 148. Optimizations
  • 149. Optimizations• Mobile and device platforms haveunique bandwidth constraints• Transport Level (HTTP)• API Design
  • 150. HTTP Optimizations• Compression• Negotiation (Accept-Encoding)• Example:• Is JSON more efficient than XML?Accept-Encoding: compress, gzip
  • 151. HTTP Optimizations• Pipelining• Multiple requests without waitingfor response• Supported in HTTP 1.1 (persistentconnections)• Idempotent actions only
  • 152. API Design OptimizationsReduce data size (pagination, fieldprojection)Reduce number of calls:• Composition• RPC batch• Caching
  • 153. CompositionURI style APIs can be chattyCombine interactions and expose onthe serverExample:/myapi/composer
  • 154. BatchingURI style APIs can be chattyCombine and invoke calls on the clientCan be complicated for the developer
  • 155. CachingMany forms of cachingHTTP Caching avoids use of networkWidely supported
  • 156. Adaptive Responses• Provide responses that are the bestfit for the calling application•Examples:• Reduced granularity• Different defaults• UI Driven
  • 157. URI Design Summary• Some standards, but lots of choices• Design with developer in mind• Consistency and structure areimportant
  • 158. Building an API Strategy:URI Style Design TipsRonnie MitraPrincipal API Architect - EuropeLayer 7 API Academy
  • 159. Building an API Strategy:The Developer ExperienceRonnie MitraPrincipal API Architect - EuropeLayer 7 API Academy
  • 160. designing APIs can be difficult
  • 161.
  • 162. UsabilityReliabilitySimplicitySecurityEtc…Software Qualities
  • 163. Focus on the developer experience(dx)
  • 164. Interaction DesignBill Moggridge
  • 165. UsabilityHuman-Computer-InteractionUser Experience DesignGoal Oriented Design
  • 166.
  • 167. A user-centric view of design.
  • 168. Well designed products are easierto use.
  • 169. Good design matters for Web APIstoo.
  • 170. Priority:Lower CostPriority:Increased Adoption
  • 171. PortalAPI
  • 172. PortalAPIDeveloperEnd UserAdministrator
  • 173. PortalAPI
  • 174. This is obvious right?
  • 175. Why is this difficult to do in practice?
  • 176. Reason #1We project our own perspective.
  • 177. Reason #2We project our own biases.
  • 178. Never use SOAP?Why?
  • 179. Consider keyboards…
  • 180.
  • 181.
  • 182.
  • 183. OR
  • 184. It doesn’t matter that you don’t likeSOAP.
  • 185. What matters is what your developerbase thinks!(and what your objective is)
  • 186. Reason #3We make bad assumptions.
  • 187. API publishers are also developers.
  • 188. “I built a mobile app once.”
  • 189. Reason #4We lack the time, money orincentive for good design
  • 190. “Best practices”, patterns andstandards become shortcuts
  • 191. Am I RESTfull enough?
  • 192. So, how can we do better?
  • 193. Developer-centric design requireseffort and diligence.
  • 194. Design with the developer in mind.
  • 195. Ask them.
  • 196. • Interviews• Surveys• Listen (blogs, presentations,tweets)
  • 197. +
  • 198. • Observe• Prototype• Analyze Historical Data
  • 199. Consider all aspects of the DX:RegistrationSecurityTroubleshootingLearningInterface Style
  • 200. A Good DX = A Good System
  • 201. Tunnel StyleURI StyleHypermedia StyleEvent Driven Style
  • 202. RegistrationLazy RegistrationSocial IntegrationPersonalization
  • 203. Development Activity Cycle1. Learn2. Code3. Implement4. Test5. Fix
  • 204. PortalAPILearnCodeTest
  • 205. APILearnTest
  • 206. API explorers and “livedocumentation” can shorten thegap between visibility andfeedback.
  • 207. LearningWADLs and WSDLs are niceBut provide real documentation for humans!Hypermedia =/= zero documentation
  • 208. TLSOAuth 2Open ID Connect
  • 209. SecuritySecurity can hurt UsabilityBut… security can also improve theoverall experience!We need to think about the system as awhole
  • 210. Complexity• Sometimes complexity is necessary –that is ok• Enough features to meetrequirements• Don’t hurt the DX – use structureand modularity
  • 211. Structure and ConsistencyDefine a consistent Message Structure{ “Response” : {“Errors” : {}}}
  • 212. Structure and ConsistencyDefine consistent standards for:• Naming• Collection structure• Content negotiation• Links
  • 213. Structure and ConsistencyEnforcing standards requiresorganizational disciplineEspecially difficult in largeorganizations!
  • 214. ModularityPartition APIs into modules orproductsFrom a DEVELOPER perspective!
  • 215. “Frictionless” integrationHigh rates of adoptionLow cost integrationWe want:
  • 216. Behaviour DesignBJ Fogg
  • 217. Visitor Invested Developer
  • 218. JoyVisitorInvested DeveloperJoyJoy
  • 219. A Sample DX Based Design Process
  • 220. 1. Define the problem space2. Design interactions3. Map the interaction to an APIstyle4. Prototype and get feedback5. Iterate
  • 221. The Problem SpaceWhy are we doing this?Who are we building it for?
  • 222. InnovationConsumer ReachRevenue SourceMarketingIntegrationLight Bulb designed by Jean-Philippe Cabaroc from The Noun Project
  • 223. Consider:PlatformsOrganizationsLanguagesWho is this for?
  • 224. The Problem SpaceWhat are our:Assumptions?Constraints?Shared terms and jargon?
  • 225. Data GatheringHow do we learn about our targetaudience?
  • 226. Interaction ModelDefine requirements:What interactions will benefit thedeveloper?What information is required tosupport the interaction?
  • 227. Interaction ModelAs a ___ I want to …
  • 228. Map Interactions to an API DesignWhich style?Which formats?How do we translate interactions?
  • 229. PrototypeDon’t bind to real data or backendUse something lightweight and easyto changeDo this early
  • 230. Practical PrototypingWrite simple code or script in a languagethat is easy for you to implement.var express = require(express),app = express();var port = 8080;app.listen(port);app.get("/tasks", function(req, res) {res.status(200).send(‘<response><tasks><task><name>Pick up Kai</name><priority>1</priority></tasks></response>’);}
  • 231. Practical PrototypingConfigure an interface in a web or APIplatformGET /tasks
  • 232. Practical PrototypingApply minimal securityTry writing throwaway client codeAsk target developers to write code anduse the APIMake quick changes and try it again
  • 233. Focus on the interactions that takeplace, rather than the interfaceswe expose
  • 234. DX > Software Qualities
  • 235. Usability Summary• Focus on the developer• Start by thinking in terms of interactions• Effective for public and private APIs
  • 236. Great API design can thrive in adeveloper-centric environment
  • 237. Building an API Strategy:The Developer ExperienceRonnie MitraPrincipal API Architect - EuropeLayer 7 API Academy
  • 238. Building an API Strategy:Architecture FoundationsRonnie MitraPrincipal API Architect - EuropeLayer 7 API Academy
  • 239. Architecture
  • 240. Pattern
  • 241. Representation Layer
  • 242. Component != Connector
  • 243. ComponentDatabaseFile SystemMessage QueueTransaction ManagerSource Code
  • 244. Components Are Private
  • 245. ConnectorWeb ServerBrowser AgentProxy ServerShared Cache
  • 246. Connectors Are Public
  • 247. Client ServerConnectorsComponentsThe Web
  • 248. 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
  • 249. • Data and Interface Transformation• Focus on the interface (usability)RepresentationSOAPLegacy
  • 250. Security Layer
  • 251. Security implementations are difficult:• Mistakes are costly• Hard to understand specifications• Performance can suffer
  • 252. Don’t implement API security in the implementationEnforce security at the edgeWhere?
  • 253. Caching Layer
  • 254. Caching Layer
  • 255. 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.
  • 256. Orchestration Layer
  • 257. • Chaining multiple calls• Aggregating and enriching data• ‘mashup’ external data with internal dataOrchestration:
  • 258. Gateway Pattern Abstraction of multiple interfaces In Software Engineering: Façade Pattern Benefits:- Deliver a consistent experience- Centralize API functionality
  • 259. API GatewayGatewayAPIAPI
  • 260. Restrict AccessImprove PerformanceFocus on Usability
  • 261. The gateway doesn’t solve all our problems
  • 262. API portalsPortal
  • 263. API ManagementPortalGatewayAPIAPI
  • 264. Nuts and Bolts of API Management Developer Registration Access Control API Explorer API Documentation Social Engagement Tracking and Reporting
  • 265. We also apply this philosophy behind the firewall.
  • 266. Architecture Summary• Use a layered architecture• Deploy a gateway for runtime• Deploy a portal for developers
  • 267. Building an API Strategy:Architecture FoundationsRonnie MitraPrincipal API Architect - EuropeLayer 7 API Academy
  • 268. Building an API Strategy:The Security ChallengeRonnie MitraPrincipal API Architect - EuropeLayer 7 API Academy
  • 269. The API security challenge:BalancingControl and Accessibility
  • 270. IdentityAuthenticationAuthorizationAvailabilityIntegrityPrivacy
  • 271. Attack Surfaces and Identities
  • 272. PortalAPIDeveloperEnd UserAdministrator
  • 273. PortalAPIDeveloperEnd UserAdministrator
  • 274. APIEnd User
  • 275. Injection AttacksUtilizing input parameters to inject data that compromisesthe security of the targeted system. Examples:- SQL Injection- Command Injection- Code Injection- Argument Injection
  • 276. API Attack Example:SQL Injection Attacks: APIsGET‘ or ‘1=1select * from tokens where token = ‘’ or ‘1=1’;
  • 277. APIs May Be A Direct Conduit292HTTPServerAppServerDatabaseAppObjectsOften:• Self-documenting• Closely mapped to object space
  • 278. Denial Of Service AttacksAn attack which has the objective of making a serviceunavailable to all usersExamples:- XML/JSON parser attacks- Jumbo messages- Server overload
  • 279. Overflow AttackIntentionally sending too much data in order to exploit atarget systems by exceeding expected boundaries.Examples: Buffer Overflow Cash Overflow
  • 280. Cross Site Scripting (XSS) AttackEmbedding code within a server that will betransmitted to users.
  • 281. XSS API Example296AttackerWeb App Server(browser+APIs)Victim: WebBrowserClient<SCRIPT …>1. API injectsscript in3. Browser loadscontent withembedded script2. Server fails toperform FIEO: FilterInput, Escape OutputAPI
  • 282. Interception of communication between two systems.Man in the Middle Attack
  • 283. OWASP Top Ten (2010 Edition)Source:
  • 284.  Impersonating a registered application in order to accessan API resource. Examples:- Guessing application ID by brute force- Retrieving application ID by sniffing traffic- Cracking application to retrieve application IDApp Spoofing
  • 285. how can I protect identity on a mobile device?
  • 286.
  • 287. what happens if my mobile app is impersonated?
  • 288. APIEnd User
  • 289. Revenue Source
  • 290. What the Fudge*! Ididn’t make 10000calls yesterday!!!!!!I’m not paying that.*This is what WTF actually stands for.
  • 291. I didn’t buy 1000mobile phones inRussia!I’m not paying that!
  • 292. Forrester:we are moving towards a ‘zero-trust’ model
  • 293. New platforms, new languages:• Ruby on Rails• Node.js• Scala• Nginx• Squid/Varnish/Traffic Manager
  • 294. TLSOAuth 2Open ID Connect
  • 295. OAuth provides aDelegated Authorization Framework
  • 296. An imperfect analogy….
  • 297.
  • 298.
  • 299. MoneyThis Shop Needs Your MoneyYou need to grant accessto your money
  • 300. won’t tell.I promise!
  • 301.
  • 302. Granting access to someone to acton your behalf.
  • 303. Your resourcesThis app needs to act on your behalfYou need to grant accessto your resources
  • 304. Your google+ dataThis app needs to access yourGoogle+ dataYou need to grant accessto your resources
  • 305. Hi Google.I’d like to have access to a user’sdata.
  • 306. Hang on, let meask…
  • 307. He said yes. Here is youraccess code.
  • 308. “Client” == application“Resource owner” == end-userThe first step to understanding OAuth 2:
  • 309. OAuth 2 Grant Types- Authorization Code- Implicit- Resource Owner Password Credentials- Client Credentials
  • 310. Authorization Code Grant326Client ApplicationResource OwnerUsingApplicationResource ServerI Wish I could accessmy resources throughthis application…
  • 311. Authorization Code Grant327Client ApplicationResource OwnerUsingApplicationResource Server…but I don’t trust thisapp enough to give itmy credentials.
  • 312. Authorization Code GrantInitiation328Client ApplicationResource Owner Authorization ServerResource ServerUser AgentIssue GETrequest viaUser-Agent
  • 313. Authorization Code GrantInitiation329Client ApplicationResource Owner Authorization ServerResource ServerUser AgentIssue GETrequest viaUser-Agentresponse_typeclient_idredirect_uriscopestate
  • 314. OAuth 2 Authorization Request response_type – indicates grant type client_id –application identifier redirect_uri (optional) – address which the UA can use to respond to client scope (optional) – space delimitted string: what the client wants to do state (optional)– opaque string used to defeat CSRF attacks Sample Authorization GET URL:https://azserver/oauth2/authorize?response_type=code&client_id=my_id&state=state&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fcallback
  • 315. Authorization Code GrantResource Owner Authentication331Client ApplicationResource Owner Authorization ServerResource ServerUser AgentSendUserAuthenticationForm?Authenticate
  • 316. Authorization Code GrantAuthorization332Client ApplicationResource Owner Authorization ServerResource ServerUser AgentDeliverGrantScreen???ApproveGrantRequest
  • 317. Authorization Code GrantReceipt of Authorization Code333Client ApplicationResource Owner Authorization ServerResource ServerUser AgentRedirectUser-AgentClientApplication! RedirectedToClientApplicationcodestate302
  • 318. Authorization Code GrantAccess Token Request334Client ApplicationResource Owner Authorization ServerResource ServerRequestAccessTokenReturnAccessTokenand OptionalRefresh Tokengrant_typecoderedirect_uriclient_id200AZ CodeAZ Code
  • 319. Authorization Code GrantAccess Protected Resource335Client ApplicationResource Owner Authorization ServerResource ServerRequestResourceUsingApplicationReturnResource200
  • 320. Authorization Code Grant - Summary Most Complex of OAuth 2 Grant Types Provides full OAuth 2 capability
  • 321. 2 vs. 3 Legged Spectrum337ThreeleggedTwolegged
  • 322. OAuth 2 ChallengesIt is a framework
  • 323. 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
  • 324. 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
  • 325. 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
  • 326.  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
  • 327. Portal
  • 328. Who is using the API?How are they (mis)using it?
  • 329. What would happen if the portal was exploited?
  • 330. PortalAPIDeveloperEnd UserAPI
  • 331. PortalAPIAdministrator
  • 332. Where are the components deployed?Who owns the identity store?
  • 333. PortalAPI
  • 334. Summary:Challenge: Balancing Usability and SecurityOld Threats Still ExistNew Styles and Access Models create new surfaces
  • 335. Building an API Strategy:The Security ChallengeRonnie MitraPrincipal API Architect - EuropeLayer 7 API Academy