क्लाइंट की नज़र से समीक्षा
तालिका समीक्षा का आधार है, सार्वभौमिक गारंटी नहीं। नया फ़ील्ड कठोर रीडर को और नया एनम मान सभी मामलों को संभालने वाली शाखाओं को तोड़ सकता है। क्लाइंट, लाइब्रेरी और मान्यताओं की सूची बनाएँ।
| बदलाव | जाँचने का जोखिम | ज़रूरी प्रमाण |
|---|---|---|
| फ़ील्ड हटाना या नाम बदलना | पढ़ना असंभव | स्पष्ट माइग्रेशन और क्लाइंट परीक्षण। |
| वैकल्पिक फ़ील्ड जोड़ना | कठोर रीडर या नाम टकराव | मौजूदा उपभोक्ता परीक्षण। |
| उत्तर में नया एनम मान | अधूरी शाखा-प्रक्रिया | अज्ञात मान का तय व्यवहार। |
| डिफ़ॉल्ट बदलना | अलग व्यावसायिक परिणाम | बिना स्पष्ट मान वाले मामलों की तुलना। |
साथ चलने की योजना
- पुरानी और नई संरचना, डिफ़ॉल्ट, त्रुटि, पृष्ठांकन और अधिकार लिखें। प्रतिनिधि उपभोक्ता मामलों पर अनुबंध परीक्षण करें।
- संस्करण चयन स्पष्ट करें। सेवा संस्करण और OpenAPI दस्तावेज़ संस्करण अलग रखें; कैश और गेटवे जाँचें।
- समय-सारणी, माइग्रेशन मार्गदर्शन और संपर्क दें। उचित टेलीमेट्री से वास्तविक उपयोग देखें और डेटा-संगत वापसी तैयार करें।
अप्रचलन और बंद होना अलग हैं
Deprecation अप्रचलित संसाधन का संकेत है; Sunset अपेक्षित अनुपलब्धता का समय बता सकता है। हेडर क्लाइंट को स्थानांतरित नहीं करते। संस्करण हटाने से पहले शेष उपभोक्ता, दायित्व और पुनर्प्राप्ति जाँचें।
प्राथमिक स्रोत
- Google AIP-180 — Backwards compatibility [EN]
- IETF RFC 9745 — Deprecation [EN]
- IETF RFC 8594 — Sunset [EN]
कंज्यूमर पर असर के हिसाब से वर्शन
URL में कोई नंबर जोड़ने से मौजूदा क्लाइंट खुद सेव नहीं होते। बदला हुआ टाइप, एक्सपेक्टेड वैल्यू, बिहेवियर या एरर रिस्पॉन्स तब भी इनकम्पैटिबल हो सकता है, जब पाथ वही रहता है।
- एक्टिव क्लाइंट और ऑब्जर्व्ड इस्तेमाल की इन्वेंटरी।
- पुराने क्लाइंट वर्शन को नए कॉन्ट्रैक्ट के हिसाब से टेस्ट करें।
- एक कोएग्जिस्टेंस पीरियड पब्लिश करें और रिटायरमेंट से पहले इस्तेमाल को इंस्पेक्ट करें।
प्राथमिक स्रोत: IETF RFC 9457 — Problem Details for HTTP APIs. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
असमकालिक API काम
अनुरोध स्वीकार होने से काम पूरा होना साबित नहीं होता।
- खाता, कार्रवाई और पुनः उपयोग योग्य पहचान
- स्थिति, समय, अंतराल और समाप्ति
- उत्पाद, त्रुटि, रद्द करना और बचे प्रभाव
- एक अधिकृत काम और बाधा के बाद जाँचा परिणाम
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"job_id": "J-42",
"timeline": [
{
"elapsed_seconds": 0,
"http": 202,
"state": "pending"
},
{
"elapsed_seconds": 5,
"http": 200,
"state": "running"
},
{
"elapsed_seconds": 6,
"http": 200,
"state": "cancel_requested"
},
{
"elapsed_seconds": 7,
"http": 200,
"state": "succeeded"
}
]
}अपेक्षित निर्णय
स्थिति पढ़ते समय 200 मिलना प्रसंस्करण पूरा होने का प्रमाण नहीं है। रद्द करने के अनुरोध के बाद केवल पुष्ट परिणाम से निष्कर्ष निकालें।
रद्द करने का अनुरोध देर से पहुँचा
काल्पनिक उदाहरण: वही कार्य J-42, समय अनुरोध भेजने के बाद सेकंड में। स्थिति के नाम इस उदाहरण के अनुबंध के हैं; HTTP इन्हें निर्धारित नहीं करता।
| समय | उत्तर और स्थिति | प्रमाणित निष्कर्ष |
|---|---|---|
| +0 s | HTTP 202 · pending | प्रसंस्करण के लिए स्वीकार किया गया; अंतिम परिणाम की पुष्टि नहीं हुई। |
| +5 s | HTTP 200 · running | स्थिति पढ़ना सफल रहा; कार्य अभी चल रहा है। |
| +6 s | HTTP 200 · cancel_requested | रोकने का अनुरोध दर्ज हुआ; रद्द होने की पुष्टि बाकी है। |
| +7 s | HTTP 200 · succeeded | प्रसंस्करण पहले पूरा हुआ। पुष्ट सफलता दिखाएँ और प्रभाव जाँचें; रद्द होने का दावा न करें। |
क्या 202 भविष्य में काम पूरा होने का प्रमाण है?
नहीं। वह प्रक्रिया के लिए स्वीकृति बताता है, अंतिम परिणाम नहीं। कार्रवाई की स्थिति जाँचें।
प्राथमिक स्रोत: MDN — 202 Accepted. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
सॉफ्टवेयर अपडेट: हस्ताक्षरकर्ता का बदलाव जाँचें
तय करें कि हस्ताक्षरित आर्टिफैक्ट अभी भी स्वीकृत निर्माता, निर्माण प्रक्रिया और संस्करण से मेल खाता है।
- नए पैकेज की जाँच से पहले अनुमत निर्माता, कुंजी या प्रमाणपत्र पहचान, जारीकर्ता और निर्माण प्रक्रिया दर्ज करें। अपेक्षाएँ सॉफ्टवेयर और पहले से विश्वसनीय पुष्टि मार्ग से जोड़ें। जाँचा जा रहा आर्टिफैक्ट अकेले अपनी स्वीकृति नीति तय न करे।
- मिली फ़ाइल का डाइजेस्ट अटेस्टेशन के विषय से मिलाएँ। तय भरोसे की जड़ों से हस्ताक्षर सत्यापित करें, फिर पहचान, बिल्डर और पैरामीटर जाँचें। दूसरी पहचान का सही क्रिप्टोग्राफिक हस्ताक्षर सेवा की नीति पूरा नहीं करता।
- घोषित रोटेशन, अप्रत्याशित जारीकर्ता, गायब हस्ताक्षर और अलग फ़ाइल जाँचें। नई पहचान की पुष्टि न हो तो आर्टिफैक्ट रोके रखें। अनुमोदन और वापसी लिखें; हस्ताक्षर कमजोरी न होने का प्रमाण नहीं है।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"signature_valid": true,
"digest_matches": true,
"expected_signer": "approved-publisher",
"observed_signer": "different-publisher",
"expected": "hold_for_independent_confirmation"
}अपेक्षित निर्णय
काल्पनिक उदाहरण: डाइजेस्ट मिलता है और हस्ताक्षर वैध है, लेकिन देखा गया हस्ताक्षरकर्ता स्वीकृत पहचान से अलग है। स्वतंत्र पुष्टि तक स्थापना रोकी रहती है।
प्राथमिक स्रोत: SLSA v1.2 — Verifying artifacts. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
API अप्रचलन और समाप्ति
इस संस्करण में विस्तृत संदर्भ टिप्पणियाँ अंग्रेज़ी में उपलब्ध हैं।
Plan retirement beyond the version number
A published version does not say when consumers need to migrate. Connect deprecation announcements, retirement dates and existing-client tests.
- Distinguish Deprecation, Sunset and policy links.
- Check that Sunset does not precede Deprecation when both dates are provided.
- Measure remaining consumers and validate the replacement before cutover.
Compare deprecation and retirement announcements →
IETF · RFC 9745 · Deprecation · Standards Track · March 2025 · §2–5 · consulted 2026-10-23
IETF · RFC 8594 · Sunset · Informational · May 2019 · §3–5, §8 · consulted 2026-10-23