वर्णन और पालन अलग करें
उपकरणों द्वारा समर्थित विनिर्देश संस्करण तय करें। पैरामीटर, बॉडी, उत्तर और सुरक्षा आवश्यकताएँ लिखें। एप्लिकेशन और गेटवे को घोषित नियम वास्तव में लागू करने होंगे।
| तत्व | क्या बताता है | अतिरिक्त जाँच |
|---|---|---|
| स्कीमा | संरचना और बाधाएँ | वास्तविक सत्यापन और व्यावसायिक नियम। |
| दर्ज उत्तर | अपेक्षित स्थिति और सामग्री | वास्तविक उत्तर का मेल। |
| सुरक्षा आवश्यकता | घोषित तरीका और अधिकार | हर ऑपरेशन का प्रभावी पहुँच नियंत्रण। |
| उदाहरण | एक समझाने वाला मामला | संगति, रहस्य रहित डेटा और सीमा मामले। |
साझा करने से पहले समीक्षा
- आवश्यक फ़ील्ड, प्रकार, सीमा, पृष्ठांकन, त्रुटि और प्रारूप जाँचें। स्कीमा-संगत काल्पनिक उदाहरण लें, रहस्य या ग्राहक डेटा नहीं।
- नियंत्रित वातावरण में विवरण और वास्तविक अनुरोध-उत्तर मिलाएँ। अनुपस्थित पहचान, अपर्याप्त अधिकार और खातों के अलगाव की जाँच करें।
- बाहरी संदर्भ और उन्हें पढ़ने वाले उपकरण जाँचें। सार्वजनिक विवरण साफ़ करें और निजी वातावरण व ऑपरेशन बचाएँ।
दस्तावेज़ बनाए रखें
बदलाव की तुलना करें और ज़िम्मेदार तय करें। बना हुआ क्लाइंट या उदाहरण संरचना में सही होकर भी व्यावसायिक नियम भूल सकता है। इंटरैक्टिव कंसोल को उचित वातावरण, सीमित अधिकार और स्थिति बदलने वाले ऑपरेशन के स्पष्ट संकेत चाहिए।
प्राथमिक स्रोत
OpenAPI की तुलना चल रही सर्विस से करें।
एक उपयोगी OpenAPI डिस्क्रिप्शन में फ़ेलियर रिस्पॉन्स, स्कीमा और उदाहरण शामिल होते हैं जिनका क्लाइंट असल में सामना करते हैं। जब डॉक्यूमेंट और API अलग-अलग होते हैं, तो एक इंटीग्रेशन डेमो पास कर सकता है और प्रोडक्शन में फ़ेल हो सकता है।
- डिस्क्रिप्शन के हिसाब से सक्सेस और एरर केस की तुलना करें।
- ऑप्शनल वैल्यू, पेजिनेशन और ऑपरेशन लिमिट को डॉक्यूमेंट करें।
- कॉन्ट्रैक्ट बदलने से पहले एक रिप्रेज़ेंटेटिव क्लाइंट को टेस्ट करें।
प्राथमिक स्रोत: IETF RFC 9457 — Problem Details for HTTP APIs. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
ZIP और TAR: निर्देशिका और संसाधन सीमा में निकालें
निकाली फ़ाइलों को प्रकाशित करने से पहले पथ, लिंक और वास्तविक विस्तार जाँचें।
- न्यूनतम अनुमति वाली नई गैर-सार्वजनिक निर्देशिका में निकालें। पूर्ण पथ, ऊपर जाने वाले पथ, अनावश्यक लिंक और विशेष फ़ाइलें अस्वीकार करें। वास्तविक समाधान किए लक्ष्य और नाम टकराव को लक्ष्य सिस्टम, अक्षर केस सहित, जाँचें। टेक्स्ट उपसर्ग अकेले सीमा साबित नहीं करता।
- लिखे बाइट, प्रविष्टि संख्या, गहराई, समय और प्रक्रिया संसाधन पर प्रति फ़ाइल और कुल सीमा रखें। केवल संपीड़ित या घोषित आकार न मानें। अनावश्यक नेस्टेड अभिलेख अस्वीकार करें; जरूरी हों तो सभी स्तर कुल बजट साझा करें। लाइब्रेरी और फ़िल्टर अद्यतन रखें।
- ../, पूर्ण पथ, लिंक, दोहराव और बजट अधिकता जाँचें। रुकावट में बैच प्रकाशित न हो और पुरानी फ़ाइल न बदले। प्रकार और सामग्री जाँचकर प्रकाशित करें; अलग निर्देशिका साफ करते समय लक्ष्य सत्यापित करें।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"compressed_mb": 2,
"expanded_mb": 600,
"aggregate_budget_mb": 100,
"first_files_valid": true,
"expected": "stop_on_actual_overrun_and_do_not_promote"
}अपेक्षित निर्णय
काल्पनिक उदाहरण: 2 MB संपीड़ित डेटा 600 MB बनता है और बजट 100 MB है। वास्तव में लिखे बाइट अधिक होते ही रोकें; पहली फ़ाइलें सही दिखें तब भी बैच प्रकाशित न करें।
Python — tarfile extraction filters and further verification
क्या छोटा अभिलेख या फ़िल्टर सुरक्षा देता है?
नहीं। बहुत विस्तार हो सकता है। संसाधन सीमाएँ, पथ नियम और निकाली फ़ाइलों का सत्यापन जोड़ें।
प्राथमिक स्रोत: Python — tarfile extraction filters and further verification. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
API त्रुटियाँ: प्रकार, स्थिति और प्रमाण
इस संस्करण में विस्तृत संदर्भ टिप्पणियाँ अंग्रेज़ी में उपलब्ध हैं।
Include errors in contract tests
A new type URI, removed extension or changed status may alter consumer behaviour. Failure examples are part of the contract alongside successful responses.
- Replay existing clients against representative refusals.
- Check tolerance of unknown extensions and localised text.
- Document migration of a problem identity and actually observed use.
Explore problem types and eight fictional responses →
IETF · M. Nottingham, E. Wilde, S. Dalal · RFC 9457 · July 2023 · obsoletes RFC 7807 · §3.1, §3.2, §4.2, §5