The document outlines key considerations for developing an effective API strategy, emphasizing the importance of understanding business drivers such as innovation, consumer reach, and revenue sources. It discusses different API styles, the significance of the developer experience in API design, and strategies for improving usability and adoption. Ultimately, successful API development requires a developer-centric approach, iterative design, and attention to interaction models.

1. Considerations for an API Strategy
Ronnie Mitra
Principal API Architect - Europe
Layer 7 API Academy

2. Business Drivers
The Developer Experience
API Architecture
Agenda

4. Private or Closed APIs

5. Acme Corp.
API
Acme Corp.
App

7. Public or Open APIs

8. Acme Corp.
API
Third Party
App

10. Priority:
Lower Cost
Priority:
Increased Adoption

11. why build an API?

12. Innovation
Consumer Reach
Revenue Source
Marketing
Integration
Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project

13. Innovation
Consumer Reach
Revenue Source
Marketing
Integration
Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project

14. Revenue Source

15. Revenue Source
http://www.flickr.com/photos/inside-south-africa/485356704
£0.10 per API Call

16. Revenue Source
1000 calls/month
5000 calls/month

17. Revenue Source
500 calls/month
1000 calls/month
5000 calls/month

18. Revenue Source
Is your content worth paying for?

19. Innovation
Consumer Reach
Revenue Source
Marketing
Integration
Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project

20. Consumer Reach

21. Consumer Reach

22. Platforms are not forever!

23. Innovation
Consumer Reach
Revenue Source
Marketing
Integration
Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project

24. Marketing
Affiliate Programs
Sometimes you pay the developer.

25. Marketing
Draw new visitors in.

26. Marketing

27. Marketing
Stay above the noise:
New channels
Information-centric marketing

28. Innovation
Consumer Reach
Revenue Source
Marketing
Integration
Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project

29. Innovation
Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project
Innovation from within

30. Innovation
Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project
Innovation outside your borders

31. Innovation
Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project
When does innovation happen?

32. Innovation
Consumer Reach
Revenue Source
Marketing
Integration
Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project

33. Integration
Business driven integration
Regulatory driven integration

34. Observational Learning:
Five Famous Stories of Public APIs

35. 2000 – ebay

36. Started with a paid developer program in 2000
Made it free in 2005

37. Consumer Reach
Marketing

38. Large developer eco-system
Large app eco-system

39. 25% of eBay listings come from their API!

40. salesforce
2000 – salesforce

41. Integration
Revenue Source

42. API as a cloud enabler

43. 2004 – Flickr

44. web 2.0 generation
the social evolution

45. Consumer Reach
Marketing

46. The rise of self-service
Announced 6 billion photos in August 2011

47. 2006 – Amazon Web Services

48. Started as an online book shop…
Became a department store…
now?

49. Jeff Bezos
Connect everything
http://www.flickr.com/photos/zippy/2430495092

50. 2004:
Hey, why don’t we sell this?

51. Revenue Source

52. Estimated revenue:
$1.5B in 2012
http://wikibon.org/wiki/v/Cloud_Computing_2013%3A_The_Amazon_Gorilla_Invades_the_Enterprise

53. Twilio or stripe
2007 - Twillio

54. Revenue Source

55. The API is the business

56. 100,000 developer milestone in 2012

57. Original APIs are still successful
New business models have emerged
Know your drivers – design accordingly
Summary

58. API Styles

59. What does a Web API look like?

60. Web APIs
HTTP

61. Network Based APIs
HTTP
COAP MQTT
WebSocket?

63. Architectural Styles

64. Tunnel Style
URI Style
Hypermedia Style
Event Driven Style

65. Tunnel Style
Example: SOAP
• transport agnostic
• operation based
• binding documents (WSDL)

66. Tunnel Style
<RetrieveStudentRecords>
<StudentId>1213</StudentId>
</RetrieveStudentRecords>

67. Tunnel Style
• lots of tooling
• not restricted to HTTP
• RPC
Advantages

68. Tunnel Style
• inefficient for HTTP
• increased learning curve
• lack of tooling in mobile
Trade-offs

69. URI Style
GET
PUT
POST
DELETE
+ URI

70. URI Style
GET /students/1232

71. URI Style
• familiar to web developers
• designed for HTTP
• URIs are intuitive
Advantages

72. URI Style
• limited to four methods
• URI design is not standard
• can be ‘chatty’
Trade-offs

73. Hypermedia Style

74. Hypermedia Style
• links
• templated input (forms)
• task based

