بررسی تفاوت‌های CRUD و REST

REST  و CRUD دو مفهوم اصلی در صنعت API هستند. در حالی که REST رایج‌ترین سبک طراحی برای API وب می‌باشد، CRUD  در برنامه‌های پایگاه داده کمک می‌کند. از آنجایی که سازمان‌ها از REST API استفاده می‌کنند، ذاتاً به معماری RESTful متکی هستند. با این حال، عملیات REST و CRUD شبیه یکدیگرند زیرا REST یک ابرمجموعه از CRUD هنگام اجرای روش‌های HTTP  است.

بر اساس طراحی،CRUD  یک چرخه است که می‌تواند به REST منتقل شود. همانطور که در زمینه CRUD بیان شد، ماندگاری یک رویکرد معقول برای برنامه‌های کاربردی جهت کاهش دستورالعمل‌های عملیاتی بین مشتریان و خدمات است. با این حال،REST  در چارچوب اصول معماری خود، چیزهای بسیار بیشتری از ماندگاری را مدیریت می‌کند.

این مقاله عملکرد REST و CRUD را شرح می‌دهد و شما را با درک اولیه CRUD در مقابل REST همراه با اصول اساسی آشنا می‌کند. این مقاله همچنین شباهت‌ها و تفاوت‌های بین REST و CRUD را مورد بحث قرار می‌دهد.

مقدمه‌ای بر REST

REST (مخفف REpresentational State Transfer)، یک سبک معماری محبوب است که برای توسعه API استفاده می‌شود. پایه و اساس REST در سال ۲۰۰۰ توسط دانشمند کامپیوتر دکتر روی فیلدینگ در پایان‌نامه دکترای او بیان شد. او همچنین اشاره کرد که REST سطح نسبتاً بالاتری از انعطاف‌پذیری و آزادی را برای توسعه‌دهندگان فراهم می‌کند.

از آنجایی که APIهای REST یک تکنیک انعطاف‌پذیر و سبک وزن برای یکپارچه‌سازی برنامه‌ها ارائه می‌کنند، این روش به عنوان پرکاربردترین روش برای اتصال اجزا در معماری‌های میکروسرویس ظاهر شده است.

۵ اصل کلیدی  REST

API، برنامه یا سرویس را قادر می‌سازد تا به منابع موجود در برنامه یا سرویس دیگر دسترسی پیدا کند. این مکانیسم از دو بخش تشکیل شده است: دسترسی به برنامه یا سرویس، “مشتری” و برنامه یا سرویس حاوی منابع، “سرور” نامیده می‌شود.

بر اساس برنامه، API ها توسط پروتکل‌های مختلفی مانند SOAP، XML-RPC  یا JSON-RPC تعریف می‌شوند که یک چارچوب سختگیرانه را به توسعه‌دهندگان تحمیل می‌کنند. با این حال، API های REST را می‌توان با استفاده از هر زبان برنامه‌نویسی توسعه داد، و از انواع فرمت‌های داده نیز پشتیبانی می‌کند. موارد زیر الزاماتی است که اصول طراحی REST را برآورده می‌کنند:

۱- بی‌تابعیتی

بی‌تابعیتی اصل راهنمای معماری REST است که دستورات ارائه‌شده بین مشتری و سرور را الزامی می‌سازد. “درخواست‌های بدون تابعیت” ارتباط بین مشتری و سرور را آغاز می‌کنند، جایی که هر درخواست باید شامل تمام اطلاعات لازم برای پردازش باشد.

۲- سیستم لایه‌ای

سیستم لایه‌ای، معماری REST را مقیاس‌پذیر می‌کند. از آنجایی که هیچ یک از لایه‌ها نمی‌توانند به لایه‌های دیگر بپردازند، تماس‌ها و پاسخ‌ها از لایه‌های مختلفی عبور می‌کنند. این اصل اجازه می‌دهد تا دستورات جدید بدون تأثیرگذاری بر دستورات قبلی و عملکرد آن‌ها اضافه شوند.

۳- سرویس جداشده

