I am working with a team tasked with building a REST API which in turn makes calls into a 3rd party REST API. So if I make a call to GET followers/ids, then our API will in turn call the 3rd party GET followers/ids, then perform some basic processing to the 3rd party results before returning to the caller.
The challenge identified by the team is that we do not control the performance of the 3rd party REST API, and therefore it's a risk to make these 3rd party calls in a synchronous manner. Arguments I have heard is that a long running 3rd Party call would keep a thread open for an extended period of time and we could start to see outages in high traffic periods when 3rd party calls are taking a long time. The solution proposed is to move to a long polling/async approach. In this approach, the caller of GET followers/ids is immediately returned a unique Call ID and then asked to poll for the results. On the server side, the call is processed in a queue. This does certainly release the thread, but then requires the callers to poll for results.
I'm not a seasoned REST API architect, but this "long polling"/asynchronous approach does not seem to be the best approach to solving the design problem of an API which calls a 3rd party API.
Wondering if anyone could suggest an alternate solution, or point me to some examples in which a REST API does exactly what we're trying to achieve.
My arguments against long polling:
- not RESTful
- adds complexity to the callers of the REST API
- inconsistent API implementation (mix of sync and async)
- polling may cause performance problems because 1000s of clients are constantly making calls (albeit shorter calls)