75. {
links: [
link {href: ‘…’ rel: ‘list’},
link {href: ‘…’ rel: ‘add’}
]
collection: [
{link: {rel:'complete',href:‘…'},
id:42,
text:‘Record 42'
}
]
}

76. Hypermedia Style
• designed for HTTP
• long lasting
• no URI construction
Advantages

77. Hypermedia Style
• leading-edge
• requires ‘smarter’ apps
• less familiar to developers
Trade-offs

78. Event Driven Style
Example: WebSockets
• event based communication
• server initiated events
• full-duplex (websocket)

79. Event Driven Style
• less overhead
• better performance
Advantages

80. Event Driven Style
• not HTTP-based
• resource intensive connections
• inefficient for request-reply
Trade-offs

81. API Styles Summary
• Web API != standard
• Four popular styles: Tunnel, URI,
Hypermedia, Event
• Choose a style that fits your constraints
and business goals

82. The Developer Experience

83. designing APIs can be difficult

84. http://www.flickr.com/photos/nirufe/3469696707
?

85. Usability
Reliability
Simplicity
Security
Etc…
Software Qualities

86. Focus on the developer experience
(dx)

87. Interaction Design
Bill Moggridge

88. Usability
Human-Computer-Interaction
User Experience Design
Goal Oriented Design

89. http://www.flickr.com/photos/58754750@N08/5541472392/

90. A user-centric view of design.

91. Well designed products are easier
to use.

92. Good design matters for Web APIs
too.

93. Priority:
Lower Cost
Priority:
Increased Adoption

94. Portal
API

95. Portal
API
Developer
End User
Administrator

96. Portal
API

97. This is obvious right?

98. Why is this difficult to do in
practice?

99. Reason #1
We project our own perspective.

102. Reason #2
We project our own biases.

103. Never use SOAP?
Why?

104. Consider keyboards…

105. http://www.flickr.com/photos/yvettemn/139890573/

106. http://www.flickr.com/photos/jonathanpberger/7126054997/

107. http://www.flickr.com/photos/novemberborn/286773981/

108. OR

109. It doesn’t matter that you don’t like
SOAP.

110. What matters is what your developer
base thinks!
(and what your objective is)

111. Reason #3
We make bad assumptions.

112. API publishers are also developers.

113. “I built a mobile app once.”

114. Reason #4
We lack the time, money or
incentive for good design

115. “Best practices”, patterns and
standards become shortcuts

116. Am I RESTfull enough?

117. So, how can we do better?

118. Developer-centric design requires
effort and diligence.

121. Design with the developer in mind.

122. Ask them.

123. • Interviews
• Surveys
• Listen (blogs, presentations,
tweets)

124. +

125. • Observe
• Prototype
• Historical Data

126. Consider all aspects of the DX:
Registration
Security
Troubleshooting
Learning
Interface Style

127. A Good DX = A Good System

128. Tunnel Style
URI Style
Hypermedia Style
Event Driven Style

130. Registration
Lazy Registration
Social Integration
Personalization

131. Development Activity Cycle
1. Learn
2. Code
3. Implement
4. Test
5. Fix

132. Portal
API
Learn
Code
Test

133. API
Learn
Test

134. API explorers and “live
documentation” can shorten the
gap between visibility and
feedback.

135. Troubleshooting and Feedback
Provide useful information at runtime
Provide useful post-run information

136. TLS
OAuth 2
Open ID Connect

137. Security
Security can hurt Usability
But… security can also improve the
overall experience!
We need to think about the system as a
whole

138. Complexity
• Sometimes complexity is necessary –
that is ok
• Enough features to meet
requirements
• Don’t hurt the DX – use structure
and modularity

141. Structure and Consistency
Define a consistent Message Structure
{ “Response” : {
“Errors” : {}
}}

142. Structure and Consistency
Define consistent standards for:
• Naming
• Collection structure
• Content negotiation
• Links

143. Modularity
Partition APIs into modules or
products
From a DEVELOPER perspective!

144. “Frictionless” integration
High rates of adoption
Low cost integration
We want:

145. Behaviour Design
BJ Fogg

146. Visitor Invested Developer

147. Visitor Invested Developer
Joy Joy Joy

148. A Sample DX Based Design Process

149. 1. Identify the problem space
2. Learn about the audience
3. Design Interactions
4. Make API design choices that
are developer-centric
5. Prototype and get feedback
6. Iterate

150. The Problem Space
Why are we doing this?
Who are we building it for?

151. Innovation
Consumer Reach
Revenue Source
Marketing
Integration
Light Bulb designed by Jean-Philippe Cabaroc from The Noun Project

152. Consider:
Platforms
Organizations
Languages
Who is this for?

153. The Problem Space
What are our:
Assumptions?
Constraints?
Shared terms and jargon?

154. Data Gathering
How do we learn about our target
audience?

155. Interaction Model
Define requirements:
What interactions will benefit the
developer?
What information is required to
support the interaction?

156. Interaction Model
As a ___ I want to …

157. Map Interactions to an API Design
Which style?
Which formats?
How do we translate interactions?

158. Prototype
Don’t bind to real data or backend
Use something lightweight and easy
to change
Do this early

159. Focus on the interactions that take
place, rather than the interfaces
we expose

160. DX > Software Qualities

161. Great API design can thrive in a
developer-centric environment

162. Usability Summary
• Focus on the developer
• Start by thinking in terms of interactions
• Effective for public and private APIs

163. www.apiacademy.co

164. Considerations for an API Strategy
Ronnie Mitra
Principal API Architect - Europe
Layer 7 API Academy