AI API रिस्पॉन्स → संभावित समस्याएँ

AI बग विश्लेषण

API आउटपुट पर एक और नज़र — AI संरचना, वैल्यू और headers में दोष, security एक्सपोज़र तथा contract की गड़बड़ियाँ जाँचता है, और हर बात के साथ गंभीरता तथा सुझाया गया सुधार देता है।

गोपनीयता: मुफ़्त Mutqan खाता ज़रूरी है। नतीजा बनाने के लिए आपका इनपुट Mutqan AI सेवा को भेजा जाता है; prompt और नतीजे संग्रहित नहीं किए जाते — दैनिक सीमा के लिए सिर्फ़ आपके खाते की उपयोग गिनती रखी जाती है। AI टूल कैसे काम करते हैं

अच्छा API एरर रिस्पॉन्स कैसा दिखता है?

अच्छा API एरर सही स्टेटस कोड और एक सुसंगत, मशीन-रीडेबल बॉडी इस्तेमाल करता है। RFC 9457 (Problem Details) उस बॉडी को मानकीकृत करता है: एक type URI, छोटा title, status, मानव-पठनीय detail और instance पहचानकर्ता, application/problem+json में। यह कॉलर को बताता है कि क्या गलत हुआ और कैसे ठीक करें — बिना स्टैक ट्रेस, SQL या आंतरिक पाथ उजागर किए।

AI API रिस्पॉन्स → संभावित समस्याएँ कैसे इस्तेमाल करें

  1. response पेस्ट करें — status line, headers और body, या सिर्फ़ JSON।
  2. चाहें तो अपेक्षित contract (schema या विवरण) और वह request पेस्ट करें जिसका यह जवाब है।
  3. आउटपुट भाषा चुनें और «विश्लेषण करें» दबाएँ।
  4. Critical से नीचे की ओर समस्याएँ देखें; हर एक किसी JSON path की ओर इशारा करती है और समस्या दिखाने वाली वैल्यू उद्धृत करती है। CSV, Markdown या JSON में डाउनलोड करें।

AI API रिस्पॉन्स → संभावित समस्याएँ की खूबियाँ

  • असंगत टाइप, छूटे फ़ील्ड, ग़लत status semantics, लीक हुआ डेटा, ख़राब तारीख़ फ़ॉर्मेट, null संभालने के तरीक़े, naming और pagination की गड़बड़ियाँ पकड़ता है
  • हर समस्या के साथ JSON path और उद्धृत प्रमाण
  • तुलना के लिए वैकल्पिक expected contract
  • हेल्थ स्कोर के साथ "ठीक लग रहा है" सूची

AI API रिस्पॉन्स → संभावित समस्याएँ का उदाहरण

Response समीक्षा

इनपुट:

{"data":[{"id":1,"passwordHash":"…"},{"id":"2","createdAt":"02/01/2026"}]}

आउटपुट:

ISS-1 data-exposure (Critical) $.data[0].passwordHash
ISS-2 inconsistent-type (High) $.data[*].id — number vs string
ISS-3 bad-date-format (Medium) $.data[1].createdAt

AI API रिस्पॉन्स → संभावित समस्याएँ के बारे में अक्सर पूछे जाने वाले सवाल

क्या मुझे headers भी शामिल करने चाहिए?

जब मुमकिन हो तो हाँ — status और headers से AI, body के अलावा status semantics, content type और caching भी जाँच पाता है।

अपेक्षित contract जोड़ने पर क्या होता है?

response की उससे तुलना होती है, और हर विचलन — छूटा फ़ील्ड, अलग प्रकार, अनपेक्षित status — एक समस्या के रूप में बताया जाता है।

गंभीरता कैसे तय होती है?

Critical डेटा का उजागर होना या बिगड़ना है, High ऐसी चीज़ जो clients को तोड़ देगी, Medium contract या गुणवत्ता की समस्या है, और Low दिखावटी।

तकनीकी नोट्स

हर समस्या में एक ID, प्रकार (inconsistent type, missing field, wrong status, data exposure, bad date format, null handling, naming, duplicate, encoding, pagination, error format, performance या other), गंभीरता, संबंधित JSON path, header या "status", सबूत वाली वैल्यू और सुझाया गया सुधार होता है। रिपोर्ट में 0–100 का health स्कोर और "ठीक लग रहा है" सूची जुड़ती है; जिस समस्या की ओर response में इशारा न किया जा सके, उसे नहीं बताया जाता।

संदर्भ

  • RFC 9457: Problem Details for HTTP APIsIETF · 2023मशीन-रीडेबल API एरर के लिए application/problem+json फ़ॉर्मेट (type, title, status, detail, instance)।
  • OWASP Cheat Sheet Series: Error HandlingOWASP Foundationऐसी एरर रिस्पॉन्स जो कॉलर की मदद करें पर स्टैक ट्रेस, वर्ज़न या आंतरिक पाथ लीक न करें।
  • RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।