Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
APIs Are Forever: How to Design Long-Las6ng APIs James Higginbotham API Architect @launchany
Your API tells a story. What story does yours tell?
If your API is the story, you are doing it wrong.
Do we create one API product? More than one product? How can we prevent a redesign?
Architecture is design
Web APIs are an architectural concern that expose an interface to an underlying system. Design them to tell your story...
“We have a monolithic app, but we are in the process of rearchitecDng it using microservices and APIs.” -- anyone whe...
Why do we have “monolithic regret” and how can we avoid it?
Lack of Modulariza6on = Regret VS Func6on-Based Module-Based
(Re)Introducing Systems Design and Domain-Driven Design
Modeling a System System/Solu6on Subsystem Subsystem Module Module Module Module Subsystem Subsystem Module Mod...
The System of LEGO System Sub-systems Modules
“Your API design should become the definiDon of your new target architecture“ - @jharmn
MulD-Sided Marketplace PlaRorm API Example
List Avail Inventory Distributor Add Product to Order Complete Order Cancel Booking Add Product to Inventory Up...
Order Mgmt List Avail Inventory Distributor Add Product to Order Complete Order Cancel Booking Add Product to I...
Each subsystem has an API that exposes one or more endpoints.
Order API List Avail Inventory Distributor Add Product to Order Complete Order Cancel Booking Add Product to In...
IdenDfying the products becomes easier when we have boundaries around the APIs
Order API List Avail Inventory Distributor Add Product to Order Complete Order Cancel Booking Add Product to In...
For every API, ask: “What are your resources?”
Domain-Driven Design
Model domain objects to find business enDDes, relaDons, state transiDons, and events
Order API List Avail Inventory Add Product to Order Complete Order Cancel Booking Add Product to Inventory Upda...
Order API Availabili6es Orders Products (Inventory) Bookings Inventory API Fulfillment API Same data, Conceptuall...
AvailabiliDes - product - date(s) avail - qty avail Orders - bookings - order total Products - name - avail sch...
AvailabiliDes - product - date(s) avail - qty avail availabilityChanged() Orders - bookings - order total ...
PuXng it all together
AvailabiliDes - product - date(s) avail - qty avail availabilityChanged() Orders - bookings - order total ...
Where do microservices fit?
AvailabiliDes Service createAvailability() updateAvailability () deleteAvailability () … availabilityChanged() Ord...
How does your API design reflect your API story?
Thank you! James Higginbotham james@launchany.com @launchany
Upcoming SlideShare
Loading in …5
×

APIs Are Forever - How to Design Long-Lasting APIs

7,781 views

Published on

Teams often struggle with balancing the complexity of legacy applications, limited time, and limited resources when designing APIs. The result is often the release of less-than-ideal API design that meets the immediate needs of the client but misses opportunities for longer-term value. This talk explores systems design and domain-driven design (DDD) for API design thinking and how to apply this technique to your design process to create a clear, well-designed, long-lasting API. Presented at API Strategy and Practice 2015

Published in: Software
no profile picture user

  • Login to see the comments

APIs Are Forever - How to Design Long-Lasting APIs

  1. 1. APIs Are Forever: How to Design Long-Las6ng APIs James Higginbotham API Architect @launchany
  2. 2. Your API tells a story. What story does yours tell?
  3. 3. If your API is the story, you are doing it wrong.
  4. 4. Do we create one API product? More than one product? How can we prevent a redesign?
  5. 5. Architecture is design
  6. 6. Web APIs are an architectural concern that expose an interface to an underlying system. Design them to tell your story.
  7. 7. “We have a monolithic app, but we are in the process of rearchitecDng it using microservices and APIs.” -- anyone where code.age >= 3 months
  8. 8. Why do we have “monolithic regret” and how can we avoid it?
  9. 9. Lack of Modulariza6on = Regret VS Func6on-Based Module-Based
  10. 10. (Re)Introducing Systems Design and Domain-Driven Design
  11. 11. Modeling a System System/Solu6on Subsystem Subsystem Module Module Module Module Subsystem Subsystem Module Module
  12. 12. The System of LEGO System Sub-systems Modules
  13. 13. “Your API design should become the definiDon of your new target architecture“ - @jharmn
  14. 14. MulD-Sided Marketplace PlaRorm API Example
  15. 15. List Avail Inventory Distributor Add Product to Order Complete Order Cancel Booking Add Product to Inventory Update Product Qty Locate Booking Redeem Booking Point Of Sale Remove Product Customer Operator Operator
  16. 16. Order Mgmt List Avail Inventory Distributor Add Product to Order Complete Order Cancel Booking Add Product to Inventory Update Product Qty Locate Booking Redeem Booking Operator Point Of Sale Remove Product Customer Operator Inventory Mgmt Fulfillment
  17. 17. Each subsystem has an API that exposes one or more endpoints.
  18. 18. Order API List Avail Inventory Distributor Add Product to Order Complete Order Cancel Booking Add Product to Inventory Update Product Qty Locate Booking Redeem Booking Point Of Sale Remove Product Customer Operator Inventory API Fulfillment API Operator
  19. 19. IdenDfying the products becomes easier when we have boundaries around the APIs
  20. 20. Order API List Avail Inventory Distributor Add Product to Order Complete Order Cancel Booking Add Product to Inventory Update Product Qty Locate Booking Redeem Booking Operator Remove Product Inventory API Fulfillment API #1 #2 ` Point Of Sale
  21. 21. For every API, ask: “What are your resources?”
  22. 22. Domain-Driven Design
  23. 23. Model domain objects to find business enDDes, relaDons, state transiDons, and events
  24. 24. Order API List Avail Inventory Add Product to Order Complete Order Cancel Booking Add Product to Inventory Update Product Qty Locate Booking Redeem Booking Remove Product Inventory API Fulfillment API
  25. 25. Order API Availabili6es Orders Products (Inventory) Bookings Inventory API Fulfillment API Same data, Conceptually different to the API consumer!
  26. 26. AvailabiliDes - product - date(s) avail - qty avail Orders - bookings - order total Products - name - avail schedule Bookings - product - date(s) - status
  27. 27. AvailabiliDes - product - date(s) avail - qty avail availabilityChanged() Orders - bookings - order total created() updated() Products - name - avail schedule created() removed() updated() Bookings - product - date(s) - status redeemed() cancelled()
  28. 28. PuXng it all together
  29. 29. AvailabiliDes - product - date(s) avail - qty avail availabilityChanged() Orders - bookings - order total created() updated() Products - name - avail schedule created() removed() updated() Bookings - product - date(s) - status redeemed() cancelled() Order API Inventory API Fulfillment API
  30. 30. Where do microservices fit?
  31. 31. AvailabiliDes Service createAvailability() updateAvailability () deleteAvailability () … availabilityChanged() Orders Service createOrder() updateOrder () deleteOrder () … created() updated() Products Service createProduct() updateProduct () deleteProduct () … created() removed() updated() Bookings Service lookupBooking() redeemBooking () cancelBooking () … redeemed() cancelled() Order API Inventory API Fulfillment API Orders HTTP API Inventory HTTP API Fulfillment HTTP API
  32. 32. How does your API design reflect your API story?
  33. 33. Thank you! James Higginbotham james@launchany.com @launchany

×