<div dir="ltr">Hi Bob, <div>This is usually solved at the application layer with a BUS doing this API composition. Then APIMan would expose that API instead of the multiple internal APIs. If apiman was combined with Fuse or camel, this could be done, but I do not think that would be an easy feature. <br></div><div>Usually is best to place that logic into a BUS layer, and then expose that service as well as an aggregated service, this way you could expose all the single services and the aggregated one.</div><div><br></div><div>Cheers,</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-22 13:06 GMT+01:00 Eric Wittmann <span dir="ltr"><<a href="mailto:eric.wittmann@redhat.com" target="_blank">eric.wittmann@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Bob, thanks for the question. I have CC'd the apiman mailing list in<br>
case the answer is interesting to others.<br>
<br>
Hopefully I understand the question, which is around aggregation of<br>
various disparate APIs into a single application specific API. I think<br>
that apiman does something similar to what you are suggesting, in that<br>
all API endpoints end up going through the API Gateway rather than<br>
directly to the various disparate services.<br>
<br>
In other words, if a single application may consume N different services<br>
provided through apiman, *all* of those services are ultimately consumed<br>
through the root API Gateway endpoint (e.g.<br>
<a href="http://gatewayhost.com/api-gateway/*" target="_blank">http://gatewayhost.com/api-gateway/*</a>).<br>
<br>
That isn't quite the same as creating an application-specific API, but<br>
is perhaps functionally equivalent.<br>
<br>
At the moment we do not have any specific plans to implement API<br>
aggregation in apiman, but if there were community interest in it then<br>
we would certainly consider adding it to the roadmap. :)<br>
<br>
-Eric<br>
<br>
<br>
On 1/21/2015 1:44 PM, Bob McWhirter wrote:<br>
> Heya Eric—<br>
><br>
> So I’m looking into Microservices, and one thing that always pops up is an "API Gateway” which might consume N services and expose them as a single service.<br>
><br>
> The use-case being that while a fat application (desktop, web, etc) might talk to 15 different services, something on a constrained network (such as Mobile) would rather have an application-specific API that handles aggregating some subset of those 15 services into a single service, reducing round-trips.<br>
><br>
> Is this a use-case planned for by APIMan? Or would APIMan be placed in front of an API Aggregator?<br>
><br>
> Thanks!<br>
><br>
> -Bob McWhirter<br>
><br>
_______________________________________________<br>
Apiman-user mailing list<br>
<a href="mailto:Apiman-user@lists.jboss.org">Apiman-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/apiman-user" target="_blank">https://lists.jboss.org/mailman/listinfo/apiman-user</a><br>
</blockquote></div><br></div>