The document discusses how to implement an API strategy that is loved by everyone. It covers: 1. The importance of different types of API consumers like private, partner, and public and how APIs can help with acquisition, reach, content, and users. 2. The USE methodology of designing APIs that are usable, scalable, and evolvable. This includes focusing on users, supporting various representations and caching, and avoiding versions when possible. 3. Implementing a solid foundation with separate components and connectors, supporting multiple representations, caching everywhere, and security at the edges. 4. Designing API interaction models by focusing on interactions over technologies, maintaining the developer perspective, and mapping tasks to data and

1. Be My API <3
How 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 SOLID
FOUNDATION
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 <3
How to implement an API strategy everyone will love.
 Mike Amundsen
Principal API Architect
Layer 7 Technologies
@mamund
66