നിങ്ങളുടെ ആപ്പ് തകരാറിലാക്കുന്ന 9 API മാറ്റങ്ങൾ

"ഞങ്ങൾ ഒന്നും തകർത്തതല്ല. ഞങ്ങൾ റെസ്‌പോൺസ് (response) ഒന്ന് വൃത്തിയാക്കിയതാണ്."

ഈ വാക്കുകൾ പലപ്പോഴും ആപ്പുകൾ ക്രാഷ് ആകാൻ കാരണമാകുന്നു. ഒരു മൊബൈൽ ആപ്പ് പരാജയപ്പെടുന്നു. ഒരു പാർട്ണർ ഇന്റഗ്രേഷൻ തെറ്റായ വിവരങ്ങൾ (garbage) നൽകുന്നു. മറ്റുള്ളവർ ആശ്രയിക്കുന്ന ഡാറ്റയുടെ ഘടനയിൽ നിങ്ങൾ മാറ്റം വരുത്തിയിരിക്കുന്നു.

അപകടകരമായ മാറ്റങ്ങൾ പലപ്പോഴും ഒരു ക്രമീകരണം പോലെ തോന്നും. അവ കോഡ് റിവ്യൂകളിലും ടെസ്റ്റുകളിലും വിജയിച്ചേക്കാം. എന്നാൽ നിങ്ങൾ കാണാൻ കഴിയാത്ത കോഡുകളിലാണ് തകരാറുകൾ സംഭവിക്കുന്നത്.

സുരക്ഷിതമെന്ന് തോന്നുമെങ്കിലും യഥാർത്ഥത്തിൽ അല്ലാത്ത ഒൻപത് മാറ്റങ്ങൾ താഴെ പറയുന്നവയാണ്.

• ഫീൽഡുകൾ പുനർനാമകരണം ചെയ്യുക (Renaming fields) സ്ഥിരതയ്ക്കായി userId എന്നത് user_id എന്ന് മാറ്റുന്നത് ക്ലയന്റുകളെ ബാധിക്കും. ഒരു പേര് മാറ്റുക എന്നത് ഒരു ഡിലീറ്റും (delete) ഒരു അഡും (add) ആണ്. ആ ഡിലീറ്റ് ചെയ്യുന്ന ഭാഗമാണ് പ്രശ്നമുണ്ടാക്കുന്നത്. സുരക്ഷിതമായ വഴി: പുതിയ ഫീൽഡ് ചേർക്കുക. പഴയത് നിലനിർത്തുക. അത് 'deprecate' ചെയ്യുക. വളരെക്കാലത്തിന് ശേഷം മാത്രം നീക്കം ചെയ്യുക.

• ഒരു ഫീൽഡ് ഓപ്ഷണൽ (optional) ആക്കുക ഒരു ഫീൽഡ് മുമ്പ് അവിടെ ഉണ്ടായിരുന്നു. ഇപ്പോൾ അത് ചിലപ്പോൾ 'null' ആയിരിക്കാം. അത് പ്രോസസ്സ് ചെയ്യാൻ ശ്രമിക്കുമ്പോൾ ക്ലയന്റ് കോഡ് ക്രാഷ് ആകുന്നു. സുരക്ഷിതമായ വഴി: ഒരു ഫീൽഡ് "എപ്പോഴും ഉണ്ടാകണം" എന്നത് ഒരു വാഗ്ദാനമായി കാണുക. ഒരു ഫീൽഡ് ഓപ്ഷണൽ ആകുകയാണെങ്കിൽ, പുതിയ ഒരു വേർഷൻ ഉപയോഗിക്കുക.

• ഉപയോഗിക്കാത്ത ഫീൽഡുകൾ നീക്കം ചെയ്യുക നിങ്ങളുടെ ഉപഭോക്താക്കൾ ഡാറ്റ എങ്ങനെ ഉപയോഗിക്കുന്നു എന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയില്ല. "ഉപയോഗിക്കാത്തത്" എന്നാൽ നിങ്ങൾ ഉപയോഗിക്കുന്നില്ല എന്ന് മാത്രമേ അർത്ഥമുള്ളൂ. സുരക്ഷിതമായ വഴി: എന്തെങ്കിലും നീക്കം ചെയ്യുന്നതിന് മുമ്പ് പ്രൊഡക്ഷനിൽ (production) ഫീൽഡ് ഉപയോഗം അളക്കുക.

• ഇൻപുട്ട് ടൈപ്പുകൾ പരിമിതപ്പെടുത്തുക (Narrowing input types) ഒരു string-നെ enum ആയോ അല്ലെങ്കിൽ ഒരു number-നെ integer ആയോ മാറ്റുന്നത് റിക്വസ്റ്റുകളെ തകരാറിലാക്കും. ഇൻപുട്ടിന്റെ വ്യാപ്തി കൂട്ടുന്നത് (widening) സുരക്ഷിതമാണ്. എന്നാൽ അത് പരിമിതപ്പെടുത്തുന്നത് (narrowing) ഒരു ബ്രേക്കിംഗ് ചേഞ്ച് ആണ്. സുരക്ഷിതമായ വഴി: നിങ്ങൾ സ്വീകരിക്കുന്ന ഇൻപുട്ടുകൾ കൂടുതൽ ലളിതമാക്കുക (loosen) മാത്രം ചെയ്യുക. കൂടുതൽ കർശനമാക്കാൻ (tightening) പുതിയ വേർഷൻ ആവശ്യമാണ്.

