One of the questions that I run into frequently is whether APIs should be designed to be reusable. What is important to realize is that reusability implies stability over a relatively long period of time. Such stability is usually appropriate if an API is to be used for partner integration or exposed externally as part of your business model. But what if the API is created simply to improve the collaboration between your mobile development team and the team maintaining a backend system of record?

In an earlier blog, Developers want easily consumable APIs, I called out that to a developer:

– Reuse is about speed to deliver

– Sharing is about expediency

– Encapsulation is about less to learn

An API needs to be attractive to use – and speed, not stability, is the critical factor. Thinking about the implications of this, if the needs of the mobile developer change very rapidly, then your APIs must change very rapidly to keep up. This is the case for opportunistic APIs.

Mobile collaboration

In my opinion there is nothing in the concept of an API that requires it to necessarily be reusable or stable over time. Whether reusability and stability are important or not depends solely on your business purpose for having the API. If that business purpose implies rapid change, then rapidly created (and changed) opportunistic APIs is a good thing rather than something to be avoided.

There is an implicit assumption in all of this, namely that creating and maintaining APIs is both easy and cheap. If not, then the cost of opportunistic change becomes impractically high. API Management software focuses on this particular challenge. Good API Management solutions create APIs by configuration rather than coding and the task of creating or changing an API can usually be completed in minutes. This reinforces an observation from my previous blog about gateways enforcing the Ts&Cs for managed APIs – the nature of an easily managed API is that it is both defined and controlled by configuration.

Importantly there is significant value in properly managing even opportunistic APIs. Managing opportunistic APIs provides:

– Definition and enforcement of business and IT controls

– Global insight on how an API performs business wise

– IT operational flexibility for moving around and dynamically scaling API workloads.

Bottom line, depending the circumstance opportunistic APIs can have significant business value.

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

2 comments on"The case for opportunistic APIs"

  1. I find this post quite misleading.
    “What if the API is created simply to improve the collaboration between your mobile development team and the team maintaining a backend system of record?”

    Good, but then it’s your own internal API. If you’re talking about internal APIs, it’s nobody’s business anyway. In that case, reusability is not important and you control the stability yourself. Nothing opportunistic about that. You don’t even have to call it an API.

    If we’re talking about public APIs, it becomes a different story altogether.

    • ClausTJensen August 19, 2014

      Thanks for taking the time to read and reply, its a great topic to discuss.

      There is definitely a difference between public APIs and internal APIs, fully agree.

      Looking at internal APIs only, I see the enterprise reuse discussion come up quite often. The blog entry is simply calling out why reuse is not always the way to go.

      Generally I believe the term API is appropriate and useful for internal use cases, and I have seen API Management solutions being deployed for internal APIs at least as often as for public APIs. Internal APIs should be designed by configuration, should be easy to consume and there is value in having them managed in an API Management fashion (runtime controls, developer portal etc.)

Join The Discussion

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