Long-running operations (async responses) in Rest API - Mini Project: Build & Apply

Handling Long-Running Operations with Async Responses in REST API

📖 Scenario: You are building a REST API that processes large files. Since processing takes time, the API should respond immediately with a job ID and let the client check the job status later.

🎯 Goal: Create a simple REST API that starts a long-running job asynchronously, returns a job ID immediately, and allows clients to check the job status with that ID.

📋 What You'll Learn

Create a dictionary called jobs to store job statuses

Create a variable called job_counter starting at 1

Write a function start_job() that adds a new job with status 'running' and returns the job ID

Write a function check_status(job_id) that returns the status of the job

Print the job ID after starting a job

Print the status of a job when checked

💡 Why This Matters

🌍 Real World

Many web services handle tasks that take time, like file uploads or data processing. They respond immediately with a job ID and let users check progress later.

💼 Career

Understanding async responses and job tracking is important for backend developers, API designers, and anyone building scalable web services.

1

Create the initial data structure

Create a dictionary called jobs to store job statuses and a variable called job_counter set to 1.

Rest API

# Create a dictionary called jobs and a variable job_counter set to 1
# Your code here

Hint

Use {} to create an empty dictionary and assign 1 to job_counter.

2

Add a function to start a job

Write a function called start_job() that uses the global job_counter, adds a new entry to jobs with status 'running', increments job_counter, and returns the job ID.

Rest API

jobs = {}
job_counter = 1

# Define start_job() function to add a new job with status 'running'
# Your code here

Hint

Remember to use global job_counter inside the function to modify it.

3

Add a function to check job status

Write a function called check_status(job_id) that returns the status of the job from the jobs dictionary using the given job_id. If the job ID is not found, return 'not found'.

Rest API

jobs = {}
job_counter = 1

def start_job():
    global job_counter
    job_id = job_counter
    jobs[job_id] = 'running'
    job_counter += 1
    return job_id

# Define check_status(job_id) function to return job status or 'not found'
# Your code here

Hint

Use the dictionary get() method to safely get the status or return 'not found'.

4

Start a job and print its status

Call start_job() and save the result in job_id. Then print the job ID with the message "Started job with ID: {job_id}". Next, call check_status(job_id) and print the status with the message "Status of job {job_id}: {status}".

Rest API

jobs = {}
job_counter = 1

def start_job():
    global job_counter
    job_id = job_counter
    jobs[job_id] = 'running'
    job_counter += 1
    return job_id

def check_status(job_id):
    return jobs.get(job_id, 'not found')

# Start a job, print the job ID, check the status, and print it
# Your code here

Hint

Use print() with f-strings to show the messages exactly as described.

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