RESTful API چیست و با SOAP چه تفاوتی دارد؟

معماری RESTful API در حقیقت یک رابط برنامه نویسی کاربردی (API) است که از درخواست های HTTP برای دریافت (GET)، ساخت (POST)، بروز رسانی (PUT) و حذف (DELETE) داده ها استفاده می کند. امروز قصد داریم با زبانی بسیار ساده معماری RESTful API را به شما توضیح دهیم، پس تا آخر این مطلب با ما همراه باشید.

RESTful API چیست؟

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

یک RESTful API مبتنی بر سبک معماری انتقال بازنمودی حالت (Representational State Transfer) یا همان REST است که معمولاً در حوزه ارتباط وب سرویس ها به کار گرفته می شود. تکنولوژی REST به طور کلی نسبت به پروتکل دسترسی آسان به اشیا (SOAP) برتری دارد چرا که پهنای باند کمتری مصرف کرده و برای استفاده در اینترنت گزینه مناسبی محسوب می شود.

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

نحوه کار RESTful API

معماری RESTful API ماژول های کوچکی از تجزیه یک تراکنش (Transaction) ایجاد می کند که هر ماژول به یک بخش خاصی از Transaction مربوط می شود. اگرچه این قابلیت ماژولار بودن انعطاف پذیری بسیاری را در اختیار برنامه نویسان قرار می دهد، اما این موضوع که باید REST API را از ابتدا طراحی کنند برای برنامه نویسان کار بسیار سختی محسوب می شود. البته امروزه کمپانی های معروف مدل های کاربردی نظیر Amazon S3، رابط مدیریت داده های فضای ابری (CDMI) و OpenStack Swift را برای طراحی در اختیار توسعه دهندگان قرار داده اند.

در حال حاضر RESTful API از متدهای HTTP تعریف شده در پروتکل RFC 2616 استفاده می کند. به عبارت دیگر RESTful API از متد GET برای بازیابی منابع، متدPUT برای بروز رسانی و تغییر وضعیت منابع، متد POST برای ساخت منابع و از متد DELETE برای حذف منابع استفاده می کند؛ منبع (Resource) می تواند یک آبجکت، فایل یا بلاک باشد.

با استفاده از REST، تمام مولفه های شبکه ای به عنوان یک منبع در دسترس کاربران قرار دارند. تمام فراخوان ها (Calls) بدون منشا هستند و در بین عملیات اجرایی هیچ چیزی توسط سرویس RESTful ذخیره نمی شود؛ به عبارت دیگر این سرویس شبیه به یک سامانه جعبه سیاه (Black Box) است که جزییات اجرایی آن نامعلوم است.

کاربرد RESTful API

از آنجایی که فراخوان ها بدون منشا (Stateless) هستند بنابراین سرویس REST در اپلیکیشن های ابری (Cloud) بسیار کاربردی خواهد بود. کامپوننت های بدون منشا در صورت بروز مشکل می توانند دوباره به صورت آزادانه دیپلوی شوند، این کامپوننت ها همچنین قادر خواهند بود خود را با تغییرات لودینگ سازگار کنند. این موضوع به این دلیل است که هر ریکوئست توانایی این را دارد تا به هر Instance از یک کامپوننت هدایت شود؛ به عبارت دیگر هیچ چیزی ذخیره نمی شود تا Transaction بعدی آن را به یاد آورد.

به طور کل سرویس REST در استفاده از وب مفید است اما به دلیل اینکه اتصال به یک سرویس از طریق API موجب کنترل نحوه دیکدینگ (Decoding) یک URL می شود، بنابراین مدل RESTful در سرویس های ابری مفید خواهد بود. سیستم های رایانش ابری (Cloud Computing) و میکروسرویس (Microservice) ادعا می کنند که استفاده از معماری RESTful API در آینده ای نه چندان دور به یک قانون تبدیل خواهد شد.

محدودیت های طراحی و معماری RESTful API

دکتر Roy Fielding در پایان نامه دکتری خود در سال 2000 برای اولین بار از طرح RESTful API استفاده کرد. برای اینکه یک سرویس وب به عنوان RESTful API حقیقی تلقی شود باید از شش محدودیت معماری REST تبعیت کند که در ادامه هر یک را توضیح خواهیم داد:

• استفاده از Uniform Interface

منابع از طریق یک URL واحد قابل شناسایی هستند و نفوذ به آنها نیز فقط با استفاده از متدهای بنیادین پروتکل شبکه مانند GET، PUT و DELETE امکان پذیر خواهد بود.

• مبتنی بر سمت کاربر (Client-Side)

باید یک مرزبندی شفافی بین کاربر و سرور وجود داشته باشد. دامنه کاربر مربوط به بخش UI و جمع آوری ریکوئست است. در حالی که دسترسی به داده ها، مدیریت کار و امنیت به دامنه سرور مربوط خواهد بود. این اتصال بین مشتری و سرور باعث می شود که هر کدام به صورت مستقل ارتقا داده شوند.

