“Breaking Bad” on APIs – Lessons Learned – Part 2

Posted on by

Estimated reading time: 2 minutes

Thank you for reading this post, don't forget to subscribe! Happy New Year 2024!

If you haven’t read Part 1 of this series, click here.

APIs

Organizations often decide to build an API without fully considering key success factors or without first engaging their stakeholders. I saw this first hand at a previous employer and it is very painful, not just for the company, but for the consumers of the API, which can have long-lasting repercussions.

In either case, the risk is that the API does not fit the needs of its API consumers. And APIs that don’t fit the needs of consumers have a high cost: limited adoption by developers and ultimately, a failure to meet business objectives. Once the API is designed and built, undoing these mistakes is difficult and time-consuming.

In most cases, you must start over again, redesigning a new API, implementing it by connecting to backend services, then rolling it out again to the developer community. Worst of all, you will have to transition all existing users to the new API. This will require additional work which they may not have the time or willingness to do. At that point, you’ll be faced with a tough choice – continue to support the original API and its users until they eventual (hopefully) migrate, or shut it off and potentially alienate and lose those users.

Another common pitfall of API programs is allowing the design of your API to be dictated by the constraints of internal systems or processes. This is never a good idea, but is particularly perilous when the backend functionality lives in legacy systems whose data schemas are overly complex or whose business logic has been extended over the years using hard-coded workarounds and convoluted logic. Exposing this kind of dirty laundry to your API consumers is a recipe for failure. APIs modeled after internal systems are difficult to understand and use and developers simply won’t invest the time it takes to become productive with them.

What you need is an API that is simple to understand and easy to use. Developers should be able to assess the functionality of your API and start using it in just a few minutes. The only way to deliver that kind of ease of use is to design for it upfront.

Next up, “Tips to building a successful API”

Until next time, Rob