Best Practices: Service Callout scenarios

[#1]

ServiceCallouts: Best practices for API proxy design and development

It is mentioned that "Don't make ServiceCallouts to other API proxies in the same organization, including recursive callouts back into the same API proxy."

So, Cant I reuse the services at enterprise level? Proxy A is fetching some data and wanted to use that in Proxy B so that I dont have to rewrite the logic. But the above statement mentioned in apigee docs says we cannot call proxy within proxy in same org?

Please advise.

Scenario: Proxy A -- Fetches a json object using apigee GET KVM APIs (small set of enumerated kvms like country codes etc )

Proxy B -- Make a service callout to Proxy A, here I dont want service callout to directly access GET KVM APIs directly.

[anilsr]

Dear @nagesh,

As far as i know, It's just a consideration. Seems like yours is a vaild use case. One obvious thing that i can think of is, basically there is a chance of recursive calls if you call same API proxy.

@Maruti Chand , @docs , @Mukundha Madhavan, @Ozan Seymen any idea regarding same ?

Cheers,

Anil Sagar

[madhans]

Is Proxy A fetching KVM values using management API intentionally ?

KVM policies can be used to fetch KVM values and can be directly placed in Proxy B.

[#4]

Is Proxy A fetching KVM values using management API intentionally ?

Nagesh>> Yes, I am using GET KVMs APIs

KVM policies can be used to fetch KVM values and can be directly placed in Proxy B.

Nagesh>> I didn't want to do that because tomorrow my data structure source might change it can be in cache, BAAS or anything else.

These are very light weight enumerated values like few country codes, language codes etc..

Is my above use-case valid or shall I have to go by your docs? Please advise.

[gnanasekaran]

Hi @nagesh

It is possible and in your case you could very well use it.

I am assuming the need here is

> there could be several other proxies that would call Proxy A to reuse the existing functionality and at the same time,

> abstract out the implementation details [kvm or cache or baas]

Things to note: consequences / considerations

> you are basically introducing an additional network call to Apigee runtime, so every API request coming into Apigee would result in 2 API requests

> analytics - remember 1, when you are viewing analytics. You could use filters to get visibility into individual proxies

> calling management API from proxy is not a good Idea. You already have a level of indirection with Proxy A - i don't know if you still want to abstract it out. KVM Policy is strongly recommended

> leverage caching, if possible, so you could avoid the additional hops most of the times, if not all

> leverage StatisticCollector in proxy A, to keep track of which is the upstream proxy calling this service - so you can get visibility on the usage of proxy A itself

Hope this helps!,

Thanks,

[#6]

Thanks a lot! for all of you for response and helping in detailed analysis.

[birute]

Don't forget to Accept the best answer 🙂