Series Editor Foreword |
|
xxi | |
Foreword |
|
xxv | |
Preface |
|
xxvii | |
Acknowledgments |
|
xxxi | |
About the Author |
|
xxxiii | |
|
Part I Introduction to Web API Design |
|
|
1 | (28) |
|
Chapter 1 The Principles of API Design |
|
|
3 | (12) |
|
The Elements of Web API Design |
|
|
4 | (2) |
|
|
4 | (1) |
|
|
4 | (1) |
|
|
5 | (1) |
|
API Design Is Communication |
|
|
6 | (1) |
|
Reviewing the Principles of Software Design |
|
|
7 | (3) |
|
|
8 | (1) |
|
|
8 | (1) |
|
High Cohesion and Loose Coupling |
|
|
9 | (1) |
|
Resource-Based API Design |
|
|
10 | (1) |
|
Resources Are Not Data Models |
|
|
10 | (1) |
|
Resources Are Not Object or Domain Models |
|
|
11 | (1) |
|
Resource-Based APIs Exchange Messages |
|
|
12 | (1) |
|
The Principles of Web API Design |
|
|
13 | (1) |
|
|
14 | (1) |
|
Chapter 2 Collaborative API Design |
|
|
15 | (14) |
|
Why an API Design Process? |
|
|
15 | (1) |
|
API Design Process Antipatterns |
|
|
16 | (4) |
|
The Leaky Abstraction Antipattern |
|
|
16 | (3) |
|
The Next Release Design Fix Antipattern |
|
|
19 | (1) |
|
The Heroic Design Effort Antipattern |
|
|
19 | (1) |
|
The Unused API Antipattern |
|
|
20 | (1) |
|
The API Design-First Approach |
|
|
20 | (2) |
|
Remaining Agile with API Design-First |
|
|
22 | (1) |
|
The Agile Manifesto Revisited |
|
|
22 | (1) |
|
The Agility of API Design-First |
|
|
23 | (1) |
|
The Align-Define-Design-Refine Process |
|
|
23 | (3) |
|
The Role of DDD in API Design |
|
|
26 | (1) |
|
API Design Involves Everyone |
|
|
26 | (2) |
|
Applying the Process Effectively |
|
|
28 | (1) |
|
|
28 | (1) |
|
Part II Aligning on API Outcomes |
|
|
29 | (38) |
|
Chapter 3 Identify Digital Capabilities |
|
|
31 | (14) |
|
Ensuring Stakeholder Alignment |
|
|
32 | (1) |
|
What Are Digital Capabilities? |
|
|
33 | (1) |
|
Focusing on the Jobs to Be Done |
|
|
34 | (1) |
|
|
35 | (1) |
|
The Components of a Job Story |
|
|
36 | (1) |
|
Writing Job Stories for APIs |
|
|
37 | (1) |
|
Method 1 When the Problem Is Known |
|
|
37 | (1) |
|
Method 2 When the Desired Outcome Is Known |
|
|
37 | (1) |
|
Method 3 When the Digital Capability Has Been Identified |
|
|
38 | (1) |
|
Overcoming Job Story Challenges |
|
|
38 | (2) |
|
Challenge 1 Job Stories Are Too Detailed |
|
|
38 | (1) |
|
Challenge 2 Job Stories Are Feature Centric |
|
|
39 | (1) |
|
Challenge 3 Additional User Context Is Needed |
|
|
40 | (1) |
|
Techniques for Capturing Job Stories |
|
|
40 | (1) |
|
A Real-World API Design Project |
|
|
41 | (1) |
|
|
42 | (1) |
|
|
42 | (3) |
|
Chapter 4 Capture Activities and Steps |
|
|
45 | (22) |
|
Extending Job Stories into Activities and Steps |
|
|
46 | (3) |
|
Identify the Activities for Each Job Story |
|
|
47 | (1) |
|
Decompose Each Activity into Steps |
|
|
47 | (1) |
|
What If Requirements Aren't Clear? |
|
|
48 | (1) |
|
Using EventStorming for Collaborative Understanding |
|
|
49 | (1) |
|
|
50 | (8) |
|
Step 1 Identify Business Domain Events |
|
|
51 | (1) |
|
Step 2 Create an Event Narrative |
|
|
51 | (3) |
|
Step 3 Review the Narrative and Identify Gaps |
|
|
54 | (1) |
|
Step 4 Expand Domain Understanding |
|
|
54 | (2) |
|
Step 5 Review the Final Narrative |
|
|
56 | (2) |
|
The Benefits of EventStorming |
|
|
58 | (2) |
|
|
59 | (1) |
|
Facilitating an EventStorming Session |
|
|
60 | (5) |
|
Prepare: Gathering Necessary Supplies |
|
|
60 | (2) |
|
Share: Communicating the EventStorming Session |
|
|
62 | (1) |
|
Execute: Conducting the EventStorming Session |
|
|
63 | (1) |
|
Wrap-up: Capture Activities and Activity Steps |
|
|
63 | (1) |
|
Follow-up: Post-Session Recommendations |
|
|
63 | (1) |
|
|
64 | (1) |
|
|
65 | (2) |
|
Part III Defining Candidate APIs |
|
|
67 | (32) |
|
Chapter 5 Identifying API Boundaries |
|
|
69 | (10) |
|
Avoiding API Boundary Antipatterns |
|
|
70 | (2) |
|
The Mega All-in-One API Antipattern |
|
|
70 | (1) |
|
The Overloaded API Antipattern |
|
|
70 | (1) |
|
The Helper API Antipattern |
|
|
71 | (1) |
|
Bounded Contexts, Subdomains, and APIs |
|
|
72 | (1) |
|
Finding API Boundaries Using EventStorming |
|
|
73 | (1) |
|
Finding API Boundaries through Activities |
|
|
73 | (2) |
|
|
75 | (3) |
|
|
78 | (1) |
|
|
79 | (20) |
|
|
80 | (1) |
|
The API Profile Structure |
|
|
81 | (1) |
|
|
81 | (12) |
|
Step 1 Capture API Profile Summary |
|
|
83 | (2) |
|
Step 2 Identify the Resources |
|
|
85 | (2) |
|
Step 3 Define the Resource Taxonomy |
|
|
87 | (1) |
|
Step 4 Add Operation Events |
|
|
88 | (3) |
|
Step 5 Expand Operation Details |
|
|
91 | (2) |
|
Validating the API Model with Sequence Diagrams |
|
|
93 | (2) |
|
Evaluating API Priority and Reuse |
|
|
95 | (1) |
|
|
96 | (3) |
|
|
99 | (88) |
|
Chapter 7 REST-Based API Design |
|
|
101 | (36) |
|
What Is a REST-Based API? |
|
|
102 | (10) |
|
|
104 | (1) |
|
|
104 | (1) |
|
|
105 | (1) |
|
REST Supports a Layered System |
|
|
105 | (2) |
|
REST Supports Code on Demand |
|
|
107 | (1) |
|
|
107 | (4) |
|
|
111 | (1) |
|
|
112 | (13) |
|
Step 1 Design Resource URL Paths |
|
|
112 | (3) |
|
Step 2 Map API Operations to HTTP Methods |
|
|
115 | (1) |
|
Step 3 Assign Response Codes |
|
|
116 | (2) |
|
Step 4 Documenting the REST API Design |
|
|
118 | (6) |
|
Step 5 Share and Gather Feedback |
|
|
124 | (1) |
|
Selecting a Representation Format |
|
|
125 | (7) |
|
|
126 | (1) |
|
|
127 | (1) |
|
|
128 | (1) |
|
Semantic Hypermedia Messaging |
|
|
129 | (3) |
|
Common REST Design Patterns |
|
|
132 | (4) |
|
Create-Read-Update-Delete |
|
|
132 | (1) |
|
Extended Resource Lifecycle Support |
|
|
133 | (1) |
|
|
134 | (1) |
|
|
134 | (1) |
|
Long-Running Transaction Support in REST |
|
|
135 | (1) |
|
|
136 | (1) |
|
Chapter 8 RPC and Query-Based API Design |
|
|
137 | (22) |
|
What Is an RPC-Based API? |
|
|
138 | (4) |
|
|
139 | (2) |
|
Factors When Considering RPC |
|
|
141 | (1) |
|
|
142 | (4) |
|
Step 1 Identify RPC Operations |
|
|
142 | (1) |
|
Step 2 Detail RPC Operations |
|
|
142 | (3) |
|
Step 3 Document the API Design |
|
|
145 | (1) |
|
What Is a Query-Based API? |
|
|
146 | (4) |
|
|
147 | (2) |
|
|
149 | (1) |
|
Query-Based API Design Process |
|
|
150 | (7) |
|
Step 1 Designing Resource and Graph Structures |
|
|
151 | (1) |
|
Step 2 Design Query and Mutation Operations |
|
|
151 | (3) |
|
Step 3 Document the API Design |
|
|
154 | (3) |
|
|
157 | (2) |
|
Chapter 9 Async APIs for Eventing and Streaming |
|
|
159 | (28) |
|
The Problem with API Polling |
|
|
160 | (1) |
|
Async APIs Create New Possibilities |
|
|
161 | (1) |
|
A Review of Messaging Fundamentals |
|
|
162 | (9) |
|
Messaging Styles and Locality |
|
|
164 | (1) |
|
The Elements of a Message |
|
|
165 | (1) |
|
Understanding Messaging Brokers |
|
|
166 | (1) |
|
Point-to-Point Message Distribution (Queues) |
|
|
167 | (1) |
|
Fanout Message Distribution (Topics) |
|
|
167 | (1) |
|
Message Streaming Fundamentals |
|
|
168 | (3) |
|
|
171 | (7) |
|
Server Notification Using Webhooks |
|
|
171 | (1) |
|
Server Push Using Server-Sent Events |
|
|
172 | (2) |
|
Bidirectional Notification via WebSocket |
|
|
174 | (2) |
|
|
176 | (1) |
|
Selecting an Async API Style |
|
|
177 | (1) |
|
|
178 | (6) |
|
|
178 | (1) |
|
|
179 | (1) |
|
Event-Carried State Transfer Events |
|
|
180 | (2) |
|
|
182 | (1) |
|
|
183 | (1) |
|
|
184 | (2) |
|
|
186 | (1) |
|
Part V Refining the API Design |
|
|
187 | (116) |
|
Chapter 10 From APIs to Microservices |
|
|
189 | (24) |
|
|
190 | (2) |
|
Microservices Reduce Coordination Costs |
|
|
192 | (1) |
|
The Difference between APIs and Microservices |
|
|
193 | (1) |
|
Weighing the Complexity of Microservices |
|
|
193 | (5) |
|
Self-Service Infrastructure |
|
|
194 | (1) |
|
Independent Release Cycles |
|
|
194 | (1) |
|
Shift to Single-Team Ownership |
|
|
194 | (1) |
|
Organizational Structure and Cultural Impacts |
|
|
195 | (1) |
|
|
195 | (1) |
|
Distributed Data Management and Governance |
|
|
196 | (1) |
|
Distributed Systems Challenges |
|
|
196 | (1) |
|
Resiliency, Failover, and Distributed Transactions |
|
|
197 | (1) |
|
Refactoring and Code Sharing Challenges |
|
|
197 | (1) |
|
Synchronous and Asynchronous Microservices |
|
|
198 | (3) |
|
Microservice Architecture Styles |
|
|
201 | (3) |
|
Direct Service Communication |
|
|
201 | (1) |
|
|
201 | (2) |
|
|
203 | (1) |
|
Right-Sizing Microservices |
|
|
204 | (1) |
|
Decomposing APIs into Microservices |
|
|
204 | (6) |
|
Step 1 Identify Candidate Microservices |
|
|
205 | (1) |
|
Step 2 Add Microservices into API Sequence Diagrams |
|
|
206 | (2) |
|
Step 3 Capture Using the Microservice Design Canvas |
|
|
208 | (1) |
|
Additional Microservice Design Considerations |
|
|
208 | (2) |
|
Considerations When Transitioning to Microservices |
|
|
210 | (1) |
|
|
211 | (2) |
|
Chapter 11 Improving the Developer Experience |
|
|
213 | (12) |
|
Creating a Mock API Implementation |
|
|
214 | (5) |
|
|
215 | (1) |
|
|
216 | (1) |
|
|
217 | (2) |
|
Providing Helper Libraries and SDKs |
|
|
219 | (2) |
|
Options for Offering Helper Libraries |
|
|
220 | (1) |
|
Versioning Helper Libraries |
|
|
220 | (1) |
|
Helper Library Documentation and Testing |
|
|
221 | (1) |
|
|
221 | (3) |
|
|
224 | (1) |
|
Chapter 12 API Testing Strategies |
|
|
225 | (8) |
|
|
226 | (1) |
|
Automated Security Testing |
|
|
226 | (1) |
|
|
227 | (1) |
|
|
227 | (2) |
|
Selecting Tools to Accelerate Testing |
|
|
229 | (1) |
|
The Challenges of API Testing |
|
|
230 | (1) |
|
Make API Testing Essential |
|
|
231 | (1) |
|
|
231 | (2) |
|
Chapter 13 Document the API Design |
|
|
233 | (28) |
|
The Importance of API Documentation |
|
|
234 | (1) |
|
|
234 | (14) |
|
|
235 | (3) |
|
|
238 | (2) |
|
|
240 | (4) |
|
|
244 | (1) |
|
|
245 | (2) |
|
Improving API Discovery Using APIs.json |
|
|
247 | (1) |
|
Extending Docs with Code Examples |
|
|
248 | (3) |
|
Write Getting Started Code Examples First |
|
|
249 | (1) |
|
Expanding Documentation with Workflow Examples |
|
|
249 | (2) |
|
Error Case and Production-Ready Examples |
|
|
251 | (1) |
|
From Reference Docs to a Developer Portal |
|
|
251 | (2) |
|
Increasing API Adoption through Developer Portals |
|
|
251 | (1) |
|
Elements of a Great Developer Portal |
|
|
252 | (1) |
|
Effective API Documentation |
|
|
253 | (3) |
|
Question 1 How Does Your API Solve My Problems? |
|
|
254 | (1) |
|
Question 2 What Problem Does Each API Operation Support? |
|
|
254 | (1) |
|
Question 3 How Do I Get Started Using the API? |
|
|
254 | (1) |
|
The Role of Technical Writer in API Docs |
|
|
255 | (1) |
|
The Minimum Viable Portal |
|
|
256 | (3) |
|
Phase 1 Minimum Viable Portal |
|
|
256 | (1) |
|
|
257 | (1) |
|
Phase 3 Focusing on Growth |
|
|
258 | (1) |
|
Tools and Frameworks for Developer Portals |
|
|
259 | (1) |
|
|
260 | (1) |
|
Chapter 14 Designing for Change |
|
|
261 | (12) |
|
The Impact of Change on Existing APIs |
|
|
261 | (3) |
|
Perform an API Design Gap Analysis |
|
|
262 | (1) |
|
Determine What Is Best for API Consumers |
|
|
262 | (1) |
|
|
263 | (1) |
|
Change Management Is Built on Trust |
|
|
264 | (1) |
|
API Versioning Strategies |
|
|
264 | (4) |
|
Common Nonbreaking Changes |
|
|
265 | (1) |
|
|
265 | (1) |
|
API Versions and Revisions |
|
|
266 | (1) |
|
|
267 | (1) |
|
Business Considerations of API Versioning |
|
|
268 | (1) |
|
|
268 | (2) |
|
Establish a Deprecation Policy |
|
|
269 | (1) |
|
|
269 | (1) |
|
Establishing an API Stability Contract |
|
|
270 | (1) |
|
|
271 | (2) |
|
Chapter 15 Protecting APIs |
|
|
273 | (20) |
|
The Potential for API Mischief |
|
|
273 | (1) |
|
Essential API Protection Practices |
|
|
274 | (2) |
|
Components of API Protection |
|
|
276 | (3) |
|
|
276 | (1) |
|
|
276 | (1) |
|
|
277 | (1) |
|
Web Application Firewalls |
|
|
278 | (1) |
|
Content Delivery Networks |
|
|
278 | (1) |
|
Intelligent API Protection |
|
|
279 | (1) |
|
|
279 | (5) |
|
API Management Hosting Options |
|
|
279 | (3) |
|
API Network Traffic Considerations |
|
|
282 | (1) |
|
Topology 1 API Gateway Direct to API Server |
|
|
283 | (1) |
|
Topology 2 API Gateway Routing to Services |
|
|
283 | (1) |
|
Topology 3 Multiple API Gateway Instances |
|
|
283 | (1) |
|
Identity and Access Management |
|
|
284 | (5) |
|
|
285 | (1) |
|
|
286 | (1) |
|
Pass-by-Reference versus Pass-by-Value API Tokens |
|
|
287 | (1) |
|
OAuth 2.0 and OpenID Connect |
|
|
288 | (1) |
|
Considerations before Building an In-House API Gateway |
|
|
289 | (2) |
|
Reason 1 API Security Is a Moving Target |
|
|
290 | (1) |
|
Reason 2 It Will Take Longer than Expected |
|
|
290 | (1) |
|
Reason 3 Expected Performance Takes Time |
|
|
290 | (1) |
|
What about Helper Libraries? |
|
|
291 | (1) |
|
|
291 | (2) |
|
Chapter 16 Continuing the API Design Journey |
|
|
293 | (10) |
|
Establishing an API Style Guide |
|
|
293 | (4) |
|
Methods for Encouraging Style Guide Adherence |
|
|
294 | (1) |
|
Selecting Style Guide Tone |
|
|
295 | (1) |
|
Tips for Getting Started with an API Style Guide |
|
|
296 | (1) |
|
Supporting Multiple API Styles |
|
|
296 | (1) |
|
Conducting API Design Reviews |
|
|
297 | (3) |
|
Start with a Documentation Review |
|
|
298 | (1) |
|
Check for Standards and Design Consistency |
|
|
299 | (1) |
|
Review Automated Test Coverage |
|
|
299 | (1) |
|
|
299 | (1) |
|
Developing a Culture of Reuse |
|
|
300 | (1) |
|
The Journey Has Only Begun |
|
|
301 | (2) |
Appendix: HTTP Primer |
|
303 | (16) |
Index |
|
319 | |