“A good API doesn’t expose the internal data models or internal logic too much. And the more your clients are not under your control, the less you want to do that."
Today's clip is from Tech Lead Journal episode 125 with Daniel Luebke, a software architect and the co-author of “Patterns for API Design”.
In this clip, we discussed some API design patterns and best practices taken from his book. Daniel shared the importance of understanding domain requirements for building APIs and several API and message best practices. 
Listen out for:

Writing API Design Book - [00:00:26]
Loosely Coupled Message Exchanges - [00:04:29]
API Design Best Practices - [00:07:07]
Message Best Practices - [00:12:24]

_____
Daniel Luebke’s BioDaniel Lübke is an independent coding and consulting software architect with a focus on business process automation and digitization projects. His interests are software architecture, business process design, and system integration, which inherently require APIs to develop solutions. He received his PhD at the Leibniz Universität Hannover, Germany, in 2007 and has worked in many industry projects in different domains since then. Daniel is author and editor of several books, articles, and research papers; gives training; and regularly presents at conferences on topics of APIs and software architecture.
Follow Daniel:

LinkedIn – linkedin.com/in/danielluebke
Twitter – @dluebke
Blog – digital-solution-architecture.com

_____
Our Sponsors
Are you looking for a new cool swag? Tech Lead Journal now offers you some swags that you can purchase online. These swags are printed on-demand based on your preference, and will be delivered safely to you all over the world where shipping is available. Check out all the cool swags available by visiting techleadjournal.dev/shop. And don't forget to brag yourself once you receive any of those swags.

Like this episode?
Show notes & transcript: techleadjournal.dev/episodes/125.
Follow @techleadjournal on LinkedIn, Twitter, and Instagram.
Buy me a coffee or become a patron.