api thinking - how to design apis through systems design
TRANSCRIPT
API Thinking
James Higginbotham API Architect @launchany
“I say this constantly: ‘your API design should become the
defini:on of your new target architecture’ “ -‐ @jharmn
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 way”
Domain Modeling to find business en::es, rela:ons, state transi:ons, and events (Domain-‐Driven Design)
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 Train u Braking System u …
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 realize it.
Our API resources and product boundaries become more apparent
as well, including where client responsibility starts and stops.
Systems = Solu:ons Subsystems = Resources/Groups
Modules = Endpoints
What might this look like?
Subsystems: Account Management, Inventory Management, Customer Management, Ecommerce, Billing,
Analy:cs/Repor:ng
Each subsystem has an API that exposes one or more endpoints.
We can then select the right architectural styles we need to
realize our subsystems…
-‐ Client/Server -‐ Service-‐oriented -‐ Message-‐oriented -‐ Event-‐driven -‐ Pipe and Filter -‐ Yes, even microservices
“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
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.
