If you leave a bee alone, you should ‘bee’ fine. Bees are also needed for pollination; without bees we wouldn’t have apples or oranges. In fact, the agricultural system will collapse since seventy of the Top 100 food crops grown worldwide rely on pollinators.
This isn’t an article about bees. It’s about APIs. When we talk to customers, it is not so much that they fear APIs. But they have a lot of questions about them. Unlike the bees, you shouldn’t ignore APIs. The API is increasingly becoming the gateway to the world’s services and your own services. For your IT landscape, APIs are what the bees are for agriculture: an indispensable part of the ecosystem. In this blog I would like to address some of the more pressing questions or topics with regards to APIs.
APIs are more than just a front end
The first question that we come across when talking about APIs is “are APIs just a front end?”. The answer is yes, but they are much more than that. There are lightweight, easy to understand and deploy, and are literally the gateway to the digital services within your organization. That requires attention from many angles.
How to start with APIs?
I believe you should adopt the concept of API-first design. Here you take an outside-in approach. What do my customers expect from me? Did we verify upfront that our offer meets their needs? Have we arranged everything to satisfy our customers throughout their journey?
This way your API design drives the backend. Chances are you have many existing digital services to build your APIs upon. But don’t fall in the trap of simply exposing your existing services as-is. That’s probably not what your customers are expecting. You must somehow morph your existing services into smart APIs. Perhaps you even can embed third-party services in your APIs, to add value quickly. That’s why integration still is such an important competence to master.
Your external APIs expose your digital assets, which is why these rules apply:
- Your API is THE user interface of your backend services
- Your API design drives their implementation
- Your API is (self)described
- Your API is published
- You manage the lifecycle of your API
API versions have a clear lifecycle, for example, created, published or deprecated. APIs however shouldn’t change often as this will disrupt and annoy developers who use and rely on the API. They could care less about the changes you make, unless these are the changes they requested. A new interface, changing payload requirements, should be planned for, and not implemented ad hoc. Too many changes can signal a poor thought process. You can place a middleware solution between API and backend to solve issues relating to changes, like a changing requirement, and provide for backward compatibility. Do not push developers straight into the new version, implement a grace period, but be clear on the timelines for retiring the API.
That’s why your API landscape needs both API Management and Smart Integration systems. APIs are only useful if there are client applications that use them. Therefore, you must publish your API where your target audience of developers can easily discover, try and comment on them. On the flip side, your APIs might have a target audience (internal and external), when developers outside that group discover your API, you want to deny their subscription request.
APIs need to have more than just curbside appeal; they need to be solid and performant.
We have so much more
Another question or topic has to do with the heterogeneity of the it landscape. We have some APIs. But we have so much more that is not opened up by an API. Does it make sense to start with APIs if my existing backend uses proprietary protocols, SOAP messages and other things? Yes, it does. Longevity in IT means that we have interfaces that date back to the middle of the last century. I am talking about Cobol, the IMS database, but also systems built with and on that technology. Later we got other technologies that we incorporated. Until we can say goodbye to those we need to integrate and open them up. This process is continuous, with new interfaces arising like Graph QL entering the IT world. The world runs not only on Dunkin Donuts, but also on APIs.
Your API landscape is the ecosystem where your APIs are king.
Are APIs an open invitation to hackers?
No discussion about APIs is complete without discussing security. Are APIs an open invitation for hackers? How do I keep the bad guys out and let the good guys in? It is true that the only way to be truly secure online is not to be online. Opening an API for business means that you should manage the API definition, traffic and users. That’s where we can help you.
Opening up means that you are making yourself more vulnerable. However, if you do not open up, how are you going to conduct business? Developers use your API and must access to the resources they need. Hackers look for vulnerabilities in an API definition, in the products that you use and the settings of your network. Making sure that these are hardened is vital. And of course, it doesn’t really matter when you lock the front door if you leave the back door wide open. Hackers do not wait for invitations; they will try it out. As a sport or from a more malicious perspective. That’s why the entire API landscape must to be secure. A chain is as strong as its weakest link. That is why this aspect deserves special attention.
What are you waiting for?
None of these topics are showstoppers in the sense that it should block organizations wanting to do anything with APIs. APIs are too important for businesses and issues (including future ones) can be solved. The rewards can be quite sweet, yet another thing APIs and bees have in common.
I have mentioned the term API landscape a couple of times in this blog. You can now see that this is more than just an API Management solution installed somewhere in IT. No, it’s much more than that. Read our Advanced API Management Guide and find out more.
{{cta(‘bbefec95-748f-4973-9464-b4b4a93e0338′,’justifycenter’)}}
