Streamlining Experience Across Multiple Channels with APIs
And making sense of the true nature of experience APIs
Since the embracing and the vast adoption of APIs that follow the API-Led Connectivity, which in-turn is an abstraction of the Gartner’s PACE Layered Application strategy, applied to APIs, a lot has been spoken and discussed about the role of APIs that belong to the API-Led Connectivity’s Experience Layer, which is the counterpart of the Systems of Engagement layer in PACE.
These often have a focus on how APIs should be designed, implemented, tested, and deployed, following a mantra that determines that these APIs usually deal with applications and systems that directly interact with end-users, therefore focusing on their experience and agility.
It is possible though to enable and achieve a seamless and unified experience API that caters for multiple channels. Diving into the common issues and solutioning is the focus are of this article.
Experience APIs
According to MuleSoft’s vision and understanding of experience APIs, these in principle and essence are similar to process APIs in that they composite the content, features, and functionality of several other APIs, providing a business context for the data and processes that were unlocked and established with System and Process APIs.
However, unlike Process APIs, Experience APIs are more specifically tied to a unique business context, and they project data formats, interaction timings, or protocols (rather than process or create them) into a specific channel and context, and are meant to be consumed by its intended audience — such as mobile applications, internal portals for customer data, etc.
Multiple APIs and Different Experiences
Over the years though, what has been noticed is that the practical application of this concept has been translated into providing experiences tailored for specific needs of devices and systems, and not necessarily catering for smooth experience for users.
In practice that has led to a proliferation of so-called “experience APIs” that are no more than carbon (ish) copies of a previous API that makes the exact same calls as the others, but deals with data formats and protocols in a different way, according to what the consumer system supports, completely distorting the original meaning of the experience API concepts, and also adding limitations and barriers instead of removing them.
The diagram below depicts a very common scenario that demonstrates the adoption of experience APIs that not necessarily fully cater for experience as in user experience, but rather specific systems or devices needs:
In this fictious scenario, the different experience APIs exhibit the same traits when it comes to orchestrating calls to the process APIs:
- Call the Credit Checks API to check for the available credit (if any) for a customer, employee or partner.
- Call the Inventory Process API to check for product pricing, product stock levels and confirm/reserve items.
- Call the Order Fulfilment API to further process the order, generating invoice, scheduling delivery, etc.
The most obvious and outstanding issue with this approach can be immediately seen: It tends to become messier as new experiences and/or devices and systems are added and likewise, the complexity can scale quite quickly, introducing a whole number of other challenges around maintenance and evolution, possibly becoming very similar to a distributed monolith, having all of the APIs to be revisited and regression tested every time that a new feature is added, or there is a change in the orchestration process, or any other type of change that needs to cascade through all of the APIs.
The net result is often a depiction of the advantages of adopting an API-Led Connectivity and providing an experience API layer, making it very hard to share and reuse, and ultimately not necessarily achieving the end goal, which is providing a seamless experience across different channels.
In terms of implementation as in Mule applications, we would probably have 4 different applications with their own independent Mule flows (and others such as MUnits), very much similar to each other, similar to these:
NOTE: The exemplar flows above are assumed to belong to individual, independent APIs (MuleSoft applications — One flow per application) and have been implemented without using any actual API specification (such as RAML), nor using APIKit, so that they only demonstrate the technique.
None of the above statements and ideas take away the need for providing abstraction and adaptation for different types of consumers when it comes to what systems and devices support.
For instance, mobile devices have certain limitations and requirements that in fact require APIs that support and cater for specific data formats and protocols. Same goes for IoT devices and the list goes on with legacy systems and others that only support legacy integration models, etc.
To clarify even further, what all of that implies and illustrates is the need of separating the actual “experience” part, delegating any needs for orchestration and similar to a common API that does operates providing the required experience regardless of the source channel, data format and protocol, as the actual user journey and experience should be the same.
Seamless Experience Across Multiple Channels
A high-level design of this solution, that separates the orchestration from the adaptation of protocols and data formats can be demonstrated by the below diagram:
With that approach, we clearly separate the experience and orchestration logic from the actual adaptation provided by the consumer-facing APIs, now having a seamless experience across all of the different channels and corresponding APIs.
It does not end there, though! Let’s dive down and provide an exemplar implementation demonstrating the inner working between the external facing experience API and experience & orchestration API.
Even though it may sound like a cliche, there are many ways to go about solutioning this. For instance, as part of its documentation on Common Development Strategies and Best Practices and also within its Help Center articles, MuleSoft explain ways of implementing reliability patterns and also synchronous communication with request-reply pattern, which this solution is inspired by. This sequence diagram demonstrates how that would work from a high-level point of view:
Unlike the examples on the documentation (that lean towards using VM queues), to make this solution more scalable and decoupled, a request/reply pattern is being used, so that the orchestration API always publishes outbound messages to a “reply to” queue, passed on by the initial publisher (aka client facing experience API).
Now we can take a closer look into the orchestration & experience flow and its request/reply pattern that leverages Solace PubSub+ over AMQP protocol for exchanging messages back-and-forth:
Not explicitly dealing with canonical models or any other models, we have taken here a principle and approach of “dumb pipes and smart endpoints” and where transforming requests and responses in this solution have purposely left outside as yet again, there are many forms of dealing with to avoid redeploying an application in case of changes, which will be the focus of another article.
Conclusion
Making sense of the true role of experience APIs can be a daunting task, but hopefully this post has shed some light on this topic and helps on avoiding creating boilerplate, repetitive and time and cost consuming APIs, but instead helps on streamlining experience across multiple channels through a number of APIs.
Thanks for reading, stay tunned for more, and enjoy!
The Author
Eduardo Ponzoni is an experienced integration developer, architect, and manager with 20+ years of experience. Well versed public speaker and author of dozens of articles on all things systems and data integration. Leading from the front and by example, Eduardo is a MuleSoft Ambassador, holds several certifications and loves sales and delivery. He has led multi-disciplinary teams in digital transformation programs with MuleSoft, Kafka, Azure & Boomi. Currently leading the integration practice of Adaptiv, he is responsible for growing the integration business across Australia and New Zealand, from strategy, roadmap, vision, sales/pre-sales to hands-on execution & delivery as a people leader and technology specialist.
