API टेस्टिंग क्या है? REST API कैसे टेस्ट करें

API टेस्टिंग में क्या-क्या आता है

"API टेस्टिंग" एक गतिविधि नहीं बल्कि जाँचों का परिवार है। ज़्यादातर टीमें पहली तीन हर बदलाव पर और बाकी रिलीज़ से पहले चलाती हैं।

• फ़ंक्शनल टेस्टिंग — क्या हर एंडपॉइंट वैध इनपुट पर सही रिस्पॉन्स देता है? क्या POST रिकॉर्ड बनाता है, GET उसे लौटाता है, DELETE उसे हटाता है?
• वैलिडेशन और नेगेटिव टेस्टिंग — फ़ील्ड गायब हों, टाइप गलत हो, वैल्यू रेंज से बाहर हो, JSON बिगड़ा हो, टोकन एक्सपायर हो या रिक्वेस्ट बहुत बड़ी हो तो क्या होता है? API को साफ़ 4xx एरर देना चाहिए, कभी 500 नहीं।
• कॉन्ट्रैक्ट टेस्टिंग — क्या रिस्पॉन्स अब भी तय स्कीमा (OpenAPI, JSON Schema) से मेल खाता है? हटाए गए फ़ील्ड और बदले टाइप हर कंज़्यूमर को तोड़ते हैं।
• ऑथेंटिकेशन और ऑथराइज़ेशन — क्या प्रोटेक्टेड एंडपॉइंट अनाम रिक्वेस्ट (401) और गलत यूज़र या रोल की रिक्वेस्ट (403) को रिजेक्ट करते हैं?
• परफ़ॉर्मेंस — रिक्वेस्ट में कितना समय लगता है, पेलोड कितना बड़ा है, और कॉन्करेंट लोड में एंडपॉइंट कैसा व्यवहार करता है?
• सिक्योरिटी — हेडर, क्वेरी पैरामीटर और बॉडी में इंजेक्शन, रेट लिमिटिंग, और क्या एरर रिस्पॉन्स स्टैक ट्रेस या इंटरनल लीक करते हैं।

रिक्वेस्ट और रिस्पॉन्स की बनावट

हर HTTP एक्सचेंज के हिस्से एक जैसे होते हैं, और हर हिस्सा असर्ट करने लायक है।

• मेथड — GET पढ़ता है, POST बनाता है, PUT बदलता है, PATCH रिसोर्स का हिस्सा अपडेट करता है, DELETE हटाता है। गलत मेथड इस्तेमाल करना अपने आप में बग है।
• URL और क्वेरी स्ट्रिंग — रिसोर्स पाथ (/orders/42) और फ़िल्टर व पेजिंग (?status=paid&page=2)।
• रिक्वेस्ट हेडर — Content-Type सर्वर को बताता है आप क्या भेज रहे हैं, Accept आप क्या वापस चाहते हैं, Authorization आप कौन हैं।
• रिक्वेस्ट बॉडी — REST में आमतौर पर JSON; डॉक्यूमेंटेड स्कीमा से मेल खानी चाहिए।
• स्टेटस कोड — 2xx सफलता, 3xx रीडायरेक्ट, 4xx क्लाइंट की गलती, 5xx सर्वर फ़ेल। सटीक कोड मायने रखता है: 201 बनाया गया, 204 कोई कंटेंट नहीं, 400 ख़राब इनपुट, 404 नहीं मिला, 409 कॉन्फ़्लिक्ट, 422 वैलिडेशन एरर।
• रिस्पॉन्स हेडर — Content-Type, कैशिंग, रेट-लिमिट काउंटर, CORS और सिक्योरिटी हेडर।
• रिस्पॉन्स बॉडी — डेटा, या मशीन-रीडेबल कोड और इंसानी भाषा के मैसेज वाला एकसमान एरर ऑब्जेक्ट।

POST /api/v1/orders HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...

{"customerId": 7, "items": [{"sku": "A-100", "qty": 2}]}

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/v1/orders/9021

{"id": 9021, "status": "pending", "total": 249.90}

आज़माएँ: API रिक्वेस्ट बिल्डर

REST API स्टेप-बाय-स्टेप कैसे टेस्ट करें

• पहले कॉन्ट्रैक्ट पढ़ें। OpenAPI/Swagger डॉक्यूमेंट या API डॉक्स खोलें और हर एंडपॉइंट, उसके पैरामीटर, सक्सेस रिस्पॉन्स और हर डॉक्यूमेंटेड एरर की लिस्ट बनाएँ।
• हैप्पी पाथ भेजें। हर एंडपॉइंट पर एक वैध रिक्वेस्ट भेजें और स्टेटस कोड, रिस्पॉन्स स्कीमा और मुख्य वैल्यू असर्ट करें। रिस्पॉन्स सेव करें — यही आपकी बेसलाइन है।
• जानबूझकर इनपुट तोड़ें। ज़रूरी फ़ील्ड हटाएँ, गलत टाइप भेजें, लंबाई पार करें, बाउंड्री वैल्यू (0, -1, अधिकतम + 1) दें, खाली और बहुत बड़ी बॉडी भेजें, और बिगड़ा JSON भेजें। सटीक 4xx कोड और समस्या का नाम लेने वाले एरर मैसेज की उम्मीद करें।
• ऑथेंटिकेशन टेस्ट करें। प्रोटेक्टेड एंडपॉइंट को बिना टोकन, एक्सपायर्ड टोकन, दूसरे यूज़र के टोकन और गलत स्कोप वाले टोकन से कॉल करें। 401 या 403 की उम्मीद करें, डेटा की कभी नहीं।
• स्टेट बदलाव जाँचें। POST के बाद रिसोर्स GET करके पुष्टि करें कि वह मौजूद है; DELETE के बाद पुष्टि करें कि वह चला गया; PUT के बाद पुष्टि करें कि हर फ़ील्ड बदला और कुछ और नहीं बदला।
• सिर्फ़ बॉडी नहीं, हेडर पर भी असर्ट करें। Content-Type application/json होना चाहिए, प्राइवेट डेटा के लिए कैशिंग सही हो, ब्राउज़र क्लाइंट के लिए CORS सही हो।
• मापें। हर कॉल का रिस्पॉन्स टाइम रिकॉर्ड करें; रिलीज़ के बीच ऊपर जाता कोई भी टाइम रिग्रेशन है, भले ही वह अब भी "काम" करे।
• जो दोहराया, उसे ऑटोमेट करें। रिक्वेस्ट और असर्शन को कलेक्शन या स्क्रिप्ट में बदलें ताकि वे हर बिल्ड पर चलें।

