“I want an Insurance API”
“I plan to use SAP’s APIs”
“Where can I find the Watson APIs?”
These are good questions / statements, but they are not about API Management, they are about APIs
that are provided by something. I speak to businesses about managing APIs but am often asked about providing APIs. This indicates that there may be confusion between APIs that are provided and APIs that are managed. So, this is today’s topic.
Providing APIs
As Systems of Record software is modernized it has become very common to expose API interfaces as part of the new functionality in the new versions of software. Software programs such as SAP have done this. SAP APIs provide access to SAP capabilities – data and transactions supported by the SAP platform. Companies may use these APIs as simple to understand interfaces to the SAP platform.
Similarly, many cloud based platforms (e.g. IBM's Watson APIs and Weather APIs) also expose their capabilities via APIs which are easy to understand interfaces to their functionality.
Other products such as IBM App Connect Enterprise (previously called IBM Integration Bus) can expose APIs. Data access products such as Infosphere Datastage also can create REST APIs. And z/OS Connect can enable REST based access to mainframe assets such as CICS.
This certainly is not limited to IBM products. Almost all vendors have recognized the value of APIs and are providing API access to their product capabilities.
But, do not confuse the fact that an API has been provided with management of these APIs.
Managing APIsAPI Management solutions can also create APIs (more on this below) or just proxy to one that has been provided as described above. But, that is just the start. I often say – “If you build it they will come – does not work.” API Management is about Creating, Securing, and Managing APIs. Let’s look at each of these:
- Create
- While many software products are providing APIs, there are still others that do not. So, one aspect of creating APIs in an API management solution is to support the existing software assets that do not provide their own APIs but are still required parts of the solutions your business is trying to build. This might include web service interfaces, databases, or other software products that do not supply their own APIs.
- A second aspect is to provide consumer oriented APIs, not provider oriented APIs. In the earlier section on “providing APIs” these APIs that are focused on what the providing software can give you. They are provider focused. The SAP APIs only supply information that is in SAP. If this is all the consumer is looking for, then we can simply proxy to this API. However, if the consumer wants a solution that is a combination of the data that is in SAP plus other applications - perhaps from Watson and the mainframe, then we can create one new consumer oriented API that invokes all the necessary APIs sourced from SAP, Watson, and z/OS Connect to provide the consumer with the answer that they want rather than give them many provider oriented APIs and force them to build the solution themselves.
- Secure
- Controlling who has access to the APIs and what they can see/do is another core function of API Management. A runtime gateway will authenticate any calling application and potentially the user of the application if necessary, allowing them access only to the appropriate information.
- In addition, we may want to limit how often an application can call the API (i.e. rate limits). This is important to protect the back-end systems from being overwhelmed by requests, but also to support distinct levels of consumption and potentially become part of a monetization model for accessing the business resources.
- Manage
- After creating the APIs, we need to manage them. The APIs need to be tested and moved through a lifecycle (Test, QA, Production, and eventually Retirement). When ready we need to publish the APIs so that they can be consumed by our target audience - and only that audience. We also need to deploy the API to the gateway so it can be secured during execution. New versions of APIs need to be handled with appropriate migration of API consumers.
- Driving consumption of the APIs is critically important. Where can the consumers find the APIs? How can consumers perform self-service subscription to use the APIs that are provided? How do they get sample code to invoke the API or documentation? All of this (and more) is done through the developer portal to help automate the self-service consumption of the APIs.
- Understanding who is using the APIs and how much goes a long way to driving a successful API initiative. Role based analytics show business and technical information about the API consumption. Usage information may also be part of a monetization model for your APIs.
This is not meant to be a complete list of everything that is done in API management. The point was to show some of the differences between “having an API” and “managing an API”. Providing APIs is a great start. But, this is not sufficient to drive an API initiative. Attempting to drive an API initiative with unmanaged APIs can cause problems – ranging from lack of consumption, to lack of security, and lack of visibility. API Management provides the capabilities to Create, Secure, and Manage APIs, and allows your business to truly execute an API initiative.
To understand more about IBM’s thoughts on the API Economy visit the IBM
API Economy website. IBM API Connect is IBM’s complete foundation to Create, Run, Manage, and Secure APIs. You can find more information about IBM API Connect at the
API Connect website. And you can also experience a
trial version of API Connect.
If you have questions, please let me know. Connect with me through comments here or via twitter
@Arglick to continue the discussion.
Related Topics:#APIConnect#APIeconomy#APIEconomy#APImanagement#APIscience#APIsecurity#APIstrategy#api_strategy#BusinessStrategy#createapis#experienceAPIs#FirstLook#ibm#ibmapimgt#manage#provideapis#security#think_apis