جداسازی مشتری-سرور ماهیت جدایی بین مشتری و سرور را نشان می‌دهد. در حالی که یک سرویس به درخواست‌ها گوش می‌دهد و قابلیت‌های متعددی دارد، هر درخواستی که توسط مصرف‌کنندگان ارائه شود توسط سرور پذیرفته یا رد می‌شود.

۴- رابط یکنواخت

معماری REST یک قرارداد یکسان را تعریف می‌کند و استفاده از رابط‌های چندگانه یا مستقل را درAPI  ممنوع می‌کند. مهم نیست که درخواست از کجا شروع می‌شود، همه API هایی که منبع مشابهی را درخواست می‌کنند باید شبیه به هم باشند.

۵- کش (Cache)

منابع باید در سمت سرویس‌گیرنده یا سرور قابل ذخیره‌سازی باشند زیرا به کاهش محدودیت‌های بی‌تابعیتی کمک می‌کنند. کش نه تنها عملکرد سمت مشتری را بهبود می‌بخشد، بلکه مقیاس‌پذیری را در سمت سرور نیز افزایش می‌دهد.

عملیات کلیدی در REST

دستورالعمل‌های REST استفاده از روش HTTP را پیشنهاد می‌کنند. در زیر پنج دستور برای انجام اقدامات لازم آورده شده است:

۱- HTTP GET: برای بازیابی اطلاعات/نمایش منابع بدون هیچ تغییری استفاده می‌گردد. از آنجایی که درخواست‌های «GET» وضعیت منبع را تغییر نمی‌دهند، روشی امن در نظر گرفته می‌شود. علاوه بر این، API های GET فاقد قدرت هستند زیرا نتایج یکسانی را ایجاد می‌کنند، حتی زمانی که چندین درخواست یکسان رخ می‌دهند. در ادامه چند مورد استفاده از HTTP GET API آورده شده است:

• اگر منبع در سرور یافت شود، باید کد پاسخ HTTP 200 (OK) را به همراه بدنه پاسخ برگرداند.
• اگر منبعی در سرور یافت نشد، باید کد پاسخ HTTP 404 را برگرداند (NOT FOUND).
• به طور مشابه، اگر مشخص شود که خود درخواست GET به درستی تشکیل نشده است، سرور کد پاسخ ۴۰۰ (BAD REQUEST) را برمی‌گرداند.

۲- HTTP POST: برای ایجاد زیرمنابع جدید در دایرکتوری موجود استفاده می‌شود. شرایط زیر در HTTP POST API وجود دارد:

• اگر منبع جدیدی در مجموعه منابع ایجاد شود، پاسخ باید کد پاسخ HTTP 201 باشد.
• اگر عمل انجام شده توسط روش POST منجر به ایجاد یک منبع جدید نشود، کد پاسخ HTTP 200 (OK) یا ۲۰۴ (No Content) وضعیت پاسخ است.

فرض کنید وظیفه اضافه کردن یک مشتری جدید به داده‌های مشتری موجود است، از دستور POST زیر استفاده کنید:

۳- HTTP PUT: در درجه اول برای به روز رسانی منابع موجود استفاده می‌شود. موارد زیر در HTTP PUT API وجود دارد:

• اگر منبع جدیدی ایجاد شده باشد، سرور مبدا باید با کد پاسخ HTTP 201 (Created) به کاربر اطلاع دهد.
• با این حال، اگر یک منبع موجود دستخوش اصلاح شود، کدهای پاسخ ۲۰۰ (OK) یا ۲۰۴ (No Content) برای نشان دادن تکمیل موفقیت‌آمیز درخواست ارسال می‌شوند.
• علاوه بر این، پاسخ‌های به روش PUT قابل کش نیستند. اگر درخواست از یک کش عبور کند و درخواست-URI یک یا چند موجودیت اخیراً ذخیره شده را شناسایی کند، چنین ورودی‌هایی را می‌توان قدیمی تلقی کرد.

اگر وظیفه به روز رسانی نام مشتری بود، از دستور زیر استفاده کنید:

۴- HTTP DELETE: این توابع عمدتاً به حذف منابع شناسایی شده توسط URI کمک می‌کنند. این عمل بی‌توان است. موارد زیر ممکن است رخ دهد:

