We’ve all heard about ‘API First’ when it comes to building a new product or feature. It can allow your team to develop in parallel, enable expansion to multiple platforms, and create an opportunity for outside integration.

But creating a usable and maintainable API doesn’t start with opening your IDE. If you want to build an API that will meet the long term needs of your users (both internal and external), you start by designing the interface they’ll consume, not writing the code that powers that interface.

In this session, we’ll consider the benefits of a design-first approach, how that contrasts some of our natural instincts as web developers, and how design-first works even when you don’t do ‘API first’.

Comments

Comments are closed.

Yannick Voyer at 10:59 on 21 May 2019

Great talk, I would have liked to see some documentation or code example to show what errors might look like. other than that, good job

Very practical, good talk for various skill and experience levels

John Congdon at 08:44 on 22 May 2019

Great presentation, and Lorna's insistence on not sending a 200 OK with an error message came through loud and clear.

The simple concept of build what the client wants (through design first) is an often overlooked point. We often get light feedback from clients and then we build what we think they want (jump in and code, I can refactor later). But that often takes way more time.