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.

Solved Solved
1 16 8,343
1 ACCEPTED SOLUTION

Not applicable

Nagashree I think you summarized the philosophy correctly. Typically you will see better performance by directly calling the target rather than looping back through the proxy. The proxy will reapply things like apikey validation, rate limiting, auth validation, etc . When you call the target directly you have the opportunity to optimize the call as well, perhaps trimming the result set to precisely what you are looking for.

Certainly there are valid use cases for API chaining but the downside risks and the performance overhead have to be examined very carefully.

View solution in original post

16 REPLIES 16

Not applicable

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.

Yeah, I think that term API Chaining has been used for different meanings in this posting. Some discussion here is about performance of API Proxy Chaining (not API Chaining). API Proxy Chaining is a term sometimes used by Apigee which refers to Apigee Edge API Proxies that, again, proxy requests/responses for other Apigee Edge API proxies in the same Edge platform environment.

The original ask triggered conversation about why we don't recommend chaining Apigee API proxies. I think the term API Chaining might have been slightly misrepresented in the original ask.

Yeah I noticed you guys have been using the term 'API Chaining' without regards to my research; It's a little disconcerting. What you guys are doing is 'method chaining' regardless of whether you are using an API to call it or not. An API call is instantiated by a client and thus and 'API chain' would be an IO MONAD instantiated by the client using one request/response. And using API automation with an interceptor and shared IO State, this is 100% dynamic. 100% stateless, CPU bound, and single threaded.

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.

Not applicable

Nagashree I think you summarized the philosophy correctly. Typically you will see better performance by directly calling the target rather than looping back through the proxy. The proxy will reapply things like apikey validation, rate limiting, auth validation, etc . When you call the target directly you have the opportunity to optimize the call as well, perhaps trimming the result set to precisely what you are looking for.

Certainly there are valid use cases for API chaining but the downside risks and the performance overhead have to be examined very carefully.

If you abstract communication logic from business logic, there is not performance overhead as you will have a push/pull mechanism in the interceptor which creates BETTER performance by not dropping the thread and staying CPU bound rather than IO bound.

orubel
Participant I

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 ( https://www.youtube.com/watch?v=mZOs7oz0JOI )

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'

Appreciate the link (good read) but understand the context of this question relates to current best practice recommendations for Apigee Edge. As such, I consider the question answered. Perhaps another thread on this topic would generate good conversation, but as it stands within this thread I believe the best answer has been given to the original question and I would like to avoid confusion for others who happen upon this thread looking for similar information as the orginal poster.

Thanks for your inputs!

Well it was entitled 'API Chaining'; this pertains to my work. So my attempt was correction and education both of the public and the Apigee responders since everyone was following the same error in terminology and functionality.

My apologies if I offended.

orubel
Participant I

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.