How to handle asynchronous operations in REST

Question

I need to understand what approaches there are to handle asynchronous operations in REST and what their advantages and disadvantages are. Some approaches I found:

1. Resource Based: Where the status of an operation is modeled as a status. User makes an async REST call (PUT, POST etc.) gets Accepted or In-Progress response (202). Further a status URI is polled repeatedly via GET to check status/progress/messages from operation execution.

   Question: How long should this resource be active at Server? If the client polls in large intervals where in between the operation completes, how do we return the status? Seems like persisting the execution status would work. But how long to persist, when to archive/delete, is this kind of standard approach?

2. Callback Based: Where an async request is required to have a callback URI. The request gets processed asynchronously and upon completion makes a call to the callback URI with the operation status/result.

   Question: This seems more elegant and involving less overhead at the server side. But how to handle scenarios where the callback server is intermittently down, not responding, etc.? Implement a typical retries where the callback URI provides retries configuration as well? Is there any other downside to this approach?

3. Servlet 3.0 Asynchronous support: Where an HTTP client makes a connection to a Java Servlet, which remains open until it is explicitly closed and until closed client and server can communicate asynchronously over it.

   Question: Since its Servlet 3.0 spec, I think Jersey, the Spring REST implementation, doesn't utilize this approach as of now. Is there any specific REST implementation which utilizes a similar approach or pointer on ways to make it possible?

4. Any other approaches, maybe commercial ones?

Answer 1

Spring 3.2+ supports the async features of Servlet 3.0. From the Spring Blog:

you can make any existing controller method asynchronous by changing it to return a Callable. For example a controller method that returns a view name, can return Callable instead. An @ResponseBody that returns an object called Person can return Callable instead. And the same is true for any other controller return value type.

Jersey 2+ also supports asyncronous servers. See the Asynchronous Services and Clients chapter in the reference docs.

Answer 2

I think, the approach depends on time gap between initial request and the end of operation.

• For short-time operations ( < 10s ) I would just keep the request open and return response when operation finished;
• For long operations ( < 30m ) I would use servlet 3.0 or Comet model;
• For extremely long operations ( hours, days ) good enough way, as for me, is just client-based polling or Comet with big timeouts.