There has been a rash of new web UIs based on HTML5. Is a web UI the same as an API? Can we assume that a new HTML5 web UI is making use of an API on the back end, creating a new API, or is it using an older API? Presenting a web-scale UI today usually means an HTML5 UI. In many ways, this is better than the security bug-ridden flash APIs that existed in the past. Is this really about graphical front ends, user experience, or APIs? Or is it a question of all three?
While I personally am not a fan of graphical user interfaces, I do use one every day. Why I am not a fan stems from the past inherent slowness of graphical UIs, and web-based ones are no different. In the high-performance computing world, and in the LINUX or UNIX world, the command line rules. The command line often requires some bit of code between the application and the user: an API of sorts—not always an official API, but one that works. This is the foundation of the Puppet and Chef scripts we see today. Back in the depths of time, those products started as ways to organize and chain together the scripts we continually rewrote to make our systems work.
What seems odd today is that the command line and APIs are seen as incredibly new and interesting, and even caused Microsoft to create its own shell. In today’s computing, where everything is an abstraction, this is a good thing. Yet, it is still a cycle. Are the web UIs we are seeing today more of that cycle? I think so. Most people need UIs to make sense of things. APIs are often hard to understand, and they aren’t standard across platforms. They require more depth of knowledge to use effectively. Managing API keys, for example, is much harder than many people believe. Embedding keys directly into code is a cause of fraud and theft within AWS that costs some companies hundreds thousands of dollars monthly.
APIs are the world of today. Getting a handle on them is a major part of current IT taskings. This is where Puppet comes in. We also see a brand new breed of products and reinvented products driven solely by their APIs. This is a question I ask of vendors: “Is there an API I can use?” I prefer this answer when I hear it: “Our entire web user interface is driven by our APIs.” This is an excellent approach, as others are trying to use the tools via an API, and web UIs will push APIs in very different directions, often for the better.
This is not a debate about web UI vs. API: it’s about APIs being used 100% within web UIs. Private interfaces to gain access to data is not the way of the future: that’s the path that leads to breakage in items like microservices. Private interfaces can stall products when attempting to move forward into the new world of containers, microservices, and cross-hypervisor, cross-cloud applications.
This is the real reason we need well-defined APIs usable by shell scripting technologies, RESTful, and other APIs in the future. Containers are here to stay. Microservices are the future (as they were the past). Creating an application around a well-defined set of tools that presents a service, does it well, and is all it does is where we need to be. We are now back to “keep it simple” (do one thing well) services that we can chain together to create our applications.
These services all speak APIs, which can accommodate new services added to the chain, the workflow, and the application to manipulate our data.
A vendor’s web UI is a perfect place for the vendor to start using its own APIs. The future beckons, and it is driven by APIs.