Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Be My API How to Implement an API Strategy Everyone will Love

1,857 views

Published on

Mike Amundsen,
Principal API Architect, Layer 7 Technologies
Mike is the author of Building Hypermedia APIs with HTML5 & Node and is a regular speaker at leading industry events on the subject of API design, Web application development and cloud computing.

Learn how to create and publish APIs that will help your business thrive and grow

February 7, 2013
9am PST | 12pm EST

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 organization but it must also be flexible enough to meet your developer community’s diverse needs. This webinar with Mike Amundsen, Layer 7's Principal API Architect, will examine the key foundational elements necessary for a solid API implementation strategy.

You Will Learn
Align API design with business goals
Architect flexible and robust APIs that are developer-accessible
Design for multiple client platforms (Web, mobile and cloud)
Implement USE methodology, versioning, reusability and hypermedia
Address issues around security, identity, social integration, reliability and scalability
Presented By

  • Be the first to comment

Be My API How to Implement an API Strategy Everyone will Love

  1. 1. Be My API <3How to implement an API strategy everyone will love. Mike Amundsen Principal API Architect Layer 7 Technologies @mamund 1
  2. 2. PRELIMINARIES 2
  3. 3. Mike Amundsen Author, Web Architect, Presenter Principal API Architect Hypermedia Junkie Building Hypermedia APIs with HTML5 and Node RESTful Web APIs (w/ Leonard Richardson) 3
  4. 4. API Academy Mike Amundsen Ronnie Mitra Alex Gaber 4
  5. 5. API Academy http://forms.layer7tech.com/FW-API13 5
  6. 6. API Academy 6
  7. 7. API Academy Web Site (URI shortly) 7
  8. 8. Housekeeping Questions - Post questions to Q&A, we’ll cover them at breaks throughout the sessions Twitter facebook.com/layer7 - Today’s event hashtag: layer7.com/linkedin - #L7webinar layer7.com/blogs - Follow us on Twitter: - @layer7 - @mamund (Mike Amundsen) - @intalex (Alex Gaber) - @mitraman (Ronnie Mitra) 8
  9. 9. Outline The Business of APIs The USE methodology (Usable, Scalable, Evolvable) Implementing a Solid Foundation API Interaction Models 9
  10. 10. THE BUSINESS OF APIS 10
  11. 11. The Business of APIs API Consumers Acquisition Targets Product Models 11
  12. 12. API Consumer: Private Internal/contract developers Implementation control Your product is understood Your control is the code/deployment Agenda alignment Private APIs offer the ability to strengthen your market 12
  13. 13. API Consumer: Partner Strategic Partners Limited implementation control Your product is your SDK Your control is access internal content, users, etc. Agenda Co-operation Partner APIs offer opportunities to extend your market 13
  14. 14. API Consumer: Public “Third-party” developers Little to no implementation control Your product is your API Your control is the API Agenda wide open Public APIs offer a chance to discover new markets 14
  15. 15. API Consumer Private APIs to strengthen your market Partner APIs to extend your market Public APIs to discover new markets 15
  16. 16. Acquisition: Reach Increase install base Enter new markets Raise awareness/presence Leverage existing products 16
  17. 17. Acquisition: Content Increase contributed user content Gather behavioral data Make new content connections Build upon existing infrastructure 17
  18. 18. Acquisition: Users Expand user base Increase user traffic Increase user data Deepen customer relationships 18
  19. 19. Acquisition Leverage existing products Build upon existing infrastructure Deepen customer relationships 19
  20. 20. Product: Monitor Know your product What APIs are used? Who is using them? When they are using them? You are your best source of “big data” 20
  21. 21. Product: Measure What are your metrics? API performance - Latency - Uptime - Reliability Dev performance - “Installs” - Traffic - Stability You can’t improve what you don’t measure 21
  22. 22. Product: Modify Small changes can mean big results Use your APIs to test new ideas, new products “CI” means constant improvement Turn feedback into features 22
  23. 23. Product You are your best source of “big data” You can’t improve what you don’t measure Turn feedback into features 23
  24. 24. The Business of APIs API Consumers - Private, Partner, Public Acquisition Target - Reach, Content, Users Product Modeling - Monitor, Measure, Modify 24
  25. 25. USABLE, SCALABLE,EVOLVABLE (USE) 25
  26. 26. Usable “Usability is the ease of use and learnability of a human-made object.” 26
  27. 27. Usable “Usability is the ease of use and learnability of a human-made object.” In API, the “I” stands for “Interface” How usable is your interface? Design for Usability - Early focus on users and tasks - Empirical measurement - Iterative design Be prepared to measure and iterate 27
  28. 28. Scalable “Scalability is the ability of a system, network, or process, to handle a growing amount of work in a capable manner …” 28
  29. 29. Scalable “Scalability is the ability of a system, network, or process, to handle a growing amount of work in a capable manner …” Scaling out vs. scaling up Scaling up (more memory, etc.) is “easier” and more limiting Scaling out (more machines) is “harder” and more reliable over time Design-in support for the “Layered Constraint” (Fielding’s REST) Take advantage of “DevOps” practices to support scaling Be prepared to scale out 29
  30. 30. Evolvable “Evolvability is defined as the capacity of a system for adaptive evolution.” 30
  31. 31. Evolvable “Evolvability is defined as the capacity of a system for adaptive evolution.” Extend (pandere or “to stretch”) - Existing elements cannot be removed - Meaning/processing of existing elements cannot be changed - New elements must be optional Versioning (vertere or “to turn”) - Make it easy to identfy the “version” - Implementations should reject unsupported versions Don’t version unless it is unavoidable Be prepared for clients to ignore version details Do not create “Dodo” apps. 31
  32. 32. Review Usable - Your API is your Interface - Focus on users & tasks, measure, iterate Scable - Scaling out is the key - Take advantage of DevOps practices Evolvable - Don’t create Dodo apps - Favor extending over versioning whenever possible 32
  33. 33. IMPLEMENT A SOLIDFOUNDATION 33
  34. 34. Component != Connector 34
  35. 35. Component Database File System Message Queue Transaction Manager Source Code 35
  36. 36. Component == Private 36
  37. 37. 37
  38. 38. Connector Web Server Browser Agent Proxy Server Shared Cache 38
  39. 39. Connector == Public 39
  40. 40. 40
  41. 41. Client Server Connectors The Web Components 41
  42. 42. Representation Layer 42
  43. 43. 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 43
  44. 44. Caching Layer 44
  45. 45. 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, etc. 45
  46. 46. Security Layer 46
  47. 47. Security Layer Security happens at the edges HTTP supports authentication negotiation - WWW-Authenticate - Authorization - Proxy versions, too Keep Authentication out of your components Perform Authorization as early as possible Various security/routing proxies available 47
  48. 48. Review Components != Connectors - Components are private (DB Server) - Connectors are public (HTTP) Representation Layer - You only send representations - Be prepared to support multiple representation formats Caching Layer - Caching happens everywhere - Support caching at client and server (proxies) Security Layer - Security happens at the edges - Use security proxies for better compliance/performance 48
  49. 49. THE API INTERACTION MODEL 49
  50. 50. Interaction Model as a Implementation Strategy Lots of things to decide when creating an implementation How do we make good choices? What is our “basis” for decisions? 50
  51. 51. Lots of Choices SOAP, CRUD, REST XML, JSON, HTML Caching Security Error Formats, etc. 51
  52. 52. Focus on Interactions, not technologies Great APIs are based on interactions Great design starts with the user perspective Focus on how the API will be used, not what it exposes Let’s apply UX (user experience) concepts to DX (developer experience) 52
  53. 53. Three Questions Who will use this API? What will it be used to create? How will the API actually behave? 53
  54. 54. API Interaction Actors Developer Application End User 54
  55. 55. API Usage Scenarios Focus on Activities, not Objects How will this API help the developer? Narrow the interface to those things you want to encourage. 55
  56. 56. Interface Behavior Build a model of tasks Identify data points needed to complete the tasks Map out interaction details for each task (or set of tasks) 56
  57. 57. Some Tips Be sure to include error-handling interactions - Is this Fixable? - Repeatable? - Safe/Unsafe? Keep it “abstract” - Don’t get tied up w/ technology (formats, libraries, frameworks, etc.) - Describe your model independent of protocol (HTTP, webSockets, etc.) - Maintain your DX perspective at all times. 57
  58. 58. Review Focus on interactions, not technologies Maintain the developer perspective Tasks -> Data -> Models Keep it “abstract” 58
  59. 59. SUMMARY 59
  60. 60. The Business of APIs API Consumers - Private, Partner, Public Acquisition Target - Reach, Content, Users Product Modeling - Monitor, Measure, Modify 60
  61. 61. Usable, Scalable, Evolvable (USE) Usable - Your API is your Interface - Focus on users & tasks, measure, iterate Scable - Scaling out is the key - Take advantage of DevOps practices Evolvable - Don’t create Dodo apps - Favor extending over versioning whenever possible 61
  62. 62. Implement a Solid Foundation Components != Connectors - Components are private (DB Server) - Connectors are public (HTTP) Representation Layer - You only send representations - Be prepared to support multiple representation formats Caching Layer - Caching happens everywhere - Support caching at client and server (proxies) Security Layer - Security happens at the edges - Use security proxies for better compliance/performance 62
  63. 63. API Interaction Models Focus on interactions, not technologies Maintain the developer perspective Tasks -> Data -> Models Keep it “abstract” 63
  64. 64. In Conclusion The Business of APIs The USE methodology (Usable, Scalable, Evolvable) Implementing a Solid Foundation API Interaction Models 64
  65. 65. Thank you Twitter - Today’s event hashtag: facebook.com/layer7 - #L7webinar layer7.com/linkedin - Follow us on Twitter: layer7.com/blogs - @layer7 - @mamund (Mike Amundsen) - @intalex (Alex Gaber) - @mitraman (Ronnie Mitra) 65
  66. 66. Be My API <3How to implement an API strategy everyone will love. Mike Amundsen Principal API Architect Layer 7 Technologies @mamund 66

×