# Grokking Modern API Design Interview ## The API Design Interview ### Introduction: The API Design Interview ### What Is an API? ### How API Design Shows Up in Interviews ### What Interviewers Actually Grade ### A Framework for API Design Answers ### Requirements Gathering for an API ### The API as a Product ### Capstone: Design a URL Shortener API ### Chapter Assessment ## Designing a REST API ### What Are REST APIs? ### Introduction: Resource Modeling and REST Core ### Resources, Not Actions ### HTTP Methods and Their Semantics ### URL Design ### Request and Response Shapes ### Field Types That Break Contracts ### Status Codes and Error Design ### Pagination from the Consumer's View ### Filtering, Sorting, and Search ### When REST Doesn't Fit ### Bulk and Batch Operations ### Capstone: Design the Twitter API ### Chapter Assessment ## When REST Is Not Enough ### Introduction: Beyond REST ### gRPC Contract Design ### GraphQL Schema Design ### REST vs gRPC vs GraphQL ### Real Time Delivery: WebSockets, SSE, and Long Polling ### Webhooks: Designing the API That Calls Back ### Async APIs for Long Running Work ### Large Uploads and Downloads ### Capstone: Design a Live Notification API ### Chapter Assessment ## The Hard Parts: Failures, Security, and Change ### Introduction: The Hard Parts ### Idempotency Keys ### Rate Limiting in the Contract ### Authentication and Authorization for APIs ### Designing for Many Tenants ### Versioning and Backward Compatibility ### Concurrency and Conditional Requests ### Read Your Writes ### Caching in the Contract ### The Reliability Contract ### Capstone: Design a Payment API ### Chapter Assessment ## APIs for AI Products ### Introduction: APIs in the AI Era ### Streaming LLM APIs ### Designing APIs for AI Agents ### Usage Metering and Billing APIs ### Rate Limiting Expensive Compute ### Capstone: Design an LLM Inference API ### Chapter Assessment ## More Interview Questions ### Introduction: More Interview Questions ### Interview Question: Design a Chat API ### Interview Question: Design a Booking API ### Interview Question: Design a Feature Flag API ### Interview Question: Design a Checkout API ### Interview Question: Design a Calendar API ### Interview Question: Design a Collaborative Document API ### Chapter Assessment ## The Product Architecture Round ### Introduction: The Product Architecture Round ### From Feature to Data Model ### Designing for One Screen ### Offline, Sync, and Conflict ### Interview Question: Design the API Behind a News Feed Screen ### Interview Question: Design the API Behind a Messaging App ### Chapter Assessment ## Full Answers and Quick Review ### Introduction: Interview Questions and Rapid Review ### The 10 Minute API Answer ### Interview Question: Design a Ride Sharing API ### Interview Question: Design a File Storage API ### Interview Question: Critique This API ### Rapid Fire Questions ### Red Flags and Decision Cheat Sheets ### Chapter Assessment ## Conclusion: What You Now Know, and Where to Go Next ### Concurrency and Conditional Requests Two support agents read the same order. Agent A changes the shipping instruction. Agent B changes the contact phone number. Each client sends a representation based on the copy it read. If B writes last, B's stale copy may restore the old shipping instruction. Both requests return success. One person's work disappears. This is the **lost update problem**. The API needs a way for a writer to say: > "Apply this change only if the resource is still the state I read." HTTP provides that condition through an ETag and `If-Match`.