आज़माएँ: REST API टेस्टर आज़माएँ: API एंडपॉइंट टेस्टर आज़माएँ: API ऑथेंटिकेशन टेस्टर

हर रिस्पॉन्स में क्या असर्ट करें

• स्टेटस कोड ठीक वही है जो डॉक्यूमेंटेड है।
• Content-Type हेडर सही है और बॉडी पार्स होती है।
• बॉडी स्कीमा से मेल खाती है: ज़रूरी फ़ील्ड मौजूद, टाइप सही, सख़्त कॉन्ट्रैक्ट में कोई अनपेक्षित फ़ील्ड नहीं।
• वैल्यू सही हैं: ID, टोटल, ISO 8601 में तारीख़ें, अनुमत सेट के भीतर enumeration।
• एरर एकसमान हैं: हर एंडपॉइंट पर एक ही शेप, स्थिर मशीन कोड, मैसेज में कोई स्टैक ट्रेस या SQL नहीं।
• रिस्पॉन्स टाइम तय बजट के भीतर है।

आज़माएँ: API रिस्पॉन्स वैलिडेटर आज़माएँ: API स्कीमा वैलिडेटर

सबसे ज़्यादा दिखने वाली गलतियाँ

• बॉडी के अंदर एरर के साथ 200 OK — क्लाइंट टेक्स्ट पार्स किए बिना सफलता और विफलता में फ़र्क़ नहीं कर सकते।
• ख़राब इनपुट पर 400/422 की जगह 500 — वैलिडेशन लेयर गायब है या क्रैश होती है।
• अलग-अलग एंडपॉइंट पर अलग-अलग एरर शेप — हर कंज़्यूमर को कस्टम हैंडलिंग चाहिए।
• चुपचाप कॉन्ट्रैक्ट बदलना — बिना वर्ज़न बढ़ाए फ़ील्ड का नाम या टाइप बदल देना।
• ऑथराइज़ेशन चेक गायब — टोकन वैध है लेकिन ऐसे यूज़र का है जिसे रिसोर्स नहीं दिखना चाहिए।
• असंगत पेजिनेशन — पेज साइज़, ऑफ़सेट और टोटल एंडपॉइंट के बीच मेल नहीं खाते।
• टाइम ज़ोन बग — बिना ऑफ़सेट के टाइमस्टैम्प, या एक दिन खिसक जाने वाली तारीख़ें।

आज़माएँ: API स्टेटस कोड सिम्युलेटर आज़माएँ: रिस्पॉन्स कॉन्ट्रैक्ट कम्पेरेटर

Webhook और कॉलबैक टेस्ट करना

Webhook दिशा उलट देते हैं: API आपको कॉल करता है। इसे टेस्ट करने के लिए आपको ऐसा URL चाहिए जो कॉल स्वीकार करे और ठीक-ठीक दिखाए कि क्या आया — हेडर, सिग्नेचर, बॉडी और टाइमिंग — ताकि आप हैंडलर कोड की एक लाइन लिखने से पहले पेलोड को डॉक्यूमेंटेशन से जाँच सकें और शेयर्ड सीक्रेट से सिग्नेचर वेरिफ़ाई कर सकें।

आज़माएँ: Webhook टेस्टर आज़माएँ: Webhook सिग्नेचर एनालाइज़र

API टेस्टिंग टूल्स: डेस्कटॉप ऐप बनाम ब्राउज़र टूल्स

Postman, Insomnia और Bruno बड़े, लंबे समय तक चलने वाले कलेक्शन के लिए बेहतरीन हैं। रोज़ के काम के लिए — एंडपॉइंट चेक करना, बग रिप्रोड्यूस करना, रिस्पॉन्स वैलिडेट करना, webhook कैप्चर करना — ब्राउज़र टूल तेज़ है क्योंकि कुछ इंस्टॉल या साइन-इन नहीं करना पड़ता। Mutqan के API टूल्स उसी रोज़ के लूप को कवर करते हैं: रिक्वेस्ट बनाना और भेजना, नियमों या स्कीमा से रिस्पॉन्स वैलिडेट करना, स्टेटस कोड सिम्युलेट करना, webhook कैप्चर करना और सीधे OpenAPI फ़ाइल से टेस्ट केस बनाना।

आज़माएँ: OpenAPI → टेस्ट केस आज़माएँ: रिस्पॉन्स टाइम एनालाइज़र

अक्सर पूछे जाने वाले सवाल