Design Challenges: building a REST API which calls a 3rd Party REST API

893 views
Skip to first unread message

Andrew Little

unread,
Oct 2, 2012, 10:45:09 AM10/2/12
to api-...@googlegroups.com


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)

sune jakobsson

unread,
Oct 2, 2012, 11:33:58 AM10/2/12
to api-...@googlegroups.com
Ah, basically you want to add some kind of caching mechanism, so that you can speed up the requests, and keep feeding your clients.
As long as no-one bypasses your server the REST part should work out fine.

Sune

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group, send email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft?hl=en.
 
 

Ronnie Mitra

unread,
Oct 2, 2012, 11:36:55 AM10/2/12
to api-...@googlegroups.com
Hi Andrew,

My definition of long polling is when a client executes long blocking GETs until a response is received.  Is this what you are trying to do?  It sounds more like your clients will be executing short GETs to check on the status of the response periodically.

From the scenario you describe it sounds like requests could take a long time to be resolved.  In that case you might consider using a callback pattern in which the client becomes a server and waits for a response (i.e. the server sends the response message as a new HTTP request to the client).  I would classify this pattern as more complex for the client than polling, but will likely be less of a thread/connection strain on your server if that is important.

Stateful connections (like websockets) might also be suggested for situations like this, but it doesn't sound like that is the right answer here as you don't seem to have a need for bi-directional or low latency communication and you would be leaving the realm of HTTP.

Personally, I'd choose the polling method as it meets most of your criteria. I'm not sure why you think it's not RESTful, but I make a point of not going down that road!  Off the top of my head, I think the Twilio API has some examples of the callback pattern and Subbu's REST cookbook has examples of the polling style.

thanks,
Ronnie
@mitraman



--

Andrew Little

unread,
Oct 2, 2012, 1:00:46 PM10/2/12
to api-...@googlegroups.com, ronnie...@gmail.com
Thanks for the response, Ronnie.

I think I misused long polling.  I was attempting to describe standard client server polling: 1. client makes request and server responds with ACK, 2. client polls the server until a full response is returned.

Here is a significant piece of information that I left out unintentionally. In all but exceptional cases, the 3rd party API (in this case, Twitter) will respond very quickly and the API calling the 3rd party will experience almost no delay. So my problem with the polling solution is that we're introducing a more complicated polling behavior on all client apps to handle the exceptional case in which the 3rd party API is experiencing delays (perhaps high load situations). I believe we could get away with making all calls on the API in a synchronous fashion, though have not proven this theory.

I like your thoughts on the callback pattern. I'll take a look at that as well.

Mike Schinkel

unread,
Oct 2, 2012, 1:57:42 PM10/2/12
to api-...@googlegroups.com
On Oct 2, 2012, at 1:00 PM, Andrew Little <aali...@gmail.com> wrote:
In all but exceptional cases, the 3rd party API (in this case, Twitter) ...

Unrelated to your technical question and in the unlikely case your team has not considered Twitter's "Developer Rules of the Road"[1] you might want to make sure you are in compliance before you go down this path, especially 1.4.A and 1.4.E. It would be a shame to build something and then have Twitter block your access and/or send you a cease-and-desist order.

-Mike
[1]https://dev.twitter.com/terms/api-terms

Greg Brail

unread,
Oct 2, 2012, 2:54:37 PM10/2/12
to api-...@googlegroups.com
When you talk about making API calls in a synchronous manner, are you worried about the latency on the client, or thread usage on the server?

I agree that building a server that blocks a thread while waiting for a long-running API call to return is not going to scale if you have more than several tens of concurrent users of your API. (While OTOH if you only have a few users it won't matter.)

From your discussion about threads, it sounds to me like you are more worried about thread usage on the server than blocking the client -- and in that case, you need to do this using a proxy that uses async I/O. There are certainly products and tools out there that can do that (Apigee included) along with open-source libraries for async servlets and async HTTP clients (to use Java examples that I'm familiar with).

And if you're worried about blocking the client, doing the client-side stuff asynchronously is a good idea anyway, and if the client is built in JavaScript then you don't actually get much of a choice anyway...

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group, send email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft?hl=en.
 
 



--
Gregory Brail  |  Technology  |  Apigee

Daniel Crenna

unread,
Oct 2, 2012, 3:23:57 PM10/2/12
to api-...@googlegroups.com, ronnie...@gmail.com
One approach that might work well for you is to send your call asynchronously, but don't push it to a background queue right away. Give it the opportunity to complete quickly. You introduce a touch of complexity because clients may get one of two responses depending on the latency, but at least you cover 80% of cases and have a graceful way to handle the others.

Andrew Little

unread,
Oct 2, 2012, 4:03:32 PM10/2/12
to api-...@googlegroups.com
You are correct, I am only concerned about thread usage (scaling issues) on the server side. Handling things asynchronously on the client side is easy for us to do, so long running request/response cycles are not a problem (client side).

Thanks for the idea of using a proxy with async I/O.  I think this will give me some ideas to research and present some options for our API.  My aim is resolve the scaling concerns I have been hearing, but to present a solution that hides any async complexity from the client side applications - i.e. keep the API very clean and free of any Call/Job ID references. 

Andrew 

Andrew Little

unread,
Oct 2, 2012, 4:06:05 PM10/2/12
to api-...@googlegroups.com, ronnie...@gmail.com
Thanks, Dan.  I like this hybrid approach, too. Ideally, I want to keep things very clean on the client side, because there may be many applications requiring such additional logic. However, this definitely ensures that in most cases (i.e. 80%), we'd get a quick response without entering the polling loop.  Nice.

Andrew

Ben Longden

unread,
Oct 3, 2012, 3:20:51 AM10/3/12
to api-...@googlegroups.com
Hi Andrew,

I've used this Hybrid approach too - having an expected ETA for a request so that my API can either return a 'real' response, or a 202 (with a link to a 'status' resource for the request). It does add a little complexity on the client side as it needs to handle both types of response - but it does work well.

You could perhaps minimise the additional complexity by using a hypermedia type which supports embedded documents - if the request completes (ie, is not queued), embed the result data in the response. If it does not complete and returns a 202, the real result could be an embedded resource in the status monitor for the queued job. At least for both of these response types, you have the same way of retrieving the data once it is ready. application/hal+json is one of the formats which does support embedded resources in a response, to reduce the 'chatty' api syndrome. 
Reply all
Reply to author
Forward
0 new messages