Long-running operations (async responses) in Rest API - Step-by-Step Execution

Concept Flow - Long-running operations (async responses)

Client sends request

↓

Server receives request

↓

Server starts long task

↓

Server immediately responds with 202 Accepted

↓

Client polls or waits for status URL

↓

Server processes task in background

↓

Client receives final result when ready

The client sends a request for a long task. The server starts it and immediately replies with a 202 status and a status URL. The client checks this URL until the task finishes and gets the final result.

Execution Sample

Rest API

POST /start-task HTTP/1.1
Response: 202 Accepted
Location: /task-status/123

GET /task-status/123
Response: 200 OK
{ "status": "completed", "result": "done" }

Client starts a long task, gets a 202 with a status URL, then polls that URL until the task completes.

Execution Table

Step	Action	Request/Response	Status Code	Notes
1	Client sends start request	POST /start-task	N/A	Request to start long task
2	Server accepts request	202 Accepted	202	Task started asynchronously, returns Location header
3	Client polls status URL	GET /task-status/123	N/A	Client checks if task is done
4	Server responds with status	{ "status": "processing" }	200	Task still running
5	Client polls again	GET /task-status/123	N/A	Client waits for completion
6	Server responds with result	{ "status": "completed", "result": "done" }	200	Task finished, result returned
7	Client uses result	N/A	N/A	Client processes final data
Exit	Task complete, no more polling	N/A	N/A	Polling stops as task is done

💡 Polling stops when server returns status 'completed' with the final result.

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 6	Final
task_status	none	processing	processing	completed	completed
response_code	none	202	200	200	200
result_data	none	none	none	"done"	"done"

Key Moments - 3 Insights

Why does the server respond with 202 Accepted instead of 200 OK immediately?

Because the task takes a long time, the server replies quickly with 202 to say it accepted the request and will process it later (see execution_table step 2).

How does the client know when the task is finished?

The client keeps polling the status URL until the server responds with status 'completed' and the result (see execution_table steps 4, 6).

What if the client stops polling too early?

Then the client won't get the final result because the task is still running (see execution_table step 4 shows 'processing').

Visual Quiz - 3 Questions

Look at the execution table, what status code does the server send immediately after receiving the start request?

A 200

B 202

C 404

D 500

💡 Hint

Check step 2 in the execution_table where the server responds to the start request.

At which step does the client receive the final result of the long-running task?

A Step 6

B Step 4

C Step 2

D Step 3

💡 Hint

Look for the step where the server responds with status 'completed' and the result in execution_table.

If the client stops polling after step 4, what will happen?

A Client gets the final result

B Server cancels the task

C Client never gets the final result

D Server sends an error

💡 Hint

See key_moments about polling and execution_table step 4 showing 'processing' status.

Concept Snapshot

Long-running operations use async responses.
Client sends request, server replies 202 Accepted immediately.
Server provides a status URL to check progress.
Client polls status URL until task completes.
Final result returned with 200 OK and data.
This avoids client waiting too long on one request.

Full Transcript

In long-running operations, the client sends a request to start a task. The server quickly replies with a 202 Accepted status and a Location header pointing to a status URL. The client then polls this URL repeatedly to check if the task is done. While the task runs, the server responds with status 'processing'. When finished, the server responds with status 'completed' and the final result. The client stops polling and uses the result. This approach prevents the client from waiting a long time on a single request and allows asynchronous processing.