Over the years, I've had to explain and defend the importance and subject around API driven development to business owners and software developers. While most business owners tend not to adhere to this pattern, the truth is that it's inevitable.

Lets look at a few reasons behind the value of this pattern.

• Collaboration and Third Party Services

  While planning to build an application, in most cases we often figure out that we require more than one programming language or library written by someone or an organisation. The difference in pattern between these languages or library simply means that they cannot work together without an interface. However, if the library or code exposes an API, then we don't have to worry ourselves with the full mechanisms and complexity behind the code. We then have to write a code that will call the implementation in the library and get the intended outcome and response as the case may be. This then means that we can setup development teams working with different languages or patterns that they are comfortable with but delivering the same overall outcome. ADD has become an integral part of software development, and when effectively utilized, it tends to commonize the background or skill set of the developers and focus more on the outcome of the implementation. It's the major reasons behind the success of large tech organizations like Facebook, Google, Twitter, Github and others. Most of these organizations have libraries or features that developers and organizations need and they continuously ensure that they improve and maintain those features. With ADD whatever we're building will simply be in sync with other technologies that we seek to make use of. It becomes even more interesting when you're on the other side that issues the APIs because you get to maintain your code at your own pace, roll out features for other people to make use of and receive significantly less feedback on breaking changes. I think of it most times as an intermediary between different technologies or teams that simply enhances collaboration among those differences.

• Scalability

  If your solution is growing and you often require your users to take an additional action or learn something new to make use of the new feature, then you might have to reconsider your approach because we're no longer in the 60's. Its actually a privilege to have someone make use of your application - be it web application or mobile application, because there're other options that the user could have chosen and in most cases the reason they stayed put with yours is that they have less actions to perform. Don't loss that competitive edge.
  Lets say you've rolled out the first version of your application and people are already making use of it. You then have additional features that you want to introduce to your users, the truth is that in most cases users don't care about your updates until you show them. The whole idea behind new or additional features is to make things much more easier for the user and the easiest and best way to show them those updates its via the same interface that they are already making use of. With ADD you will give your users more solutions without changing the behavior or relationship between your application and its users.

• Mobile

  The relationship between users and their mobile devices is one that we developers wish we could share :) That is so true buddy! If you actually thought that was the case, am sorry am not of the same school of thought. As a developer, am the Judge Lynn and I mediate with ease.
  Mobile devices have less capacity therefore your goal should be to ensure you reduce the size of your application on mobile devices. The best approach for me is the separation of concern. Mobile devices should mainly be for presentation while the main logic behind your application should remain on the server and communication should be via APIs. ADD makes this approach seamless because we cannot control the users device but we can control what they use and how they use them via API requests and responses. This also means that we can hire developers that major in different aspects - backend and frontend.

• Testing and DRY coding

  Honestly, no code should be shipped without testing. But imagine that you've written or inherited a legacy code with thousands or millions of lines and you're asked to debug. May the Lord be with you.
  If your application is API driven its most likely that its in units or components. That means you can individually scrutinizing your application - Unit Testing. You can event allow your testing team or other developers to test your application, collect feedback and debug individual component or units before its release.
  Lastly, the importance of a DRY code cannot be over emphasized. ADD helps us to adhere to this development principle. Thanks to Andrew Hunt and Davis Thomas for publishing the book titled: The Pragmatic Programmer I believe they've said it all.