# लंबे चलने वाले Operations और Bulk Requests — API Design और Versioning

Source: https://www.geekswithgeeks.com/hi/api-design/rel-async-bulk

> 202 और status resource के साथ जल्दी लौटें और bulk endpoints जानबूझकर डिज़ाइन करें।

## 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 लागू नहीं हैं।

```text
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"}
```

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

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

*Answer:* Status resource के Location के साथ 202 Accepted. जल्दी स्वीकार करें और client को प्रगति अलग से देखने दें।