निर्णय का आधार
एकीकरण दो कामकाज जोड़ता है, केवल endpoint नहीं। रिकॉर्ड, फ़ील्ड का अधिकार, प्रमाणीकरण, समय और रुकावट का जिम्मेदार तय करें। सफल अनुरोध सिर्फ छोटा हिस्सा जाँचता है।
एक व्यावहारिक उदाहरण
काल्पनिक शिपिंग में ऑर्डर, पता सुधार, भेजना और रद्द करना देखें। अंदर और कैरियर की ID जोड़ें। लेबल बने पर उत्तर खो जाए तो क्या होगा? अंधा पुनः प्रयास दूसरा शिपमेंट बना सकता है।
विकल्पों का आकलन
सीधी कॉल तत्काल उत्तर, स्थायी कतार बाद का काम और निर्धारित मिलान गायब रिकॉर्ड के लिए है। स्पष्ट स्थिति के साथ तीनों मिल सकते हैं।
योजना कहाँ टूटती है
विक्रेता फ़ील्ड अलग मैपिंग में रखें और इनपुट जाँचें। अस्थायी विफलता और गलत पता अलग करें; खराब डेटा दोहराना सुधार नहीं।
रिकॉर्ड का अनुबंध व्यापार की भाषा में लिखें
शिपिंग में प्रतीक्षा, कैरियर द्वारा स्वीकार, भेजा गया, रद्द और ध्यान चाहिए जैसी स्थितियाँ बताएँ। साझा पहचान और अनुमत बदलाव तय करें। नेटवर्क जवाब केवल प्राप्ति बता सकता है; व्यावसायिक पुष्टि बाद में आ सकती है। हर सफल HTTP को पूरी शिपमेंट न मानें।
खाली फ़ील्ड, समय क्षेत्र, इकाई और वैकल्पिक मान लिखें। खाली निर्देश का अर्थ कोई निर्देश नहीं; फ़ील्ड न भेजने का अर्थ पुराना रखना हो सकता है। वास्तविक अनुबंध जाँचें। कुंजी बदलना, सीमाएँ, संस्करण और टेस्ट वातावरण पूछें। अपुष्ट जवाब खुली निर्भरता रहें, निश्चित डिलिवरी तारीख नहीं।
टूटे हस्तांतरण की बहाली का जिम्मेदार रखें
लेबल बन जाए लेकिन जवाब खो जाए तो समर्थित idempotency या अपने संदर्भ से खोज मदद कर सकती है। दोनों न हों तो दूसरी शिपमेंट बनाने के बजाय मामला जाँच में रोकें। स्थानीय नकली सेवा या अधिकृत sandbox उपयोग करें, असली ग्राहक ऑर्डर नहीं।
निजी संचालन साधन विफल संदर्भ, सुरक्षित त्रुटि और अंतिम पुष्ट स्थिति दिखाए। दोबारा प्रक्रिया वही तार्किक पहचान और पहली जैसी जाँच रखे। खाते, मैपिंग बदलाव और रोज के अपवाद के मालिक तय करें। संस्करण वाले उदाहरण और contract test प्रदाता बदलाव पकड़ते हैं, पर नए व्यावसायिक अर्थ पर जिम्मेदार व्यक्ति निर्णय लेता है।
काम शुरू कराने से पहले
खाता किसका है? प्रतिनिधि परीक्षण है? ऑपरेटर एक विफल रिकॉर्ड खोजकर सुरक्षित दोहरा सकता है? एकीकरण साझेदार से सफलता और विफलता स्वीकृति तय करें।