Do you offer RESTful APIs? That is a question we often hear. And that’s no wonder, as REST API has become synonymous to cloud services which embrace openness.
Openness, in this case, means that a 3rd party service component of a larger application is from the beginning designed so it can be seamlessly integrated with, or often plugged into, the main service. The component focuses on performing certain limited functionality so well that other service providers can be expected to adopt it as a part of their own service – in order to achieve high quality user experience and enjoy faster time to market. The latter target is down to providing a unified service by eliminating need for context switching, which we discussed a few weeks ago.
Service providers want consistent branding…
These online services with APIs – or API offerings – come in many forms and variants. Some carry their own, specific branding, others do not. Usually, with some money put on table, a service provider can get a true white-label service component so that no other brand is visible, but their own.
Many offer some sort of free or freemium approach, and expect that significant part of those freemium users will eventually mature into paid users, and plan customer journeys accordingly. Often this means limited functionalities and performance throttling for the freemium users – which effectively may mean worse service. That really does not make sense, unless the service provider is absolutely certain that the user knows and believes that their commercial plans are a lot better.
In case the service is really focused on offering just a limited functionality in some standard format like JSON, it is quite easy to understand, how it works and should be integrated. The external service component just feeds the main service with functionalities and data, which can easily be made available through the UI the main service provider controls.
….And a unified user experience
However, if the external service offers its functionality through its own user interface, the waters get a lot muddier. How can these functional components be integrated into the main service? How do they interact with other functionalities offered? What about the overall security? And achieving a unified look & feel for the service?
In fact, the more complex the external component is, the more likely it is that the provider of the would like to customize its look & feel so that it really feels like a part of the service, not something that feels completely external.
High demand for openness
From Documill’s point of view, we’ve experienced the rise of demand for APIs. Our integrator partners ask for them, driven by customers, who are looking for external components that have the look and feel of their own. The demand for customizability via APIs seems to originate from larger enterprises, who are used to getting such flexibility from traditional integrator-driven project deliverables.
APIs offer us means to provide such a SaaS offering with highly customizable user experience.
In the mean time, it is our job to design the core functionality of these services as well as is humanly possible.
One size fits all? No!
And here comes a word of warning to other SaaS-focused software vendors or ISVs out there. It does not help telling customers: “but Sir, with a SaaS, one size, functionality and UI fits all”. That is not true – as a provider of the main service wants to give users a unified experience. It must look and feel like completely their own – not something which has been patched together by loosely integrated handful of 3rd party solutions.
So – in case your service component is not yet offering its core functionality via open REST APIs, maybe it should?