انتقال تجربیات در حوزه برنامه نویسی دات نت

۲ مطلب با کلمه‌ی کلیدی «RESTful در وب سرویس» ثبت شده است

رعایت Backward Compatibility در سرویس ها

شاید اولین تصویری که با جستجوی کلمه 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 استفاده کنید. 

۰۶ تیر ۹۹ ، ۱۴:۵۲ ۱ نظر موافقین ۱ مخالفین ۰
احسان احسانی اطهر

مفهوم RESTful در Web API 2

قبل از اینکه به توضیح این قسمت بپردازم لازم میدونم که دو مفهوم رو توضیح بدم : Loosely Coupled و Tightly Coupled

تفاوت Loosely Coupled و Tightly Coupled

1- Loosely-Coupled به معنای اتصال و وابستگی ضعیف دلالت دارد. یعنی Client به Server وابستگی ضعیفی دارد و با حداقل دانش از نیازمندی های سرور میتواند با سرور کار کند. (در ادامه مثال را بررسی کنید.)

2- Tightly-Coupled به معنای اتصال و وابستگی قوی میباشد. و کلاینت جهت کار با سرور باید اطلاعات زیادی از سرور داشته باشد.

یک مثال ساده در دنیای واقعی از اتصال ضعیف رو میتونید در مادربرد تصور کنید، که شکاف های اتصال RAM به صورت Loosely Coupled تعبیه شده است و کاربر به راحتی میتواند RAM مادربرد خود را تعویض کند اما مثلا خازن ها به صورت اتصال قوی یا همان Tightly Coupled طراحی شده است و کاربر نهایی به راحتی نمیتوان آن ها را تعویض کند.

حال فرض کنید اگر تمامی قطعات در مادربرد به صورت اتصال قوی ساخته میشد برای تعویض RAM,CPU,Graphic Card و سایر قطعات میبایست کل مادربرد تعویض گردد.

ادامه مطلب...
۲۴ ارديبهشت ۹۶ ، ۱۱:۴۵ ۰ نظر موافقین ۰ مخالفین ۰
احسان احسانی اطهر