• عملیات بدون منشا (Stateless Operations)

تمام عملیات سمت کاربر باید به صورت بدون منشا باشند و مدیریت حالت (State) مورد نیاز باید به جای سرور بر روی سمت کاربر انجام پذیرد.

• کشینگ (Caching) منابع RESTful

تمام منابع باید اجازه کشینگ را داشته باشند مگر اینکه به صراحت اعلام شود امکان کشینگ وجود ندارد.

• سیستم لایه ای (Layered System)

مدل REST امکان معماری متشکل از سرور چند لایه ای را برای برنامه نویسان فراهم می کند.

• تقاضای کد

در اکثر اوقات یک سرور ایستا یک منبع را در قالب کدهای JSON یا XML پاسخ می دهد، اما سرورها در صورت لزوم قادر خواهند بود تا کدهای اجرایی را برای کاربران نیز ارسال کنند.

تفاوت RESTful API و SOAP

مدل RESTful API و پروتکل دسترسی آسان به اشیاء (SOAP)، هر کدام متدهای مختلفی برای فراخوانی سرویس های وب ارائه می کنند. مدل REST یک سبک معماری محسوب می شود در حالی که SOAP یک پروتکل ارتباطی استاندارد را برای تبادل پیام های مبتنی بر XML تعریف می کند. البته به خاطر داشته باشید که اپلیکیشن های REST نیز می توانند از پروتکل SOAP استفاده کنند.

سرویس های وب RESTful API بدون منشا (Stateless) هستند و در مقایسه با SOAP راحت تر اجرا می شوند. اما از آنجایی که هیچ مجموعه قوانینی برای توصیف رابط سرویس های وب REST وجود ندارد، بنابراین کاربران باید محتوا و زمینه آن را درک کنند. سرویس های REST برای دستگاه هایی نظیر موبایل مفید بوده و به راحتی با وبسایت های موجود ادغام می شوند.

در طرف دیگر پروتکل SOAP در مقایسه با سرویس REST به پلامپینگ کدهای (Plumping Code) کمتری نیاز دارد، این کدهای زیر ساختی سطح پایین در حقیقت ماژول های کد اصلی را به یکدیگر متصل می کند. زبان توصیف خدمات وب (Web Services Description Language) مجموعه ای از قوانین را برای تعریف پیام ها، اتصالات، عملیات و موقعیت مکانی سرویس توضیح می دهد. سرویس های وب SOAP برای پردازش و فراخوانی ناهمزمان مفید هستند.

تاریخچه RESTful API

قبل از REST، توسعه دهندگان از SOAP برای یکپارچه سازی API استفاده می کردند. آنها برای برقراری فراخوانی، کدهای XML را از طریق یک فراخوانی از راه دور (RPC) می نوشتند. در سال 2000، روی فیلدینگ به همراه گروهی از توسعه دهندگان دیگر تصمیم گرفتند که برای ارتباط سرورها یک استاندارد خاص طراحی کنند. فیلدینگ مدل REST را در رساله دکترای خود مطرح کرد و امروزه برنامه نویسان با استفاده از آن نرم افزارهای مختلف را با یکدیگر ادغام می کنند.

شرکت Salesforce اولین کمپانی بود که در سال 2000 یک API را در پکیج خدمات اینترنتی خود به فروش رساند. اگرچه توسعه دهندگان اندکی قادر به استفاده از آن XML API های پیچیده بودند. سرانجام شرکت EBay یک سرویس REST API راه اندازی کرد و آن را در هر وبسایتی که به API آن دسترسی داشت نیز توسعه داد. این موضوع توجه شرکت های بزرگ تجاری را نیز به خود جلب کرد تا آنجایی که کمپانی آمازون از سرویس API خود در سال 2002 رونمایی کرد.

کمپانی Flicker نیز سرویس RESTful API اختصاصی خود را در سال 2004 معرفی کرد به گونه ای که بلاگرها می توانستند تصاویر موجود در وبلاگ ها و شبکه های اجتماعی خود را در آن بارگذاری کنند. فیسبوک و توییتر نیز API اختصاصی خود را در سال 2006 منتشر کردند.

زمانی که وب سرویس آمازون (AWS) به راه اندازی فضای ابری (Cloud) در سال 2006 کمک کرد، توسعه دهندگان با استفاده از REST API می توانستند به فضای اطلاعات دسترسی پیدا کنند و بدین ترتیب درخواست برای API های عمومی نیز با افزایش چشمگیری مواجه شد. به عبارت دیگر برنامه نویسان از آن زمان به سرویس RESTful API علاقه مند شدند و هم اکنون برای افزودن قابلیت های دیگر به وبسایت و اپلیکیشن های خود از آن استفاده می کنند.