• یک پاسخ حذف متوالی باید کد پاسخ HTTP 200 (OK) را برگرداند.
• اگر عمل در صف باشد، کد پاسخ ۲۰۲ (Accepted) خواهد بود.
• اگر عمل انجام شود، اما پاسخ شامل یک موجودیت نباشد، کد پاسخ ۲۰۴ (No Content) است.

به عنوان مثال اگر وظیفه شما حذف یک رکورد موجود است، از دستور زیر استفاده کنید:

۵- HTTP PATCH: این درخواست‌ها برای به روز رسانی جزئی منابع استفاده می‌شوند. اگرچه درخواست‌های PUT هویت منبع را تغییر می‌دهند، روش PATCH همچنان انتخاب صحیحی برای به‌روزرسانی جزئی یک منبع موجود است. روش PATCH جهانی نیست و ممکن است از همه مرورگرها، سرورها و برنامه های کاربردی وب پشتیبانی نکند.

REST همچنین شامل بسیاری از روش‌های HTTP دیگر مانند TRACE، CONNECT و OPTIONS است.

مقدمه‌ای بر CRUD

CRUD مخفف دستورات Create، Read، Update و Delete است. این چهار عملکرد اصلی راهنمای اولیه برای توسعه‌دهندگان نرم‌افزار هستند که با پایگاه‌های داده تعامل دارند.

عملیات CRUD به جای اینکه یک سیستم معماری باشد ماهیت چرخه‌ای دارد. برای هر وب سایت پویا، چرخه‌های CRUD متعددی وجود دارند. علیرغم منشأ آن از پایگاه‌های داده، اکنون اصل طراحی برنامه‌های کاربردی پویا مانند HTTP، SQL و DDS را ترسیم می‌کند.

۴ اصل کلیدی CRUD

در اینجا اصول CRUD آمده است:

• ایجاد (Create): رویه‌ای که رکوردهای جدیدی را از طریق عبارت «INSERT» تولید می‌کند.
• خواندن (Read): رویه‌ای که برای خواندن/بازیابی داده‌ها بر اساس پارامترهای ورودی مورد نظر استفاده می‌شود.
• به روز رسانی (Update): این روشی است که برای اصلاح رکوردها بدون بازنویسی آن‌ها استفاده می‌شود.
• حذف (Delete): رویه‌ای که برای حذف کامل یک یا چند ورودی استفاده می‌شود.

عملیات در CRUD

هر سازمانی که داده‌ها را ردیابی می‌کند به سیستمی نیاز دارد که ذخیره‌سازی سازمان‌یافته را در یک پایگاه داده فراهم نماید. یک پایگاه داده رابطه‌ای شامل داده‌هایی است که به طور سیستماتیک در ردیف‌ها و ستون‌ها مرتب شده‌اند. CRUD به چهار تابع پیاده‌سازی شده در پایگاه داده اشاره دارد که مخفف‌ها ایجاد، خواندن، به‌روزرسانی و حذف می‌کنند.

از آنجایی که پایگاه‌های داده رابطه‌ای یک لایه پایدار در برنامه‌های کاربردی نرم‌افزاری هستند، عملکردهای CRUD در SQL انجام می‌شوند و جدول زیر خلاصه‌ای از عملیات را نشان می‌دهد:

به طور مشابه، روش‌های HTTP همچنین دارای CRUD Mnemonic برای معناشناسی ذخیره‌سازی هستند. از آنجایی که CRUD عملیات اساسی را نشان می‌دهد، حداقل نیاز نرم‌افزار برای کاربران نهایی است.

CRUD در عملیات منابع انسانی

بخش منابع انسانی معمولاً سوابق پایگاه داده کارکنان موجود را برای مدیریت سوابق و رفاه کارکنان نگهداری می‌کند. چنین سوابقی عبارتند از جدول کارکنان با ویژگی‌هایی مانند شماره شناسایی کارمند، نام و نام خانوادگی، آدرس منزل، شماره تماس، محل کار و جزئیاتی از این دست.

