Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We maintain an API that as part of its purpose makes a call to an external API. This external API takes a few seconds to fulfil the request we make to it. With our current architecture the request is made synchronously, meaning that the http response we return to the user request is blocked until our service get the response from the external API.

I am considering changing our architecture to be able to deal with the request asynchronously... By this I mean accept the user request into our API and put a message on a queue so that we return an http response a lot quicker. The response would contain the address of where the full/complete result can be found. A background task would then pick messages up from the queue and make the call to the external API, then store the result at the address provided in our response. The address could then be polled by the user/client until the desired state of the respource is reached (i.e. when the background task has finished calling the external api and has stored the result).

This architecture I have mainly lifted from the REST in Practice book. The crux however is that our external API only takes 2-3 seconds to return the response. The example in the book describes an ordering process that might take minutes or hours. Is this suggested solution worth the increase in complexity for such a short response time from our external dependency? i.e. will the application still scale with the existing synchronous architecture?

share|improve this question
add comment

1 Answer

There is nothing in REST that stops you from mixing synchronous and asynchronous solutions per resource and method combination.

For example in our query server we return almost everything synchronously as the resources/information are readily available. Only when a new query is posted, do we go the route of generating an identifier and returning an "Accepted" or "See other" (303) response with the URI of the query results resource in the body as well as the location header. Returning information about the query and the query results themselves is done synchronously again.


Don't have any numbers on the average delay before result data is available for a posted query. We are still working on the REST implementation. However, queries in our current architecture usually take milliseconds to complete (we are sort of an in-memory database), though we have customers where some queries are known to take 20 minutes to return a result. So in a sense the need for asynchronicity isn't so much the average delay, but the fact that we do not want to have any requests that could block a connection for any serious period of time (> 1 second or so) and customers can post queries that run for more than that.

To give a few more details on the asynchronous execution of queries:

  • The "query result" is a resource that holds the basics about the results of a posted query: identifier, status (progress), uri for the result data (empty / absent until that is available), those kinds of things.
  • The new "query result" resource is stored immediately and before the response to the POST is returned.
  • The query process updates the "query result" with its progress and ultimately with the total number of rows in the result data.

In other words: the new "query result" resource is queryable as soon as the POST returns. It just isn't complete yet. Polling the query result will show status and progress and once the query process finishes, status will be finished and the uri for the result data will have a value.

share|improve this answer
That sounds much like what I plan to do. What is your average delay between accepting a request for a new query and storing the new resource in the database so that they are accessible to the client? –  Nick Jul 17 '13 at 11:30
@Nick: see update –  Marjan Venema Jul 17 '13 at 17:21
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.