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.
API	
  Thinking	
  
James	
  Higginbotham	
  
API	
  Architect	
  
@launchany	
  
“I	
  say	
  this	
  constantly:	
  ‘your	
  API	
  
design	
  should	
  become	
  the	
  
defini:on	
  of	
  your	
  new	
...
I	
  ask:	
  	
  
“What	
  are	
  your	
  resources?”	
  
Their	
  answer:	
  	
  
“How	
  do	
  I	
  figure	
  out	
  what	
  
resources	
  I	
  need?”	
  
“We	
  have	
  a	
  monolithic	
  app,	
  but	
  
we	
  are	
  in	
  the	
  process	
  of	
  
redesigning	
  it.”	
  
Microservice	
  everything!	
  
Containerize	
  it	
  all!	
  
Maybe.	
  Maybe	
  not.	
  
First,	
  we	
  need	
  to	
  be	
  able	
  to	
  look	
  
at	
  our	
  soPware	
  systems	
  in	
  a	
  
“fresh,	
  old	
...
Domain	
  Modeling	
  to	
  find	
  
business	
  en::es,	
  rela:ons,	
  
state	
  transi:ons,	
  and	
  events	
  
(Domain...
Systems:	
  Solu:on	
  to	
  Problem(s)	
  
Subsystems:	
  Bounded	
  Concerns	
  
Modules:	
  Atoms	
  for	
  Composi:on	...
Automo:ve	
  Systems	
  
u  Engine	
  
– Intake	
  
– Exhaust	
  
– Fuel	
  System	
  
– Valve	
  Train	
  
u  Drive	
  ...
Third-­‐party	
  APIs	
  may	
  replace	
  
modules,	
  subsystems,	
  or	
  even	
  
en:re	
  systems	
  
Once	
  we	
  understand	
  our	
  logical	
  
architecture,	
  we	
  can	
  determine	
  
the	
  op:on(s)	
  to	
  realiz...
Our	
  API	
  resources	
  and	
  product	
  
boundaries	
  become	
  more	
  apparent	
  
as	
  well,	
  including	
  whe...
Systems	
  =	
  Solu:ons	
  
Subsystems	
  =	
  Resources/Groups	
  
Modules	
  =	
  Endpoints	
  
What	
  might	
  this	
  look	
  like?	
  
Subsystems:	
  Account	
  Management,	
  
Inventory	
  Management,	
  Customer	
  
Management,	
  Ecommerce,	
  Billing,	
...
Each	
  subsystem	
  has	
  an	
  API	
  that	
  
exposes	
  one	
  or	
  more	
  endpoints.	
  	
  
We	
  can	
  then	
  select	
  the	
  right	
  
architectural	
  styles	
  we	
  need	
  to	
  
realize	
  our	
  subsyste...
-­‐	
  Client/Server	
  
-­‐	
  Service-­‐oriented	
  
-­‐	
  Message-­‐oriented	
  
-­‐	
  Event-­‐driven	
  
-­‐	
  Pipe...
“If	
  the	
  ranks	
  of	
  programmers	
  has	
  
doubled	
  every	
  five	
  years,	
  then	
  it	
  
stands	
  to	
  re...
I’m	
  on	
  a	
  mission	
  to	
  help	
  teams	
  
re-­‐think	
  the	
  way	
  they	
  architect	
  
their	
  soPware,	
...
James	
  Higginbotham	
  
james@launchany.com	
  
hDp://launchany.com	
  	
  
@launchany	
  
	
  
Upcoming SlideShare
Loading in …5
×

API Thinking - How to Design APIs Through Systems Design

2,128 views

Published on

A 5 min discussion about how to improve API design by focusing on domain modeling (to identify entities, relationships, transitions, and events) and systems design (to find the context boundaries for our APIs).

Published in: Software
  • Be the first to comment

  • Be the first to like this

API Thinking - How to Design APIs Through Systems Design

  1. 1. API  Thinking   James  Higginbotham   API  Architect   @launchany  
  2. 2. “I  say  this  constantly:  ‘your  API   design  should  become  the   defini:on  of  your  new  target   architecture’  “  -­‐  @jharmn  
  3. 3. I  ask:     “What  are  your  resources?”  
  4. 4. Their  answer:     “How  do  I  figure  out  what   resources  I  need?”  
  5. 5. “We  have  a  monolithic  app,  but   we  are  in  the  process  of   redesigning  it.”  
  6. 6. Microservice  everything!   Containerize  it  all!  
  7. 7. Maybe.  Maybe  not.  
  8. 8. First,  we  need  to  be  able  to  look   at  our  soPware  systems  in  a   “fresh,  old  way”  
  9. 9. Domain  Modeling  to  find   business  en::es,  rela:ons,   state  transi:ons,  and  events   (Domain-­‐Driven  Design)  
  10. 10. Systems:  Solu:on  to  Problem(s)   Subsystems:  Bounded  Concerns   Modules:  Atoms  for  Composi:on  
  11. 11. Automo:ve  Systems   u  Engine   – Intake   – Exhaust   – Fuel  System   – Valve  Train   u  Drive  Train   u  Braking  System   u  …  
  12. 12. Third-­‐party  APIs  may  replace   modules,  subsystems,  or  even   en:re  systems  
  13. 13. Once  we  understand  our  logical   architecture,  we  can  determine   the  op:on(s)  to  realize  it.    
  14. 14. Our  API  resources  and  product   boundaries  become  more  apparent   as  well,  including  where  client   responsibility  starts  and  stops.  
  15. 15. Systems  =  Solu:ons   Subsystems  =  Resources/Groups   Modules  =  Endpoints  
  16. 16. What  might  this  look  like?  
  17. 17. Subsystems:  Account  Management,   Inventory  Management,  Customer   Management,  Ecommerce,  Billing,   Analy:cs/Repor:ng  
  18. 18. Each  subsystem  has  an  API  that   exposes  one  or  more  endpoints.    
  19. 19. We  can  then  select  the  right   architectural  styles  we  need  to   realize  our  subsystems…  
  20. 20. -­‐  Client/Server   -­‐  Service-­‐oriented   -­‐  Message-­‐oriented   -­‐  Event-­‐driven   -­‐  Pipe  and  Filter   -­‐  Yes,  even  microservices    
  21. 21. “If  the  ranks  of  programmers  has   doubled  every  five  years,  then  it   stands  to  reason  that  most   programmers  were  hired  within  the   last  five  years”  –  Robert  C.  Mar:n   hDp://blog.cleancoder.com/uncle-­‐bob/2014/06/20/MyLawn.html  
  22. 22. I’m  on  a  mission  to  help  teams   re-­‐think  the  way  they  architect   their  soPware,  resul:ng  in   be`er  API  designs  and  products.    
  23. 23. James  Higginbotham   james@launchany.com   hDp://launchany.com     @launchany    

×