If you are building new applications on public cloud platforms, you are faced with a choice: Should you build a set of APIs bound to the new cloud application’s application services? Or should you look for another job?
I’m seeing many new cloud applications that are built to fail. Not because they are poorly designed, but because they are leaving out the power of using application services with well-defined and designed APIs that let other applications access those services.
This use of APIs is no longer optional. The cloud platforms themselves are API-driven. They provide storage services, provisioning services, database services, etc., and they like to work with other things that use APIs.
Not having APIs means that you’re providing only a single path to access for the cloud-based applications: the user interface. Moreover, and most important, you’re not providing a path for reuse of the applications services.
) as well. An application that provides 330 functions or behaviors should also provide at least 330 APIs as well—and typically, many more.
Why? Although users will consume the application services using the user interface, there are opportunities to reuse much of the application, by other applications, so you are not reinventing the wheel for common services such as transaction validation or blockchain update. You certainly can find other uses for those services, and once they are discoverable by others in the dev shop, they will indeed find other purposes.
The benefit of this is financial: It’s cheaper to build new applications from existing services than to do it all from scratch. The benefit is also agility. If you can build or change applications that are API- or service-based, that will translate into additional business agility. .