Document icon
We no longer even think about the fact that business centric people routinely publish new or changed content to web sites. We “know” that using a good content management system, bad things won’t happen even without strong controls. We simply trust the separation of the software platform from the content running on that platform. That same trust, intrinsic to the world of the web, is quickly creeping into the way we build mobile apps. The separation of platform from content is the new normal; the way to present relevant and up to date information on the client side of an engaging experience.

Contrast that with the way we manage the lifecycle of software. We have learned the hard way that unless we are very stringent about the configuration of all the parts of a software solution, bad things not only may happen, they are almost guaranteed to happen. “Murphy’s Law” is alive and well in software engineering – anything that can go wrong, will go wrong, sooner or later.

I have talked at length about the need for APIs to change at a different rate and pace than the underlying software systems of record. I have also argued that APIs do need to be managed and governed. How do we reconcile the two? Simply by managing APIs like content, not like software.

APIs should have their own simple, light weight lifecycles. The API owner should be able to declaratively decide what an API looks like, with whom to share that API, and under what terms and conditions. All done independently of the lifecycle of software assets providing data and function exposed through the API. We must trust the API platform to make sure that when we give the API owner this freedom, bad things will in fact not happen.

API platforms (such as IBM’s API Management solution) that “define APIs by configuration” give you the freedom to manage your APIs as content. Building APIs in software does not give you that freedom. A software centric approach to APIs requires much more elaborate controls and results in a much slower speed of change and sharing, ultimately requiring that API constructs are managed as part of your Software Delivery Lifecycle.

If an API was built through code then you would need to make sure that you could deploy the code to any environment. That you knew what runtime the code was associated with and could update accordingly. That code dependencies were understood and managed, including any leverage of code libraries. That the code was under appropriate quality controls, including any applicable security reviews. That the operations team knew about deployed instances of the code object and took it into account during maintenance. The list goes on, basically encompassing all the usual intricacies of software engineering and operations.

Think about how much easier it is to just define your API as a content configuration, manage it through simple policy assertions and finally deploy it through the click of a button! This is what a good API platform does for you.

Connect with me on @ClausTorpJensen or read my earlier blogs. You can also subscribe to the blog list here

1 comment on"Manage your APIs like content, not like software"

  1. […] feel that changing without defining a new version is sloppy engineering practice. My reply is that APIs are more like content than like code. There is no real value in defining a new version if everything is backwards compatible, yet there […]

Join The Discussion

Your email address will not be published. Required fields are marked *