شاید اولین تصویری که با جستجوی کلمه Backward Compatibility به آن برسید تصویر کنسولهای بازی باشد! اتفاقا این تصاویر به خوبی میتوانند توضیح دهند اصطلاح Backward Compatibility چیست: وقتی یک کنسول بازی جدید خریداری کردید اگر این کنسول با بازی های کنسول نسل قدیمی سازگاری داشته باشد (به عنوان مثال بتوان DVD های خریداری شده برای کنسول قدیمی را در کنسول نسل جدید استفاده کرد) آنگاه کنسول جدید ما Backward Compatible هست.

 

سرویس های Backward Compatible چیست؟

اگر سرویس های قدیمی ما همچنان بتوانند پس از انتشار سرویس های جدید به کار خود ادامه دهند و دچار مشکل نشوند آنگاه سرویس های ما Backward Compatible هستند.

به عنوان مثال : سرویس Orders سرویسی میباشد که لیستی از سفارش کاربران را به ما میدهد، بنا به دلایلی مجبور به تغییراتی در سرویس Order میباشیم در این تغییر جدید بازه زمانی از جنس تاریخ نیز میتواند به عنوان ورودی دریافت شود و اگر بازه زمانی دریافت شود آنگاه لیست سفارشات همان بازه زمانی برگشت داده میشود.

نکته: اگر پارامتر بازه زمانی فیلدی اجباری باشد چه اتفاقی خواهد افتاد؟ مشتریان جدید ما اگر متوجه این تغییرات شوند و برنامه خود را با توجه به آن توسعه دهند طبیعتا مشکلی بوجود نخواهد آمد اما نرم افزارهای و سرویس های قبلی که در حال استفاده از این سرویس بودند و اطلاعی از پارامتر جدید ندارند با خطا مواجه شده و دیگر نمیتوانند لیست سفارشات را دریافت کنند.

 

چرا باید سرویس های Backward Compatible داشت؟

شاید بتوان گفت مهمترین دلیل جلوگیری از بروز مشکل برای کاربران سرویس های قدیمی باشد.

 

راه حل ها

1- مطمئن باشیم تغییراتی که اعمال میکنیم باعث بروز خطا در سرویس های قبلی نشود مثلا:

Api/v2/orders : public List<orders> (optional int UserId)

 

فرض کنید سرویس بالا یک متد Get میباشد و با فراخوانی آن لیستی از سفارشات برمیگردد. مشاهده میکنید که پارامتر UserId به صورت Optional تعریف شده و اگر مقدار آن وارد شود آنگاه لیست سفارشات یک کاربر خاص نمایش داده میشود. 

اگر در ورژن جدید سرویس، به اشتباه این فیلد از اختیاری به اجباری تغییر کند آنگاه کاربرانی که از نسخه قدیمی استفاده میکنند به احتمال زیاد به مشکل خواهند خورد.

 

2- خروجی یک سرویس را تغییر ندهید. مثلا ممکن است فکر کنید اضافه کردن یک فیلد در یک فایل Json مشکلی بوجود نخواهد آورد اما شاید یک کاربر بر روی تعداد فیلدهای خروجی حساب باز کرده باشد! و یک عملیات خاصی را روی آنها انجام دهد.

 

3- از Version بر روی URI های خود استفاده کنید و ورژن های قدیمی را حفظ کنید. (و به مرور زمان کاربران را به سمت ورژنهای جدید سوق دهید). یکی از مزیت های این روش این است که دیگر نیاز ندارید Instanse های مختلف از برنامه خود را بالا نگه دارید و همه ورژن ها را در یک نسخه بالا نگه میدارید.

Api/v2/orders

Api/v3/orders 

 

4- از UnitTest استفاده کنید و مطمئن شوید تغییرات شما نسخه های قبلی را دچار مشکل نمیکند.

5- از قراردادهای اتوماتیک بر روی Pipleline های CI/CD استفاده کنید.