உங்கள் செயலியை முடக்கும் 9 API மாற்றங்கள்
"நாங்கள் எதையும் உடைக்கவில்லை. நாங்கள் பதிலைத் (response) தூய்மைப்படுத்தினோம்."
அந்த வார்த்தைகள் பெரும்பாலும் செயலி முடங்குவதற்கு (crashes) வழிவகுக்கும். ஒரு மொபைல் செயலி செயலிழந்துவிடும். ஒரு பார்ட்னர் ஒருங்கிணைப்பு (partner integration) தவறான தரவுகளைத் தரும். மற்றவர்கள் சார்ந்திருக்கும் தரவின் அமைப்பை (shape of data) நீங்கள் மாற்றிவிட்டீர்கள்.
ஆபத்தான மாற்றங்கள் பெரும்பாலும் ஒரு ஒழுங்குபடுத்தல் போலத் தோன்றும். அவை கோட் ரிவியூ (code reviews) மற்றும் சோதனைகளில் (tests) வெற்றி பெறும். ஆனால், நீங்கள் பார்க்க முடியாத கோடில் தான் பாதிப்பு ஏற்படும்.
பாதுகாப்பானது என்று தோன்றும், ஆனால் உண்மையில் பாதுகாப்பானது அல்லாத ஒன்பது மாற்றங்கள் இதோ.
புலங்களை மறுபெயரிடுதல் (Renaming fields) ஒருமைப்பாட்டிற்காக (consistency)
userId-ஐuser_id-ஆக மாற்றுவது கிளையண்டுகளைப் பாதிக்கும். மறுபெயரிடுதல் என்பது ஒரு நீக்கம் மற்றும் ஒரு சேர்க்கை ஆகும். அந்த நீக்கும் பகுதி பயனர்களைப் பாதிக்கும். பாதுகாப்பான வழி: புதிய புலத்தைச் சேர்க்கவும். பழைய புலத்தை அப்படியே வைத்திருக்கவும். அதைத் தற்காலிகமாகப் பயன்பாட்டிலிருந்து நீக்கவும் (Deprecate). நீண்ட காலத்திற்குப் பிறகு அதை நீக்கவும்.ஒரு புலத்தை விருப்பத்தேர்வாக (optional) மாற்றுதல் ஒரு புலம் முன்பு இருந்தது. இப்போது அது சில நேரங்களில்
null-ஆக இருக்கிறது. கிளையண்ட் கோட் அதைச் செயல்படுத்த முயலும்போது செயலி முடங்கும். பாதுகாப்பான வழி: "எப்போதும் இருக்கும்" என்பதை ஒரு வாக்குறுதியாகக் கருதவும். ஒரு புலம் விருப்பத்தேர்வாக மாறினால், புதிய பதிப்பைப் (version) பயன்படுத்தவும்.பயன்படுத்தப்படாத புலங்களை நீக்குதல் உங்கள் தரவை நுகர்வோர் (consumers) எவ்வாறு பயன்படுத்துகிறார்கள் என்பதை உங்களால் பார்க்க முடியாது. "பயன்படுத்தப்படவில்லை" என்பது நீங்கள் பயன்படுத்துவதில்லை என்பதைக் குறிக்கிறதே தவிர, மற்றவர்கள் பயன்படுத்துவதில்லை என்பதைக் குறிக்காது. பாதுகாப்பான வழி: எதையும் நீக்குவதற்கு முன், தயாரிப்புச் சூழலில் (production) புலப் பயன்பாட்டைக் கணக்கிடுங்கள்.
உள்ளீட்டு வகைகளைக் குறைத்தல் (Narrowing input types) ஒரு
string-ஐenum-ஆகவோ அல்லது ஒருnumber-ஐinteger-ஆகவோ மாற்றுவது கோரிக்கைகளை (requests) பாதிக்கும். உள்ளீட்டை விரிவுபடுத்துவது (Widening) பாதுகாப்பானது. ஆனால் அதைச் சுருக்குவது ஒரு பாதிப்பை ஏற்படுத்தும் மாற்றமாகும். பாதுகாப்பான வழி: நீங்கள் ஏற்றுக்கொள்ளும் உள்ளீடுகளைத் தளர்த்தவும் (loosen). இறுக்கமாக்க (tightening) புதிய பதிப்பு தேவை.இயல்பு மதிப்புகளை (default values) மாற்றுதல் ஒரு இயல்பு மதிப்பை
false-லிருந்துtrue-ஆக மாற்றுவது, பிழை ஏதுமின்றி நடத்தையை மாற்றும். இது அமைதியாக தர்க்கத்தை (logic) பாதிக்கும். பாதுகாப்பான வழி: இயல்பு மதிப்பு மாற்றத்தை ஒரு பாதிப்பை ஏற்படுத்தும் மாற்றமாகவே கருதவும்.கட்டாயப் புலங்களைச் சேர்த்தல் (Adding required fields)
tenantId-ஐச் சேர்த்து அதைத் கட்டாயமாக்குவது தற்போதுள்ள அனைத்து கிளையண்டுகளையும் பாதிக்கும். அவர்களுக்கு 400 பிழை (error) வரும். பாதுகாப்பான வழி: புதிய புலங்கள் விருப்பத்தேர்வாக (optional) இருக்க வேண்டும் அல்லது புதிய பதிப்பைப் பயன்படுத்த வேண்டும்.பிழை வடிவங்களை (error formats) மாற்றுதல் 400-ஐ 422-ஆக மாற்றுவது அல்லது பிழைப் பகுதியை (error body) மாற்றுவது பிழை கையாளுதல் (error handling) கோடைப் பாதிக்கும். பாதுகாப்பான வழி: பிழை வடிவங்கள் என்பவை ஒப்பந்தங்கள் (contracts). மற்றவற்றைப் போலவே இதற்கும் பதிப்புகளைப் பயன்படுத்தவும்.
enum மதிப்புகளை மாற்றுதல் "active"-ஐ "ACTIVE"-ஆக மறுபெயரிடுவது கிளையண்டுகளைப் பாதிக்கும். ஒரு மதிப்பை நீக்குவது கடுமையான தர்க்கத்தைக் (strict logic) கொண்ட கிளையண்டுகளைப் பாதிக்கும். பாதுகாப்பான வழி:
enumமதிப்புகள் நிரந்தரமானவை. அவற்றை கவனமாகச் சேர்க்கவும். ஒரு முக்கிய பதிப்பு (major version) இல்லாமல் அவற்றை ஒருபோதும் மறுபெயரிடவோ அல்லது நீக்கவோ வேண்டாம்.தரவின் பொருளை மாற்றுதல் தேதியை Unix வினாடிகளிலிருந்து ISO-8601-க்கு மாற்றுவது அல்லது பக்கப் பிரிவை (pagination)
offset-லிருந்துcursor-க்கு மாற்றுவது அனைத்தையும் பாதிக்கும். ஒரு ஸ்கீமா வேறுபாடு (schema diff) கூட இதைக் கண்டறியாமல் போகலாம். பாதுகாப்பான வழி: வடிவங்களை (formats) வெளிப்படையாகக் குறிப்பிடவும். விவரக்குறிப்பை (spec) மட்டும் பார்க்காமல், உண்மையான தரவுப் பகுதிகளை (payloads) ஒப்பிட்டுப் பார்க்கவும்.
உணர்வுகளை மட்டும் நம்பிவிடாதீர்கள். உங்கள் CI-இல் ஒவ்வொரு மாற்றத்தையும் production contract உடன் ஒப்பிட்டுப் பாருங்கள். பெயர் மாற்றப்பட்ட ஒரு field-ஐ ஒரு மனிதன் கவனிக்கத் தவறலாம். ஆனால் ஒரு diff tool அதைத் தவறவிடாது.
மூலம்: https://dev.to/deepaksatyam/9-api-changes-that-look-backwards-compatible-but-arent-1bk0