0

In the best practice documentation of apigee I found following sentence:

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

Is there any explanation why I should not use recursive callouts in an API proxy? I only found one argument regarding the performance.

My case: We check if there is a token (if not - create a new one) and then create a service callout to an URL and receive either a correct http code or a 400 http code (this occurs if our token is expired, but was there). The user should not know that his token has been expired. We can't check, if his token is expired prior to the service callout to the URL. So we only know if there is already a token or not. If there is no token and the token will be generated by us, the service callout works always with a 200 http status code. But if the token is invalid we need to send again the request as a service callout. Best way would be recursive - so that in the response we could delete the existing, but expired, token and start the whole process again.

I hope it could be understood somehow...

Mike S.
  • 1
  • 1

1 Answers1

0

The real issue here is that if you call back to exactly the same service you can create an infinite loop and there is currently no model in place to keep that API from looping back on itself forever. This can lead to your entire org crashing.

Michael Bissell
  • 1,210
  • 1
  • 8
  • 14