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.

Practice

1. What is the main purpose of using long-running operations with async responses in REST APIs?

easy

A. To make the server process all requests instantly.

B. To let clients start a task and check its progress later without waiting.

C. To block the client until the task finishes.

D. To avoid using URLs for task status.

Solution

1. Step 1: Understand client-server interaction in async operations

   Clients start a task and receive a URL to check progress later, avoiding waiting.

2. Step 2: Identify the benefit of async responses

   This approach keeps apps responsive and user-friendly by not blocking clients.

3. Final Answer:

   To let clients start a task and check its progress later without waiting. -> Option B

4. Quick Check:

   Async responses = clients check progress later [OK]

Hint: Async means start task, check later URL [OK]

Common Mistakes:

• Thinking server processes all requests instantly
• Assuming client waits for task completion
• Ignoring the use of status URLs

2. Which HTTP status code is typically returned immediately by a REST API to indicate a long-running operation has started asynchronously?

easy

A. 200 OK

B. 404 Not Found

C. 202 Accepted

D. 500 Internal Server Error

Solution

1. Step 1: Recall HTTP status codes for async start

   202 Accepted means the request is accepted but processing is not complete yet.

2. Step 2: Compare with other codes

   200 OK means completed, 404 means missing resource, 500 means server error.

3. Final Answer:

   202 Accepted -> Option C

4. Quick Check:

   Async start = 202 Accepted [OK]

Hint: 202 means accepted but not done yet [OK]

Common Mistakes:

• Using 200 OK for async start
• Confusing 404 with async status
• Assuming 500 means task started

3. Given this REST API response after starting a long-running task:

{"status": "accepted", "status_url": "/tasks/123/status"}

What should the client do next to get the task result?

medium

A. Send a DELETE request to /tasks/123/status to cancel the task.

B. Send a POST request to /tasks/123/status to get the result.

C. Wait for the server to push the result automatically.

D. Send a GET request to /tasks/123/status to check progress.

Solution

1. Step 1: Identify the purpose of status_url

   The status_url is provided for the client to check the task progress or result.

2. Step 2: Determine correct HTTP method to check status

   GET requests are used to retrieve information, so client should GET the status URL.

3. Final Answer:

   Send a GET request to /tasks/123/status to check progress. -> Option D

4. Quick Check:

   Check progress = GET status URL [OK]

Hint: Use GET on status URL to check progress [OK]

Common Mistakes:

• Using POST instead of GET to check status
• Expecting server to push result without polling
• Using DELETE to check or cancel unintentionally

4. A developer wrote this code to start a long-running task and check its status:

response = start_task()
if response.status_code == 202:
    status_url = response.json()["status_url"]
    result = requests.post(status_url)
    print(result.json())

What is the error in this code?

medium

A. Using POST instead of GET to check the status URL.

B. Not checking if status_url exists in the response.

C. Not handling the case when status_code is not 202.

D. Printing result without parsing JSON.

Solution

1. Step 1: Review HTTP method used to check status

   The code uses POST to check status, but status URLs require GET requests.

2. Step 2: Confirm other parts of code

   Checking status_url existence and status_code handling are good practices but not the main error here.

3. Final Answer:

   Using POST instead of GET to check the status URL. -> Option A

4. Quick Check:

   Status check = GET, not POST [OK]

Hint: Status check always uses GET method [OK]

Common Mistakes:

• Using POST instead of GET for status check
• Ignoring missing status_url key
• Not handling unexpected status codes

5. You want to design a REST API endpoint for a long-running image processing task. Which approach best follows async response principles?

hard

A. Client POSTs image, server returns 202 Accepted with a status URL; client polls status URL until done.

B. Client POSTs image, server processes image immediately and returns 200 OK with result.

C. Client POSTs image, server returns 404 Not Found if task is slow.

D. Client POSTs image, server holds connection open until processing finishes.

Solution

1. Step 1: Understand async response design

   Server accepts task, returns 202 with status URL for client to poll progress.

2. Step 2: Evaluate other options

   Immediate processing (200 OK) blocks client; 404 is wrong status; holding connection open blocks client.

3. Final Answer:

   Client POSTs image, server returns 202 Accepted with a status URL; client polls status URL until done. -> Option A

4. Quick Check:

   Async design = 202 + status URL + polling [OK]

Hint: Async = 202 + status URL + client polls [OK]

Common Mistakes:

• Returning 200 OK immediately for slow tasks
• Using 404 for slow processing
• Keeping connection open until done