Constructing a facade for microservices in Azure API Management

Question

I want to use Azure API Management as a gateway for a bunch of microservices in the backend. From the perspective of the consumer, I wish to present a consistent API surface i.e. a single OpenAPI spec and all actions available from the same base path e.g. /exampleapi.

How should a problem like this be approached in Azure APIM? Is it the only way to construct and manually maintain an API spec separately in the gateway and then fiddle around with the e.g. 'choose' and 'set-backend-service' policies?

What I find lacking in this approach is the inability to reuse existing API specs at all. Those could potentially already be available from the backends - and maintained by the teams implementing the microservices themselves. And I would like to avoid repeating this effort.

What I find especially disheartening, is that it does not even matter how many microservices you have - as soon as you have more than one, you immediately lose all ability to reuse and automate (e.g. "importing" a microservice into API management is not applicable - as that would be published as a separate API from the consumer's perspective). Even having the teams agree to some standard, does not help.

But is there any other way, especially for RESTful APIs? I'm aware of how this is tackled in the case of e.g. federated GraphQL.