Hello everyone,
I’m currently working on a project where I have three different backend APIs that serve the same business purpose, but are technically very different. Specifically:
They differ in HTTP methods (e.g., some use GET, others POST)
The request body structures, query parameters, headers, and response formats are all different
What I want to achieve is to expose a single unified API facade via Apigee X. This unified API would act as the public interface for clients, while internally routing requests to the appropriate backend and transforming both the request and response payloads accordingly.
The goal is to shield clients from backend differences, so they only interact with one stable, unified API regardless of which backend actually handles the request.
My questions are:
Is this architecture achievable with Apigee X alone — given the level of transformation needed for requests/responses, across multiple diverse backends? (if yes how to do that in api proxies)
If not fully feasible with Apigee X, what Google Cloud products or architectural patterns would be better suited for building this kind of middleware layer?
Are there any best practices or examples from similar use cases?
To be transparent, I have some doubts that Apigee alone is flexible enough to handle the depth of transformation required here(specially that we have not to add important latencies to api calls)more then 5B calls per month. But I would really appreciate input from experts in the community to either validate or challenge this assumption.
Thanks in advance!
LinkedIn
Twitter
