প্রায় সবাই জানি Stripe-এর API অসাধারণ। কিন্তু জানেন কি কেন তারা traditional /v1, /v2 versioning ব্যবহার না করে, বরং date-based versioning ব্যবহার করে?
এটা মূলত Stripe-এর developer-friendly এবং stable API design-এর ঝলক।
Traditional Versioning-এর কিছু সীমাবদ্ধতা রয়েছে। উদাহরণস্বরূপ, যখন একটি API /v1/customers থেকে /v2/customers-এ আপডেট হয়, তখন সাধারণত endpoint structure, data format, এবং response shape-এর বড় পরিবর্তন আসে। এর ফলে existing integrations হঠাৎ ভেঙে যেতে পারে এবং developers-কে নতুন version-এ migrate করতে অনেক সময় ও effort দিতে হয়। এছাড়া, একাধিক version maintain করাও জটিল হয়ে যায়। অর্থাৎ, Traditional Versioning বড় পরিবর্তনের ক্ষেত্রে risk তৈরি করে এবং integration-কে কম stable রাখে।
Stripe-এর Date-Based Versioning হল এমন একটি পদ্ধতি যেখানে প্রতিটি API version একটি নির্দিষ্ট তারিখের সঙ্গে mark করা থাকে, যেমন 2025-09-30.clover. এতে করে প্রতিটি major বা monthly release সহজে track করা যায়।
Major release-এ বড় পরিবর্তন (যা backward-compatible নয়) আনা হয়, কিন্তু monthly release-এ শুধু backward-compatible ছোট পরিবর্তন আসে। এই পদ্ধতিতে, আপনার integration যেই version-এ pinned থাকে, তা নতুন update এলেও ভাঙবে না। Developer রা চাইলে পরবর্তীতে step-by-step নতুন version-এ safely migrate করতে পারেন।
Stripe internally প্রতিটি request handle করে compatibility layer দিয়ে।
Main codebase সর্বদা latest থাকে, কিন্তু পুরোনো version-এর জন্য response backward-compatible হয়।
Stripe-এর SDK যেমন stripe-node, stripe-python, release time-এর API version-এর সাথে pinned থাকে। ফলে Type mismatch বা API inconsistency-এর ঝুঁকি কমে যায়।
Webhook endpoint তৈরির সময় যেই version নির্বাচন করা হয়, সেই version-এর data format সবসময় ঠিক থাকে। নতুন update আসলেও আপনার webhook break হয় না।
সহজভাবে-
- Traditional versioning = একবারে big change, risk বেশি
- Date-based versioning = step by step small change, integration always stable
Stripe-এ এটি win-win.
Stripe-এর date-based versioning দেখায় কিভাবে innovation এবং stability একসাথে রাখা যায়। Integration সহজ, upgrades smooth, এবং system সবসময় reliable.
Top comments (0)