लंबे चलने वाले Operations और Bulk Requests

Clients को socket पर इंतज़ार न कराएँ

जब काम में कुछ सेकंड से ज़्यादा लगे (video processing, बड़े exports, रिपोर्ट बनाना), तो अनुरोध स्वीकार करें, 202 Accepted के साथ status resource (/exports/exp_9) की ओर इशारा करता Location लौटाएँ, और client को उसे poll करने दें (pending, running, नतीजे के link के साथ succeeded, या problem के साथ failed) या पूरा होने पर webhook पाने दें। Polling के लिए Retry-After संकेत जोड़ें। Bulk ऑपरेशनों (500 items बनाना) के लिए अर्थ पहले तय करें: सब-या-कुछ-नहीं, या प्रति-item नतीजे (सफलताओं और विफलताओं की 207-शैली सूची), batch आकार सीमित करें, और हर item idempotent रखें। Bulk endpoints round trips घटाते हैं पर जटिलता जोड़ते हैं, इसलिए सिर्फ़ वहीं दें जहाँ clients को सचमुच चाहिए।

202 का प्रवाह

उदाहरण HTTP आदान-प्रदान; demo API में exports लागू नहीं हैं।

POST /v1/exports          {"report": "orders", "month": "2026-09"}
<- 202 Accepted
   Location: /v1/exports/exp_9
   Retry-After: 5

GET /v1/exports/exp_9
<- 200 {"id":"exp_9","status":"running","progress":0.4}

GET /v1/exports/exp_9      (later)
<- 200 {"id":"exp_9","status":"succeeded","download_url":"https://files.example.com/exp_9.csv"}

त्वरित जाँच: जिस अनुरोध को पूरा होने में मिनट लगेंगे उसके लिए API को क्या लौटाना चाहिए?

• मिनटों तक रुककर 200
• Status resource के Location के साथ 202 Accepted
• 204 और भूल जाना
• 401