Challenge Extended…
Can Mule expose an API without any understanding of the service it is supposed to proxy?
Recently, a client asked me to expose an existing service via a simple proxy that would allow external API consumers to pass through a firewall — and to do it using Mule.
There were a few constraints:
- Security: The service used its own API Key Authentication and at least one of the API consumers did not support Basic Authentication (a standard Mule API Policy and one generally enforced by the client’s security team)
- Compatibility: Th API exposed by MuleSoft had to be identical to the existing service; no change in any external system, except the obvious url change
So far so good. There were a few business / policy hurdles to overcome but no technical ones. And then came the clincher…
- Legal / Contractual: No MuleSoft developers were allowed to document, or even see, the structure of the API they were being asked to expose via the proxy. To even show the MuleSoft dev team this 3rd Party API’s documentation would find the client in breach of contract. The assumption was that the API consumers understand both the endpoints and the message structures for the calls they need to make.
In truth, this was not a difficult solution to implement. However, in light of the outlandish contractual constraint above, I felt this worthy of a post.
Could Mule expose an API without any understanding of the service it was supposed to proxy?
Challenge
I cast my mind back and recalled that earlier versions of Mule offered an HTTP Proxy connector. A quick read of the documentation showed that:
- This Proxy component had been deprecated in more recent versions and
- It wasn’t clear whether the older systems supported the HTTP Header requirements for the security aspects of this use- case
However — just because the latest version doesn’t offer a specific Proxy Component (as it appears at time of writing), that does not mean the good folk at MuleSoft have removed any of the raw power from their beast of burden.
It simply meant we would have to roll our own.
Solution
I reached for the humble HTTP Listener Component. A simple mask on the path meant we could expose an endpoint that would accept any relative path beyond the Base Path
Path: /my/api/root/*
Then, we snatched the relative path from the attributes:
message.attributes.maskedRequestPath
We then created an HTTP Request object and pointed it at the target service. We set the above value in said HTTP Request component’s Path, pointed at the server. Now, as long as our API consumer pointed at a valid target resource, we could back-to-back the calls without any understanding of the target API’s structure.
Next step was the authentication. This comes through as a header, set by the consumer when it calls our service. We simply grab the HTTP header value we’re looking for. In this case, the HTTP header is apikey but it could just as easily have been Authorization if the service used Basic Authentication.
message.attributes.headers.apikey
… and we set this in our request header.
In our case the target service made it easy as all API calls used the POST method. However, we could just as easily back-to-back the method using:
message.attributes.method
Payload was easy! As there were no transforms; it was a simple passthrough. The responsibility rests on the consumer to build a valid payload. After all, we are legally not allowed to understand what the payload looks like. This was the requirement, right?
The solution took 30 minutes to implement, including coffee breaks.
Conclusion
The lesson in this exercise? In the modern business paradigm, proprietary connectors are all the rage. To connect to Salesforce, stakeholders expect a “Salesforce Connector”. To connect to SAP, they expect an “SAP Connector”. And to connect to ACME’s Extraordinary Web Service, the industry demands — say it with me — an “ACME Extraordinary Web Service CONNECTOR”
What many stakeholders fail to recognise is this; most, if not all, of these proprietary products expose their bespoke functionality over tried and tested protocols that are as old as the internet.
Of course MuleSoft has moved with the times and it currently offers a raft of proprietary connectors to keep its growing client-base happy. However, the Mule has never forgotten its roots and it can still leverage those underlying protocols — on which all of these sexy new proprietary connectors are built — directly when all else fails.