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.
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.
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