৯টি API পরিবর্তন যা আপনার অ্যাপকে অচল করে দিতে পারে
"আমরা কিছুই ভেঙে ফেলিনি। আমরা শুধু রেসপন্সটি গুছিয়ে নিয়েছি।"
এই কথাগুলো প্রায়ই ক্র্যাশ বা অ্যাপ অচল হওয়ার কারণ হয়ে দাঁড়ায়। একটি মোবাইল অ্যাপ কাজ করা বন্ধ করে দেয়। একটি পার্টনার ইন্টিগ্রেশন ভুল বা অসংলগ্ন ডেটা প্রদান করে। আপনি এমন ডেটার কাঠামো পরিবর্তন করেছেন যার ওপর অন্যরা নির্ভরশীল।
বিপজ্জনক পরিবর্তনগুলো প্রায়ই গোছানোর মতো মনে হয়। এগুলো কোড রিভিউ এবং টেস্টে সফলভাবে পাস করে। কিন্তু সমস্যা বা ভাঙন ঘটে এমন কোডে যা আপনি দেখতে পান না।
এখানে এমন নয়টি পরিবর্তনের কথা বলা হলো যা নিরাপদ মনে হলেও আসলে তা নয়।
Renaming fields সামঞ্জস্য বজায় রাখতে
userId-কেuser_id-তে পরিবর্তন করলে ক্লায়েন্ট সাইডে সমস্যা হয়। একটি নাম পরিবর্তন করা মানে হলো একটি ফিল্ড মুছে ফেলা এবং একটি নতুন ফিল্ড যোগ করা। ফিল্ডটি মুছে ফেলার অংশটিই ব্যবহারকারীদের সমস্যা তৈরি করে। Safe move: নতুন ফিল্ডটি যোগ করুন। পুরনোটি রেখে দিন। এটিকে deprecate করুন। অনেক পরে এটি সরিয়ে ফেলুন।Making a field optional একটি ফিল্ড আগে সবসময় থাকতো। এখন এটি মাঝে মাঝে
nullহতে পারে। ক্লায়েন্ট কোড যখন এটি প্রসেস করার চেষ্টা করে, তখন সেটি ক্র্যাশ করে। Safe move: "সবসময় উপস্থিত থাকবে" বিষয়টিকে একটি প্রতিশ্রুতি হিসেবে বিবেচনা করুন। যদি কোনো ফিল্ড অপশনাল হয়ে যায়, তবে একটি নতুন ভার্সন ব্যবহার করুন।Removing unused fields আপনার ব্যবহারকারীরা কীভাবে আপনার ডেটা ব্যবহার করছেন তা আপনি দেখতে পান না। "অব্যবহৃত" মানে কেবল এটি যে আপনি এটি ব্যবহার করছেন না। Safe move: কোনো কিছু সরানোর আগে প্রোডাকশনে ফিল্ডের ব্যবহার পরিমাপ করে নিন।
Narrowing input types একটি
string-কেenum-এ বা একটিnumber-কেinteger-এ পরিবর্তন করলে রিকোয়েস্টগুলো কাজ করা বন্ধ করে দেয়। ইনপুট টাইপ বড় করা (Widening) নিরাপদ। কিন্তু এটি সংকুচিত করা (Narrowing) একটি breaking change। Safe move: আপনি যে ইনপুট গ্রহণ করেন সেগুলোকে কেবল শিথিল (loosen) করুন। টাইট বা সংকুচিত করতে হলে নতুন ভার্সন প্রয়োজন।Changing default values ডিফল্ট ভ্যালু
falseথেকেtrue-তে পরিবর্তন করলে কোনো এরর ছাড়াই আচরণ বদলে যায়। এটি নিঃশব্দে লজিক বা যুক্তি নষ্ট করে দেয়। Safe move: ডিফল্ট ভ্যালুর পরিবর্তনকে একটি breaking change হিসেবে বিবেচনা করুন।Adding required fields
tenantIdযোগ করা এবং এটিকে রিকোয়ার্ড করা প্রতিটি বিদ্যমান ক্লায়েন্টকে অচল করে দেয়। তারা একটি 400 এরর পাবে। Safe move: নতুন ফিল্ড অবশ্যই অপশনাল হতে হবে অথবা একটি নতুন ভার্সন ব্যবহার করতে হবে।Changing error formats 400 এররকে 422-তে পরিবর্তন করা বা এরর বডি পরিবর্তন করা এরর হ্যান্ডলিং কোডকে অচল করে দেয়। Safe move: এরর ফরম্যাট হলো একটি চুক্তি (contract)। অন্য সবকিছুর মতো এগুলোকেও ভার্সন অনুযায়ী পরিবর্তন করুন।
Modifying enum values "active"-কে "ACTIVE"-তে পরিবর্তন করলে ক্লায়েন্ট সাইডে সমস্যা হয়। কোনো ভ্যালু সরিয়ে ফেললে কঠোর লজিক ব্যবহারকারী ক্লায়েন্টরা অচল হয়ে পড়ে। Safe move: Enum ভ্যালুগুলো চিরস্থায়ী। এগুলো সাবধানে যোগ করুন। একটি মেজর ভার্সন ছাড়া কখনোই এগুলো রিনেম বা রিমুভ করবেন না।
Changing data meaning তারিখকে Unix seconds থেকে ISO-8601-এ পরিবর্তন করা বা পেজিনেশন (pagination) offset থেকে cursor-এ পরিবর্তন করা সবকিছু অচল করে দেয়। একটি স্কিমা ডিফ (schema diff) হয়তো এগুলো ধরতেও পারবে না। Safe move: ফরম্যাটগুলো স্পষ্টভাবে নির্দিষ্ট (pin) করে দিন। শুধুমাত্র স্পেসিফিকেশন নয়, বরং আসল পেলোড (payload) তুলনা করুন।
অনুমানের ওপর নির্ভর করবেন না। আপনার CI-তে প্রতিটি পরিবর্তন প্রোডাকশন কন্ট্রাক্টের সাথে তুলনা করুন। একজন মানুষ হয়তো কোনো ফিল্ডের নাম পরিবর্তন করা বিষয়টি খেয়াল নাও করতে পারেন। একটি diff tool তা করবে না।
উৎস: https://dev.to/deepaksatyam/9-api-changes-that-look-backwards-compatible-but-arent-1bk0