API chaining
If I have a scenario where one api proxy needs to call another API, what is the best way to do it?
I checked the javascript mashup example. Do both API calls essentially pass through the API gateway or can they be handled by the message processor itself? (i am checking on the latency here)
I checked the best practices link, it said DO NOT use service callout to invoke a proxy from inside another proxy. Pls let me know the most efficient way to do it.
Do not confuse 'method chaining' with 'api chaining'. API Chaining is a client-side IO Monad that allows clients to dynamically create chains using one request/response to return data. This is EXTREMELY useful for mobile applications but cannot be done using the 'old' api pattern; one must implement the 'new' api pattern wherein the communication logic is abstracted from business logic.
Answer by Michael Malloy
·
Jan 29, 2015 at 05:32 PM
There are two reasons why the best practices mentions to not use a Service Callout to call another proxy
- Performance - A Service Callout to another proxy uses more resources. Latency for a Service Callout to another API proxy will be slightly slower than calling the API directly
- Circular References - You will get unexpected results if a chain of API calls ends up calling the same API twice
Generally, it is better to avoid calling one API from within another, but if you are in a position where you have to do that, you will need to use a Service Callout. If you end up doing that, please take extra care to ensure that there are no circular references in your API chain.
The circular reference isn't slower and is the better solution as it provides a push/pull mechanism for forwards/redirects (thus avoiding a dropped thread and IO binding when redirecting to proxy/api gate). You do this in an Interceptor.
Michael's answer is in the context of the Apigee Edge product and how Edge API proxies perform when you chain them together. API proxy chaining in this context is:
client <--> api proxy 1 <--> api proxy 2 <--> api backend service
where api proxy 1 and api proxy 2 exist in the same platform, but have no direct relationship in their code processing. Communication between api proxy 1 and api proxy 2 is HTTP requests leaving the platform and then entering the same platform for the same request going to the api backend service.
But the question was on API Chaining. As stated, this is 'method chaining'. The API pattern binds communication logic to business logic through the data (ie RestfulController, JAX, etc). As such, one cannot separate the data from functionality unless one abstracts the communication logic. Thus when doing a forward/redirect to Apigee Edge, the same problem occurs... dropped thread, IO bound processes.
Within the context of Apigee Edge and abstracting the communication layer to an Interceptor, one can avoid this architectural cross cutting concern. Make sense?
Oh and an api chain is actually done like so...
https://github.com/orubel/grails-api-toolkit-docs/wiki/API-Chaining
Not trying to be rude. Just trying to avoid alot of assumptions being made here.
Answer by Nagashree B
·
Jan 30, 2015 at 06:01 AM
Thanks Micheal. In essence you would say that, it is better to call the backend service (target url) directly from within an API proxy using service callout rather than calling another proxy pointing to the target url; and this would give better performance.
API Chaining is a pattern created by Owen Rubel and shown at ApiDays (see spec for api chaining - https://github.com/orubel/grails-api-toolkit-docs/wiki/API-Chaining). It is an IO Monad relying on IO State wherein a client can send a string of inter-related apis which the backend can batch in one request/response without requiring any hardcoding ahead of time (ie everything is automated).
This CANNOT be achieved using the existing API pattern as communication logic and business logic are bound with IO data being bound as well and unshareable across the architecture creating an architectural cross cutting concern.
The new API pattern moves communication logic to a higher layer and unbinds IO state so it can be shared thus creating a more automatable api, greater CPU bound processes vs IO bound processes, less code, less tooling, greater scalability, easier deployability, etc.
See this video for an example of IO state in API Architecture ( )
As for Michaels statement about slowness, this is incorrect. When communication layer is separated from business logic so that IO state can be shared across architecture, this allows for a push/pull mechanism. In Spring framework we call it a handlerInterceptor. We can intercept the request/response and loop them back when doing forwards/redirects. This allows for greater automation of data checks, role checks, batching, api chaining, etc
So there is no speed loss. In fact, by GREATLY reducing mobile throughput, there is a huge speed GAIN! And because you can use a common returned resource for your api, you can cache that object easier and your api calls are greatly sped up.
I voted this answer down as it doesn't pertain to the Apigee Edge platform, which is the context of the question being asked. I understand your statements about API chaining in general, but they aren't accurate for implementations on the Edge platform at this time.
Actually it does if you understand it. The API instance needs to abstract the communication logic from business logic to avoid the issue. The issues you are talking about are incorrect implementations of the API pattern in concerns with architecture which cause architectural; cross cutting concerns in relation to communication functionality/data in the API instance.
This directly relates to the question as that is HOW API chaining is done; anything else is 'method chaining'
