Multiple thread invocation in Rest Web Service

Question

I have a scenario in our Web Application.

GUI invokes a REST web wervice and further web service calls a procedure. However, the procedure returns data properly for most of the scenarios. In some scenarios it takes more than 5 minutes and a session timeout happens. Now client suggested that in this case if any procedure takes more than 2 mins then it should return to GUI with a message "XLS WILL BE SENT VIA EMAIL" and when procedure returns the data (let's say, after 10 mins) then it should mail the XLS file to requested mail Id.

I have one approach as of now.

To implement a check while procedure call starts and if it crosses 2 minutes then it will invoke another REST service and from existing service message will be returned. Now from second web service it will mail the XLS file.

But this approach will take more time 2 mins + 10 mins (Procedure response).

Please guide me best approach for this implementation.

Please note GUI Team , Web Service Team and Database Team are different and works in different organizations.

Answer 1

For long running tasks, blocking in order to return the response synchronously is not appropriate. What you should do instead is have your service accept the request, start the long running job, and return a success response.

Here's a basic design for this kind of thing: The client submits uses POST to send a request that starts the job. You then return a URI for the job that was created. A GET on that URI will (eventually) return the results but if it is not complete, returns some information about the status of the request and (if you can) an estimate of completion.

Sending the result in an email is a modification of the above. I get the sense that email was chosen simply because a solution was needed but if this is important, you can have the results sent along with the above or simply use the GET on the created resource for retrieving the status.

The big difference here is that instead of waiting 2 minutes to return and say "working on it", you do that right away and release the client from having to wait. Then the client can poll for the results or receive the results by email. Generally, it's better to have everything be consistent and process each request the same way.

Answer 2

The recommended solution is to return 202 Accepted (http status for saying request has been accepted for processing but processing is not complete)

Then notify the user upon completion of the request. WebSocket is a popular mechanism to accomplish this.

It is not recommended for user facing operations to take more than a second, even if the user is aware the server is doing work.