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

Please download to get full document.

View again

All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
 4
 
 

Slides

  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
Related documents
Share
Transcript
  • 1. Be My API <3How to implement an API strategy everyone will love. Mike Amundsen Principal API Architect Layer 7 Technologies @mamund 1
  • 2. PRELIMINARIES 2
  • 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. API Academy Mike Amundsen Ronnie Mitra Alex Gaber 4
  • 5. API Academy http://forms.layer7tech.com/FW-API13 5
  • 6. API Academy 6
  • 7. API Academy Web Site (URI shortly) 7
  • 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. Outline The Business of APIs The USE methodology (Usable, Scalable, Evolvable) Implementing a Solid Foundation API Interaction Models 9
  • 10. THE BUSINESS OF APIS 10
  • 11. The Business of APIs API Consumers Acquisition Targets Product Models 11
  • 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. 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. 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. API Consumer Private APIs to strengthen your market Partner APIs to extend your market Public APIs to discover new markets 15
  • 16. Acquisition: Reach Increase install base Enter new markets Raise awareness/presence Leverage existing products 16
  • 17. Acquisition: Content Increase contributed user content Gather behavioral data Make new content connections Build upon existing infrastructure 17
  • 18. Acquisition: Users Expand user base Increase user traffic Increase user data Deepen customer relationships 18
  • 19. Acquisition Leverage existing products Build upon existing infrastructure Deepen customer relationships 19
  • 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. 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. 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. Product You are your best source of “big data” You can’t improve what you don’t measure Turn feedback into features 23
  • 24. The Business of APIs API Consumers - Private, Partner, Public Acquisition Target - Reach, Content, Users Product Modeling - Monitor, Measure, Modify 24
  • 25. USABLE, SCALABLE,EVOLVABLE (USE) 25
  • 26. Usable “Usability is the ease of use and learnability of a human-made object.” 26
  • 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. Scalable “Scalability is the ability of a system, network, or process, to handle a growing amount of work in a capable manner …” 28
  • 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. Evolvable “Evolvability is defined as the capacity of a system for adaptive evolution.” 30
  • 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. 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. IMPLEMENT A SOLIDFOUNDATION 33
  • 34. Component != Connector 34
  • 35. Component Database File System Message Queue Transaction Manager Source Code 35
  • 36. Component == Private 36
  • 37. 37
  • 38. Connector Web Server Browser Agent Proxy Server Shared Cache 38
  • 39. Connector == Public 39
  • 40. 40
  • 41. Client Server Connectors The Web Components 41
  • 42. Representation Layer 42
  • 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. Caching Layer 44
  • 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. Security Layer 46
  • 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. 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. THE API INTERACTION MODEL 49
  • 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. Lots of Choices SOAP, CRUD, REST XML, JSON, HTML Caching Security Error Formats, etc. 51
  • 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. Three Questions Who will use this API? What will it be used to create? How will the API actually behave? 53
  • 54. API Interaction Actors Developer Application End User 54
  • 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. 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. 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. Review Focus on interactions, not technologies Maintain the developer perspective Tasks -> Data -> Models Keep it “abstract” 58
  • 59. SUMMARY 59
  • 60. The Business of APIs API Consumers - Private, Partner, Public Acquisition Target - Reach, Content, Users Product Modeling - Monitor, Measure, Modify 60
  • 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. 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. API Interaction Models Focus on interactions, not technologies Maintain the developer perspective Tasks -> Data -> Models Keep it “abstract” 63
  • 64. In Conclusion The Business of APIs The USE methodology (Usable, Scalable, Evolvable) Implementing a Solid Foundation API Interaction Models 64
  • 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. Be My API <3How to implement an API strategy everyone will love. Mike Amundsen Principal API Architect Layer 7 Technologies @mamund 66
  • Related Search
    We Need Your Support
    Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

    Thanks to everyone for your continued support.

    No, Thanks