𝟵 𝗔𝗣𝗜 𝗖𝗵𝗮𝗻𝗴𝗲𝘀 𝗧𝗵𝗮𝘁 𝗕𝗿𝗲𝗮𝗸 𝗬𝗼𝘂𝗿 𝗔𝗽𝗽

𝟵 𝗔𝗣𝗜 𝗖𝗵𝗮𝗻𝗴𝗲𝘀 𝗧𝗵𝗮𝘁 𝗕𝗿𝗲𝗮𝗸 𝗬𝗼𝘂𝗿 𝗔𝗽𝗽

"आम्ही काहीही बिघडवले नाही. आम्ही फक्त रिस्पॉन्स (response) स्वच्छ केला आहे."

हे शब्द अनेकदा क्रॅशला कारणीभूत ठरतात. एखादे मोबाईल ॲप निकामी होते. पार्टनर इंटिग्रेशनमधून चुकीचा डेटा (garbage) मिळतो. तुम्ही अशा डेटाचे स्वरूप बदलले ज्यावर इतर अवलंबून आहेत.

धोकादायक बदल अनेकदा 'स्वच्छता' किंवा 'सुसूत्रीकरण' असल्यासारखे वाटतात. ते कोड रिव्ह्यू आणि टेस्टमध्ये यशस्वी होतात. पण खरा बिघाड अशा कोडमध्ये होतो जो तुम्हाला दिसत नाही.

येथे असे नऊ बदल दिले आहेत जे सुरक्षित वाटतात पण प्रत्यक्षात तसे नसतात.

• Renaming fields (फील्ड्सची नावे बदलणे) सुसंगततेसाठी userId चे रूपांतर user_id मध्ये केल्यास क्लायंट्सना समस्या येते. नाव बदलणे म्हणजे एक फील्ड डिलीट करणे आणि दुसरे नवीन जोडणे होय. डिलीट केल्यामुळे इतरांचे काम थांबते. Safe move: नवीन फील्ड जोडा. जुने फील्ड तसेच ठेवा. ते 'डिप्रेकेट' (deprecate) करा. खूप काळानंतर ते काढून टाका.

• Making a field optional (एखादे फील्ड 'ऑप्शनल' करणे) एखादे फील्ड आधी नेहमी उपलब्ध असायचे. आता ते कधीकधी null असते. जेव्हा क्लायंट कोड त्यावर प्रक्रिया करण्याचा प्रयत्न करतो, तेव्हा तो क्रॅश होतो. Safe move: "नेहमी उपलब्ध असणे" हे एक वचन (promise) समजा. जर एखादे फील्ड ऑप्शनल होणार असेल, तर नवीन व्हर्जन वापरा.

• Removing unused fields (न वापरली जाणारी फील्ड्स काढून टाकणे) तुमचे ग्राहक तुमचा डेटा कसा वापरतात हे तुम्हाला दिसत नाही. "न वापरलेले" याचा अर्थ फक्त एवढाच आहे की 'तुम्ही' ते वापरत नाही आहात. Safe move: काहीही काढून टाकण्यापूर्वी प्रोडक्शनमध्ये (production) त्या फील्डच्या वापराचे मोजमाप करा.

• Narrowing input types (इनपुट प्रकार मर्यादित करणे) string चे रूपांतर enum मध्ये किंवा number चे integer मध्ये केल्यास रिक्वेस्ट्समध्ये बिघाड होतो. इनपुटचा प्रकार वाढवणे (widening) सुरक्षित आहे, पण तो मर्यादित करणे (narrowing) हा एक 'ब्रेकिंग चेंज' आहे. Safe move: तुम्ही स्वीकारत असलेले इनपुट फक्त शिथिल (loosen) करा. ते अधिक कडक (tighten) करण्यासाठी नवीन व्हर्जन आवश्यक आहे.

• Changing default values (डिफॉल्ट व्हॅल्यूज बदलणे) डिफॉल्ट व्हॅल्यू false वरून true मध्ये बदलल्यास कोणताही एरर न येता वर्तणूक (behavior) बदलते. यामुळे लॉजिक शांतपणे बिघडते. Safe move: डिफॉल्टमधील बदलाला 'ब्रेकिंग चेंज' म्हणून समजा.

• Adding required fields (आवश्यक फील्ड्स जोडणे) tenantId जोडणे आणि ते अनिवार्य (required) करणे यामुळे सर्व विद्यमान क्लायंट्सना समस्या येते. त्यांना 400 एरर येईल. Safe move: नवीन फील्ड्स ऑप्शनल असावीत किंवा त्यासाठी नवीन व्हर्जन वापरावे.

• Changing error formats (एरर फॉरमॅट्स बदलणे) 400 एररचे रूपांतर 422 मध्ये करणे किंवा एरर बॉडी बदलणे यामुळे एरर हँडलिंग कोडमध्ये बिघाड होतो. Safe move: एरर फॉरमॅट्स हे करार (contracts) आहेत. इतर गोष्टींप्रमाणेच त्यांचेही व्हर्जनिंग करा.

• Modifying enum values (Enum व्हॅल्यूजमध्ये बदल करणे) "active" चे नाव बदलून "ACTIVE" केल्यास क्लायंट्सना समस्या येते. एखादी व्हॅल्यू काढून टाकल्यास कडक लॉजिक वापरणाऱ्या क्लायंट्सना अडथळा येतो. Safe move: Enum व्हॅल्यूज कायमस्वरूपी असतात. त्या काळजीपूर्वक जोडा. मेजर व्हर्जनशिवाय त्यांचे नाव कधीही बदलू नका किंवा त्यांना काढून टाकू नका.

• Changing data meaning (डेटाचा अर्थ बदलणे) तारीख Unix seconds वरून ISO-8601 मध्ये बदलणे किंवा पेजिनेशन (pagination) offset वरून cursor मध्ये बदलणे यामुळे सर्व काही बिघडते. स्कीमा डिफ (schema diff) कदाचित हे बदल पकडू शकणार नाही. Safe move: फॉरमॅट्स स्पष्टपणे निश्चित (pin) करा. केवळ स्पेसिफिकेशन (spec) न पाहता प्रत्यक्ष पेलोड्सची (payloads) तुलना करा.

केवळ भावनेवर अवलंबून राहू नका. तुमच्या CI मध्ये प्रत्येक बदलाची तुलना प्रोडक्शन कॉन्ट्रॅक्टशी करा. एखादी व्यक्ती नाव बदललेले फील्ड (renamed field) कदाचित दुर्लक्षित करू शकते. 'डिफ टूल' (diff tool) तसे करणार नाही.

स्रोत: https://dev.to/deepaksatyam/9-api-changes-that-look-backwards-compatible-but-arent-1bk0