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

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

"ہم نے کچھ بھی نہیں توڑا۔ ہم نے صرف رسپانس (response) کو بہتر بنایا ہے۔"

یہ الفاظ اکثر کریش (crash) کا باعث بنتے ہیں۔ ایک موبائل ایپ ناکام ہو جاتی ہے۔ ایک پارٹنر انٹیگریشن (integration) غلط ڈیٹا واپس کرتی ہے۔ آپ نے ڈیٹا کی اس شکل کو بدل دیا ہے جس پر دوسرے انحصار کرتے ہیں۔

خطرناک تبدیلیاں اکثر صفائی ستھرائی جیسی لگتی ہیں۔ وہ کوڈ ریویو اور ٹیسٹ میں پاس ہو جاتی ہیں۔ خرابی اس کوڈ میں ہوتی ہے جسے آپ دیکھ نہیں سکتے۔

یہاں نو ایسی تبدیلیاں ہیں جو محفوظ محسوس ہوتی ہیں لیکن ہوتی نہیں ہیں۔

• فیلڈز کا نام بدلنا تسلسل (consistency) کے لیے userId کو user_id میں بدلنا کلائنٹس کو توڑ دیتا ہے۔ نام بدلنا دراصل ایک ڈیلیٹ اور ایک ایڈ (add) ہے۔ ڈیلیٹ والا حصہ لوگوں کے کام خراب کر دیتا ہے۔ محفوظ طریقہ: نئی فیلڈ شامل کریں۔ پرانی والی کو برقرار رکھیں۔ اسے 'ڈیپرییکیٹ' (deprecate) کر دیں۔ بہت بعد میں اسے ہٹائیں۔

• کسی فیلڈ کو آپشنل (optional) بنانا ایک فیلڈ پہلے موجود ہوتی تھی۔ اب یہ کبھی کبھی null ہوتی ہے۔ جب کلائنٹ کوڈ اسے پروسیس کرنے کی کوشش کرتا ہے تو وہ کریش ہو جاتا ہے۔ محفوظ طریقہ: "ہمیشہ موجود رہنے" کو ایک وعدے کے طور پر لیں۔ اگر کوئی فیلڈ آپشنل ہو جائے، تو نیا ورژن استعمال کریں۔

• غیر استعمال شدہ فیلڈز کو ہٹانا آپ یہ نہیں دیکھ سکتے کہ آپ کے صارفین آپ کے ڈیٹا کو کیسے استعمال کرتے ہیں۔ "غیر استعمال شدہ" کا مطلب صرف یہ ہے کہ آپ اسے استعمال نہیں کر رہے۔ محفوظ طریقہ: کچھ بھی ہٹانے سے پہلے پروڈکشن (production) میں فیلڈ کے استعمال کی پیمائش کریں۔

• ان پٹ ٹائپس (input types) کو محدود کرنا ایک string کو enum میں یا ایک number کو integer میں بدلنا ریکویسٹس (requests) کو توڑ دیتا ہے۔ ان پٹ کو وسیع کرنا محفوظ ہے۔ اسے محدود کرنا ایک بریکنگ چینج (breaking change) ہے۔ محفوظ طریقہ: صرف ان ان پٹس کو ڈھیلا کریں جنہیں آپ قبول کرتے ہیں۔ اسے مزید سخت کرنے کے لیے نئے ورژن کی ضرورت ہوتی ہے۔

• ڈیفالٹ ویلیوز (default values) کو بدلنا ڈیفالٹ کو false سے true میں بدلنا بغیر کسی ایرر کے رویے کو بدل دیتا ہے۔ یہ خاموشی سے لاجک (logic) کو خراب کر دیتا ہے۔ محفوظ طریقہ: ڈیفالٹ کی تبدیلی کو ایک بریکنگ چینج کے طور پر لیں۔

• لازمی (required) فیلڈز کا اضافہ کرنا tenantId کا اضافہ کرنا اور اسے لازمی بنانا ہر موجودہ کلائنٹ کو توڑ دیتا ہے۔ انہیں 400 ایرر ملے گا۔ محفوظ طریقہ: نئی فیلڈز کو آپشنل ہونا چاہیے یا نیا ورژن استعمال کریں۔

• ایرر فارمیٹس (error formats) کو بدلنا 400 کو 422 میں بدلنا یا ایرر باڈی (error body) کو بدلنا ایرر ہینڈلنگ کوڈ کو توڑ دیتا ہے۔ محفوظ طریقہ: ایرر فارمیٹس معاہدے (contracts) ہوتے ہیں۔ انہیں بھی کسی بھی دوسری چیز کی طرح ورژن کریں۔

• انم (enum) ویلیوز میں ترمیم کرنا "active" کا نام بدل کر "ACTIVE" کرنا کلائنٹس کو توڑ دیتا ہے۔ کسی ویلیو کو ہٹانا سخت لاجک والے کلائنٹس کو توڑ دیتا ہے۔ محفوظ طریقہ: انم ویلیوز ہمیشہ کے لیے ہوتی ہیں۔ انہیں احتیاط سے شامل کریں۔ میجر ورژن (major version) کے بغیر انہیں کبھی نام نہ بدلیں اور نہ ہی ہٹائیں۔

• ڈیٹا کے معنی بدلنا تاریخ کو Unix seconds سے ISO-8601 میں بدلنا یا پیجینیشن (pagination) کو offset سے cursor میں بدلنا سب کچھ توڑ دیتا ہے۔ ایک اسکیما ڈِف (schema diff) شاید انہیں پکڑ بھی نہ سکے۔ محفوظ طریقہ: فارمیٹس کو واضح طور پر طے (pin) کریں۔ صرف اسپیسیفیکیشن (spec) کا نہیں بلکہ اصل پے لوڈز (payloads) کا موازنہ کریں۔

محض احساس پر بھروسہ نہ کریں۔ اپنے CI میں ہر تبدیلی کا موازنہ پروڈکشن کنٹریکٹ (production contract) سے کریں۔ ایک انسان کسی ری نیم شدہ فیلڈ (renamed field) کو نظر انداز کر سکتا ہے۔ ایک 'diff tool' ایسا نہیں کرے گا۔

ماخذ: https://dev.to/deepaksatyam/9-api-changes-that-look-backwards-compatible-but-arent-1bk0