جدول داده‌های منابع انسانی دارای ویژگی‌هایی مانند شناسه کارمند، اطلاعات حقوق و دستمزد کارمند، شماره تامین اجتماعی، حقوق و غیره می‌باشد.

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

هر زمان که استخدام جدیدی اتفاق می‌افتد، داد‌ه‌ها به سوابق در جداول مربوطه مانند جدول حقوق و دستمزد، جدول کارکنان و غیره اضافه می‌شوند. بخش منابع انسانی یک رکورد جدید ایجاد کرده و آن را به روز می‌کند تا تغییرات را منعکس نماید. هنگامی که شرکت نیاز به ارسال نامه دارد، به سادگی جدول کارکنان را می‌خواند تا جزئیات شخص مربوطه را انتخاب کند، یا زمانی که کارمند شرکت را ترک می‌کند، آن‌ها به سادگی باید عملیات حذف انجام دهند تا تغییر را با استفاده از عملیات CRUD منعکس کنند.

شباهت‌ها و تفاوت‌های  CRUD و REST

REST دارای یک معماری قوی می‌باشد که حول منابع و هایپر رسانه توسط پروتکل‌های HTTP متمرکز شده است. CRUD چرخه‌ای است که به منظور حفظ سوابق دائمی در سیستم‌های مدیریت پایگاه داده ایجاد می‌شود.

REST دارای پایه معماری RESTful است که از HTTP برای رابط وب پشتیبانی می‌کند، در حالی که CRUD را می‌توان به روش‌های DDS، SQL یا HTTP نگاشت. در حالی که اصول CRUD شباهت‌های قابل توجهی با REST دارند، باید توجه داشت که REST به عملیات CRUD محدود نمی‌شود بنابراین می‌توانیم درک بهتری از CRUD در مقابل REST داشته باشیم.

اگرچه CRUD را می‌توان از منظر طراحی به REST نگاشت، REST برای کاهش دستورات عملیات بین مشتری و خدمات، ماندگاری بیشتری نسبت به CRUD دارد. CRUD عملی است که برای نوشتن داده‌ها در پایگاه داده انجام می‌شود، در حالی که REST با هر شیء یا منبعی، از فایل رسانه، وب سایت گرفته تا سند، و سایر خدمات سازگار است.

پارامترهای انتخاب بین CRUD و REST

ویژگی‌های زیادی وجود دارد که عملیات CRUD و REST را در سازمان‌ها متفاوت می‌سازد. هنگامی که به برنامه‌نویسان حق انتخاب بین CRUD و REST داده می‌شود، آن‌ها CRUD را برای اجرای عملکردهای ضروری ذخیره‌سازی پایدار انتخاب می‌کنند. با این حال، در زیر چند پارامتر وجود دارد که REST را قابل اعتماد می‌سازد:

• مقیاس‌پذیری: معماری REST به رابط یکنواخت پایبند است و استفاده از چندین رابط را در یک API ممنوع می‌کند. این مکانیسم REST را مقیاس‌پذیر می‌کند.
• سادگی: REST بدون حالت است و مشتری و سرور را جدا می‌کند، یک درخواست حاوی تمام اطلاعات لازم است.
• دارای سیستم: REST با تعیین پاسخ‌های ارسال شده توسط سرور، از مکانیسم کش استفاده موثری می‌کند.

جمع‌بندی

وقتی از هر توسعه‌دهنده‌ای پرسیده می‌شود برای انجام عملیات‌های مرتبط با پایگاه داده در وب‌سایت‌ها یا برنامه‌ها بین CRUD و REST کدام را انتخاب می‌کند، CRUD معمولا ترجیح داده می‌شود. با این حال، به دلیل دامنه محدود توسعه قوی، سازمان‌ها بر معماری RESTful متکی هستند. نه تنها REST ویژگی‌های انحصاری مختلفی را ارائه می‌دهد که خدمات وب را مقیاس‌بندی می‌کند، بلکه با سادگی و کارایی بالا، معماری REST به طور گسترده برای ساخت API پذیرفته شده است.

این مقاله عملکرد REST و CRUD را شرح داده و سعی داشته است شما را با درک CRUD در مقابل REST همراه با اصول اساسی آشنا سازد.