• ഡിഫോൾട്ട് വാല്യൂകൾ (default values) മാറ്റുക ഒരു ഡിഫോൾട്ട് വാല്യൂ 'false'-ൽ നിന്ന് 'true' എന്നതിലേക്ക് മാറ്റുന്നത് ഒരു എറർ പോലും കാണിക്കാതെ പെരുമാറ്റത്തിൽ മാറ്റം വരുത്തും. ഇത് ലോജിക്കിനെ നിശബ്ദമായി തകരാറിലാക്കും. സുരക്ഷിതമായ വഴി: ഡിഫോൾട്ട് മാറ്റങ്ങളെ ഒരു ബ്രേക്കിംഗ് ചേഞ്ച് ആയി പരിഗണിക്കുക.

• നിർബന്ധിത ഫീൽഡുകൾ (required fields) ചേർക്കുക tenantId ചേർക്കുകയും അത് നിർബന്ധമാക്കുകയും ചെയ്യുന്നത് നിലവിലുള്ള എല്ലാ ക്ലയന്റുകളെയും ബാധിക്കും. അവർക്ക് 400 എറർ ലഭിക്കും. സുരക്ഷിതമായ വഴി: പുതിയ ഫീൽഡുകൾ ഓപ്ഷണൽ ആയിരിക്കണം അല്ലെങ്കിൽ പുതിയ വേർഷൻ ഉപയോഗിക്കണം.

• എറർ ഫോർമാറ്റുകൾ മാറ്റുക ഒരു 400 എററിനെ 422 ആക്കി മാറ്റുന്നതോ അല്ലെങ്കിൽ എറർ ബോഡി (error body) മാറ്റുന്നതോ എറർ ഹാൻഡ്‌ലിംഗ് കോഡിനെ തകരാറിലാക്കും. സുരക്ഷിതമായ വഴി: എറർ ഫോർമാറ്റുകൾ എന്നത് കരാറുകൾ (contracts) പോലെയാണ്. മറ്റുള്ളവയെപ്പോലെ തന്നെ അവയ്ക്കും വേർഷനുകൾ നൽകുക.

• enum വാല്യൂകൾ മാറ്റുക "active" എന്നത് "ACTIVE" എന്ന് മാറ്റുന്നത് ക്ലയന്റുകളെ ബാധിക്കും. ഒരു വാല്യൂ നീക്കം ചെയ്യുന്നത് കർശനമായ ലോജിക് ഉപയോഗിക്കുന്ന ക്ലയന്റുകളെ തകരാറിലാക്കും. സുരക്ഷിതമായ വഴി: Enum വാല്യൂകൾ ശാശ്വതമാണ്. അവ ശ്രദ്ധാപൂർവ്വം ചേർക്കുക. ഒരു മേജർ വേർഷൻ ഇല്ലാതെ അവയുടെ പേര് മാറ്റുകയോ നീക്കം ചെയ്യുകയോ ചെയ്യരുത്.

• ഡാറ്റയുടെ അർത്ഥം മാറ്റുക ഒരു ഡേറ്റ് (date) Unix seconds-ൽ നിന്ന് ISO-8601 ആക്കി മാറ്റുന്നതോ അല്ലെങ്കിൽ പേജിനേഷൻ (pagination) offset-ൽ നിന്ന് cursor ആക്കി മാറ്റുന്നതോ എല്ലാം തകരാറിലാക്കും. ഒരു സ്കീമ ഡിഫ് (schema diff) പോലും ഇവ കണ്ടെത്തണമെന്നില്ല. സുരക്ഷിതമായ വഴി: ഫോർമാറ്റുകൾ കൃത്യമായി നിശ്ചയിക്കുക (Pin formats). സ്പെസിഫിക്കേഷൻ (spec) മാത്രം നോക്കാതെ യഥാർത്ഥ പേലോഡുകൾ (payloads) താരതമ്യം ചെയ്യുക.

വെറും തോന്നലുകളെ മാത്രം ആശ്രയിക്കരുത്. നിങ്ങളുടെ CI-യിൽ ഓരോ മാറ്റവും പ്രൊഡക്ഷൻ കോൺട്രാക്റ്റുമായി താരതമ്യം ചെയ്യുക. പേര് മാറ്റപ്പെട്ട ഒരു ഫീൽഡ് ഒരു മനുഷ്യന് ശ്രദ്ധിക്കാതെ പോകാം, എന്നാൽ ഒരു ഡിഫ് ടൂളിന് അത് സംഭവിക്കില്ല.

സ്രോതസ്സ്: https://dev.to/deepaksatyam/9-api-changes-that-look-backwards-compatible-but-arent-1bk0