How do you model a long-running operation in REST?
Assesses fundamental understanding of REST API Design conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Do not hold the connection open. Instead accept the work and return 202 Accepted with a pointer to a status resource.
POST /reports
Location: /reports/jobs/789
Retry-After: 5
HTTP/1.1 202 Accepted
{ "id": "789", "status": "running", "progress": 0.4 }
The client polls the job URL, or you notify it via a webhook or server-sent events. When finished, the status resource either includes the result or links to it, and the job may transition to succeeded or failed with error details. Store jobs durably so a server restart does not lose them, and let polling use conditional requests and Retry-After to reduce load.
Design for idempotency: a retried POST should return the same job rather than starting a second one. Also give jobs a retention policy so the status store does not grow without bound, and consider cancellation endpoints for user-initiated work.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.