How to handle asynchronous operations in REST

Question

I need to understand which pros-n-cons approaches to handle asynchronous operations in REST. Some approaches that I have found:

1- Based on resources:. Status status is modeled as status. The user makes an asyn REST call (PUT, POST, etc.). Gets an Accepted or In-Progress ( 202 ) response. Additional uri status is re-processed via GET to check the status / progress / messages from the operation.

Question:. How long will this resource be active on the server? If customer surveys are at large intervals, when between activities ends, how do we return status? It looks like the execution status will remain. But how long to persist, when to archive / delete, is this such a standard approach?

2- Based on the callback:. If an Async request requires a callbackURI, the request is processed asynchronously and, upon completion, makes a callbackURI call with the status / result of the operation.

Question: It seems more elegant, less server-side overhead. But the scenarios in which the callback server is interrupted without reacting, etc., How do we deal with this? Implement typical retries in which callbackURI also provides retry configuration? Is there any other drawback to this approach?

3- Servlet 3.0 Asynchronous Support:. If the HTTP client for Java Servlet creates connections that remain open until they are explicitly closed, until the closed client server can asynchronously exchange data on it.

Question: With its Servlet 3.0 specification, I think that Jersey, Spring's REST implementation does not use this approach at the moment. Is there any specific REST implementation that uses a similar approach or a pointer to ways to make this possible?

4 Any other approaches may be commercial?

Answer 1

Spring 3.2+ supports asynchronous functions of Servlet 3.0. From the Spring Blog :

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

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

Answer 2

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

• For short-term operations (<10s), I would just leave the request open and return a response when the operation was completed;
• For long operations (<30 m) I will use the servlet 3.0 or the comet model;
• For very long operations (hours, days) it’s good enough, as for me, it’s just a client-based survey or a comet with long timeouts.

Answer 3

Now I am dealing with the same situation and have found a general approach to using the response of the Location header to give a resource that can be controlled to check the status (by polling, of course). This seems to be the best, but in my case I am not creating a resource, so I have no place to check the status (my asynchronous process is just creating a cache page).

You can always use your own headers to give an estimated time to complete the operation. Anyway, I am thinking of using the Retry-After header to give an approximate time. What do you guys think?

Answer 4

I know this is old, but I thought I would say here to say that if what you want is something that can scale in a stateless environment, then you should go with the first option. You can perform the basic operation anywhere, and if you put the result in something like redis, it will not matter which web server the client performs subsequent polling requests. I usually put the polling interval in the response that I sent to the client. When the result is ready, I will return the SEE OTHER to the client, which includes the result identifier in the URI.