Finding the path to scaling API success

How big should your HTTP APIs be? Should you add your new resource to an existing API, or should you create them in a new API?

Any company discovering the value of building APIs is going to be faced with these questions at some point. How should you partition your APIs? Should those partitions be exposed to customers, or should you federate those APIs behind a single façade? What does this mean for your API documentation? Your SDKs?

Let me guide you on this journey to discover why some companies are making choices based on past experiences that do not translate well to distributed HTTP APIs. Let me show you how to leverage one of the most underused aspect of HTTP APIs to build developer experiences that can scale to APIs of any size.