REST API چیست و چطور طراحی می‎شود؟

(REST (Representational State Transfer یا  RESTful API design برای استفاده از مزایای پروتکل‌های موجود طراحی‌شده است. از آنجا که REST تقریباً بر روی همه پروتکل‌ها استفاده می‌شود، هنگام استفاده بر روی API های وب، می‌تواند از مزایای HTTP بهره‌مند شود.

طراحی REST API در سال ۲۰۰۰ میلادی در رساله دکتری Roy Fielding ارائه شد. نکته قابل‌توجه آن در انعطاف‌پذیری فوق‌العاده‌اش است. از آنجا که داده‌ها با متدها و منابع گره نخورده‌اند، REST با پیاده‌سازی صحیح hypermedia توانایی مدیریت انواع فراخوانی‌ها، برگرداندن فرمت‌های داده‌ای مختلف و حتی تغییر ساختاری را نیز دارد.

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

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

درک طراحی REST API

از آنجا که بیشتر API ها ادعا می‌کنند RESTful هستند، اما نیازمندی‌ها و شروطی که دکتر Fielding مطرح کرده را ندارند. شش شرط کلیدی برای طراحی REST API وجود دارد که در زمان تعیین API برای پروژه‌تان باید از آن آگاهی داشته باشید.

سرویس‌گیرنده – سرویس‌دهنده

شرط سرویس‌گیرنده- سرویس‌دهنده بدین معناست که سرویس‌گیرنده و سرویس‌دهنده بایستی از یکدیگر جدا باشند و اجازه توسعه جداگانه و مستقل را داشته باشند. به‌عبارت‌دیگر، باید بتوانیم روی اپلیکیشن موبایل خود، بدون آنکه اثری روی ساختار داده یا طراحی پایگاه داده در سرویس‌دهنده داشته باشد، تغییراتی را اعمال کنیم. همچنین بدون تأثیر بر سرویس‌گیرنده موبایل، بتوانیم پایگاه داده را تغییر دهیم یا تغییراتی در اپلیکیشن سرویس‌دهنده اعمال کنیم. بدین ترتیب ارتباطات از هم جدا می‌شوند و به هر برنامه کاربردی اجازه رشد و مقیاس‌پذیری مستقل داده می‌شود و سازمان شما سریع‌تر و کارآمدتر رشد می‌کند

مستقل از موقعیت (Stateless)

هر REST API مستقل از موقعیت است، بدین معنی که فراخوانی‌ها مستقل از یکدیگر انجام می‌شود و هر فراخوانی شامل داده‌هایی است که برای اتمام موفق خودش به آن‌ها نیاز دارد. یک REST API نباید وابسته به داده ذخیره‌شده در سرویس‌دهنده یا نشست‌ها باشد تا تعیین کند که با یک فراخوانی چه شود بلکه باید وابسته به داده‌ای باشد که فراخوانی، خود آن را فراهم می‌کند. زمانی که فراخوانی‌ها انجام می‌شود، شناسایی اطلاعات در سرویس‌دهنده ذخیره نمی‌شود. در عوض هر فراخوانی داده خود را دارد همانند API key، access tiken، user ID و غیره. همچنین این مسئله با داشتن همه اطلاعات لازم برای فراخوانی به افزایش قابلیت اطمینان API ها کمک می‌کند تا اینکه وابسته به یک سری فراخوانی با سرویس‌دهنده باشد تا آبجکتی را بسازد که ممکن است منجر به شکست جزئی شود. در عوض برای کاهش نیازمندی‌های حافظه و هرچه مقیاس‌پذیرتر بودن برنامه کاربردی، یک RESTful API نیاز به ذخیره وضعیت در سرویس‌گیرنده دارد – نه در سرویس‌دهنده.

کش در Rest API

ازآنجاکه یک API مستقل از موقعیت می‌تواند سربار درخواست را با بار زیاد مدیریت فراخوانی‌های ورودی و خروجی افزایش دهد، یک API REST ساخته می‌شود تا منجر به ذخیره‌سازی داده قابل کش شود. بدین معنی که زمانی که داده قابل کش است، پاسخ باید نشان دهد که داده می‌تواند تا زمان مشخصی (زمان انقضا) ذخیره گردد یا در مواردی که به داده بلادرنگ نیاز داریم، دیگر نباید پاسخ در سرویس‌گیرنده کش شود. با فعال نمودن این شرط بحرانی، نه‌تنها تعداد تعاملات با API از طریق کاهش استفاده از سرویس‌دهنده داخلی به‌شدت کاهش می‌یابد بلکه ابزار لازم برای تهیه کارآمدترین و سریع‌ترین برنامه‌های کاربردی ممکن را در اختیار کاربران API شما قرار می‌دهد. به خاطر داشته باشید که کش کردن سمت سرویس‌گیرنده انجام می‌شود. ازآنجاکه شما ممکن است بتوانید برخی داده‌ها را در معماری خود کش کنید تا بیشترین کارایی را داشته باشید، تمایل به سمت آموزش سرویس‌گیرنده است که گونه کار را ادامه دهد و داده را موقتاً ذخیره کند یا خیر.

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

کلید تفکیک سرویس‌گیرنده از سرویس‌دهنده داشتن یک رابط کاربری یکنواخت است که بدون وابستگی سرویس‌ها، مدل‌ها و عملیات برنامه کاربردی به لایه API، به برنامه کاربردی اجازه تکامل مستقل می‌دهد. رابط کاربری یکنواخت به سرویس‌گیرنده اجازه می‌دهد تا مستقل از معماری بک‌اند (Backend) با یک‌زبان واحد با سرویس‌دهنده صحبت کند. این رابط کاربری ابزار ارتباطی استاندارد و ثابتی بین سرویس‌دهنده و سرویس‌گیرنده فراهم می‌کند، همانند استفاده از HTTP با منابع URI، CRUD(Create, Read, Update, Delete) و JSON.

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

همان‌طور که از اسم آن برمی‌آید، سیستم لایه‌ای سیستمی است که از چندلایه تشکیل‌شده است و هر لایه عملکرد و مسئولیت خاص خود را دارد. اگر فریمورک Model View Controller را در نظر بگیریم، هر لایه مسئولیت‌های مخصوص به خود را دارد Models شامل چگونگی تشکیل داده است، Controller بر عملیات ورودی تمرکز دارد و View روی خروجی تمرکز دارد. هر لایه مستقل است اما با دیگر لایه‌ها در تعامل است. در طراحی REST API همین قوانین حاکم است با لایه‌های مختلفی از معماری که برای ساخت یک سلسه‌مراتب با هم کار می‌کنند و به ساخت یک برنامه کاربردی مقیاس‌پذیرتر و ماژولارتر کمک می‌کنند.

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

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

درخواست کد از API

شاید ناشناخته‌ترین شرط و تنها شرط اختیاری، کد درخواستی است که به کدها یا برنامه‌های کاربردی کوچک اجازه می‌دهد که از طریق API منتقل‌شده و در برنامه کاربردی از آن‌ها استفاده شود. در اصل، برنامه کاربردی هوشمندی را می‌سازد که دیگر تنها به ساختار کد خود وابسته نیست. بااین‌وجود، شاید به دلیل اینکه زودتر از زمان خود ارائه شد، برای تطابق به عنوان Web API ها با مشکلاتی مواجه شد زیرا Web API ها از زبان‌های مختلفی استفاده می‌کردند و برای انتقال کد نگرانی‌ها و سؤالات امنیتی به وجود آمد. (به‌عنوان‌مثال دایرکتوری باید قابلیت نوشتن را دارا بود و فایروال باید به آنچه قبل از این آن‌ها را محدود کرده بود مجوز می‌داد)

این شروط همراه با یکدیگر تئوری Representational State Transfer یا REST را بهبود بخشیدند. اگر به گذشته نگاه کنید، خواهید دید که چگونه هرکدام از این شروط موفق یکی پس از دیگری می‌آیند و درنهایت یک رابط کاربری نسبتاً پیچیده اما قدرتمند و انعطاف‌پذیر را خلق می‌کنند؛ اما مهم‌تر از همه، این شروط طراحی را ابه همان روشی که ما به به صفحات مختلف در وب سایت دسترسی پیدا می‌کنیم انجام می‌دهد. یعنی API ای را می‌سازد که معماری‌اش به آن اشاره نکرده است اما با آنچه برمی‌گرداند و یک API- که ازنظر معماری مستقل از موقعیت است- وابسته به آنچه ارائه‌شده است موقعیت برنامه کاربردی را دیکته می‌کند.