REST چیست؟ | همه چیز درباره RESTful API – به زبان ساده

اکنون، قبل از پرداختن به تعریف REST API و اینکه REST چیست بهتر است ابتدا پیشنیازهای لازم برای درک مفهوم REST معرفی شوند. بنابراین، در ابتدای مطلب REST چیست منابع لازم در خصوص مفاهیم HTTP و API معرفی و همچنین، توضیحاتی در مورد دو مفهوم Client و Resource ارائه شده است.
پیشنیازهای آموزش REST چیست؟
قبل از مطالعه این مطلب و یافتن پاسخ این سوال که REST چیست باید درکی از مفاهیم HTTP و API وجود داشته باشد. در ادامه این بخش از مطلب REST چیست به معرفی منابع مطالعاتی مناسب برای هر کدام از این دو مفهوم مهم پرداخته شده است. در صورتی که درک و آشنایی کافی با HTTP و API وجود داشته باشد، میتوان از این بخش صرفنظر و به بخشهای بعدی مطلب REST چیست مراجعه کرد.
API چیست ؟
API سرنامی برای «واسط برنامهنویسی اپلیکیشن» (Application Programming Interface) است. API یک میانجی یا واسطه است که امکان برقراری ارتباط میان دو برنامه کاربردی را فراهم میکند.
برای مطالعه بیشتر و پاسخ کاملتر به سوال «API چیست» میتوان مطالب زیر را مطالعه کرد:
- API چیست؟ — به زبان ساده: در این مطلب، مفهوم واسط برنامهنویسی اپلیکیشن که با سرنام API شناخته میشود، از پایه و با زبانی ساده آموزش داده شده است. برای مطالعه مطلب «API چیست؟ — به زبان ساده» + اینجا کلیک کنید.
- API چیست و API های باز چگونه اینترنت را تغییر میدهند؟: در این مطلب، ابتدا API تعریف و سپس، کاربردهای API در زمینههایی از جلمه کسب و کارها، مرورگرها و سایر موارد توضیح داده شده است. برای مطالعه مطلب «API چیست و API های باز چگونه اینترنت را تغییر میدهند؟» + اینجا کلیک کنید.
- آموزش جنگو (Django) | راهنمای کامل و رایگان جنگو برای شروع: در این مطلب یکی از APIهای بسیار محبوب و مهم پایتون در زمینه توسعه وباپلیکیشن به نام جنگو به طور کامل معرفی و تمام جوانب آن شرح داده شده است. برای مطالعه مطلب «آموزش جنگو (Django) | راهنمای کامل و رایگان جنگو برای شروع» + اینجا کلیک کنید.
اکنون در ادامه مطلب REST چیست به تعریف کوتاهی از HTTP و معرفی منابع مطالعاتی در مورد آن پرداخته شده است.
HTTP چیست ؟
HTTTP سرنامی برای «پروتکل انتقال فرا متن» (Hypertext Transfer Protocol) است. HTTP پروتکل یا ضوابطی است که برای انتقال داده در وب استفاده میشود.
برای یادگیری و درک بیشتر مفاهیم HTTP، مطالعه مطالب زیر پیشنهاد میشود.
- پروتکل HTTP چیست؟ — به زبان ساده: در این مطلب، پروتکل HTTP و اجزا و نحوه عملکرد آن توضیح داده شده است. برای مطالعه مطلب «پروتکل HTTP چیست؟ — به زبان ساده»، + اینجا کلیک کنید.
- همه چیز در مورد HTTP 3 — از صفر تا صد: در این مطلب، به مشخصات نسخه سه پروتکل HTTP و همچنین تاریخچه کلی HTTP پرداخته شده است. برای مطالعه مطلب «همه چیز در مورد HTTP 3 — از صفر تا صد» + اینجا کلیک کنید.
- وب هوک (WebHook) چیست ؟ — به زبان ساده: در ابتدای این مطلب نیز تعریفی از HTTP و همچنین یک درخواست HTTP به زبان ساده و روان ارائه شده است. برای مطالعه مطلب «وب هوک (WebHook) چیست ؟ — به زبان ساده» + اینجا کلیک کنید.
قبل از ورود به اینکه چه چیزی یک API را RESTful (رست فول | مطابق با REST) میکند و برای ایجاد APIهای RESTful چه محدودیتها و قوانینی باید دنبال شوند، لازم است دو اصطلاح کلیدی توضیح داده شود.
کلاینت چیست ؟
منبع چیست ؟
تاریخچه REST
چه کسی REST را به وجود آورد ؟
REST توسط دانشمند رایانه، روی فیلدینگ (Roy Fielding) بنا نهاده شد. او قواعد REST را در پایاننامه دکتری خود در دانشگاه کالیفرنیا (Irvine) در سال ۱۳۸۰ ارائه کرد.
REST چگونه شکل گرفت ؟
در اوایل دهه هشتاد شمسی، روی فیلدینگ و گروهی از توسعهدهندگان تصمیم گرفتند استانداردی را به وجود بیاورند تا هر سروری بتواند با سرور دیگر مکالمه کند. وی REST را تعریف و اصول و محدودیتهایی را برای آن تعیین کرد. این قواعد جهانی باعث شد کار تولید نرمافزار برای توسعهدهندگان آسانتر شود.
REST چگونه بر سر زبانها افتاد ؟
شرکتهای پیشتاز در ارائه REST API
و به این ترتیب، تقاضا برای APIهای عمومی به طور تصاعدی رشد کرد. از آن زمان، توسعهدهندگان APIهای RESTful را پذیرا بودهاند و از آنها برای بهکارگیری قابلیتهای افزوده به وبسایتها و اپلیکیشنهایشان بهره میبرند. امروزه، REST APIها «شالوده و استخوانبندی اینترنت» بهشمار میروند.
چرا نیاز به REST API وجود دارد ؟
برای پاسخ به سوال چرا نیاز به REST API وجود دارد میتوان از یک مثال کمک گرفت. بنابراین میتوان استفاده از یک اپلیکیشن خرید بلیت سینما را در نظر گرفت. واضح است که این اپلیکیشن به دادههای ورودی بسیاری نیاز دارد چرا که، ارائه دادهها در چنین اپلیکیشنی هرگز ایستا (Static | ثابت) نخواهند بود.
مثلاً، دادهها شامل فیلمهای در حال اکران هستند که به طور مرتب تغییر میکنند. فیلمهای جدید اضافه میشوند و اکران برخی فیلمها به اتمام میرسد. بنابراین، دادهها هیچگاه ایستا نخواهند بود. حال، این سوال به وجود میآید که این دادهها از کجا دریافت میشوند؟
داده ها در اپلیکیشن ها از کجا میآیند ؟
آیا ارسال داده توسط سرور در قالب HTML مناسب است ؟
REST چیست ؟
برای توضیح اینکه REST چیست باید گفت که، ایده REST به این صورت است که یک شیٔ از داده مورد درخواست کلاینت ایجاد و مقادیر آن شیٔ در پاسخ به کاربر ارسال شود. در مورد مثال اپلیکیشن فیلم، اگر کاربر درخواست یک فیلم در شهر خاصی را در یک مکان و زمان مشخص داشته باشد، آنگاه میتوان یک شیٔ در سمت سرور ایجاد کرد که دارای وضعیت یا حالت مشخصی است.
- برای دیدن فیلم آموزش فریم ورک Django Rest در پایتون برای ساخت Web APIs + اینجا کلیک کنید.
مفهوم REST
همانطور که بیان شد، REST سرنامی برای REpresentational State Transfer و به معنی انتقال حالت بازنمودی است.
- یعنی وقتی یک RESTful API فراخوانی میشود، سرور یک بازنمایی (Representation) از حالت منبع درخواستی برای کلاینت (درخواست کننده) ارسال خواهد کرد.
در ادامه برای درک بهتر و پاسخ به سوال REST چیست یک مثال ساده ارائه شده است.
یک مثال برای درک بهتر
قالب بازنمایی
بازنمایی (بازنمود | Representation) یک حالت میتواند در قالب JSON باشد که احتمالاً برای اکثر APIها این چنین است. همچنین، این بازنمایی میتواند در قالب XML یا HTML نیز باشد.
تعریف REST
بنابراین، میتوان انتقال حالت بازنمودی را که به عنوان REST شناخته میشود، اینگونه تعریف کرد:
- REST یک شیوه معماری و یک رویکرد برای مقاصد ارتباطی است که اغلب در توسعه خدمات مختلف وب مورد استفاده قرار میگیرد.
شیوه و سبک معماریگونه REST به مصرف پهنای باند کمتر کمک میکند و باعث میشود یک اپلیکیشن برای اینترنت مناسبتر و بهتر باشد. REST اغلب به عنوان «زبان اینترنت» (Language of the Internet) شناخته میشود. برای درک بهتر، باید بررسی عمیقتری انجام شود و نحوه دقیق کارکرد یک REST API را شناخت. به همین دلیل، در ادامه مطلب REST چیست برای درابتدا درخواست API با یک مثال ساده شرح داده شده است.
مثال ساده درخواست و پاسخ در API
درخواست به API
مثالی از یک «درخواست به API» به صورت زیر است:
پاسخ از سرور
پاسخ سرور چیزی شبیه به تصویر زیر خواهد بود:
پاسخ سرور در REST چگونه است ؟
وقتی کلاینت یکی از APIهای خود را فراخوانی میکند، آنچه که سرور انجام میدهد به دو چیز وابسته است که باید توسط کلاینت فراهم شود. این دو مورد، در ادامه فهرست شدهاند.
- یک شناسه (Identifier) برای منبع مورد نظر نیاز است. این شناسه، همان URL منبع مربوطه است که همچنین، به عنوان نقطه انتهایی (Endpoint) نیز شناخته میشود. در واقع، URL سرنامی برای Uniform Resource Locator به معنای «موقعیتیاب یکپارچه منبع» است.
- عملیاتی که سرور باید روی آن منبع انجام دهد. این عملیات میتواند در قالب یک متُد HTTP یا یک فعل (Verb) باشد. از متدهای رایج HTTP میتوان PUT ،POST ،GET و DELETE را نام برد.
برای مثال، واکشی یک کاربر توییتر خاص، با استفاده از RESTful API توییتر، به یک URL نیاز خواهد داشت که آن کاربر و متد اچتیتیپی GET را شناسایی کند. از متد GET برای واکشی منابع استفاده میشود.
یک مثال برای درک بهتر
«www.twitter.com/jk_rowling» یک URL است که شناسه منحصربهفرد جی.کی. رولینگ (J. K. Rowling) در توییتر را به همراه دارد که همان شناسهکاربری (Username) او (jk_rowling) است. توییتر از شناسهکاربری به عنوان Identifier استفاده میکند و البته شناسههای کاربری توییتر منحصربهفرد هستند و هیچ دو کاربر توییتر با شناسهکاربری یکسان وجود ندارد. متد اچتیتیپی GET تعیین میکند که قصد دریافت حالت آن کاربر وجود دارد.
وباپلیکیشن RESTful چیست ؟
یک وباپلیکیشن RESTful از شیوه معماری REST تبعیت میکند و اطلاعات درباره خودش را در قالب اطلاعات درباره منابعش ارائه میدهد. این وباپلیکیشن یا برنامه کاربردی تحت وب RESTپذیر یا رست فول همچنین، این امکان را برای کلاینت به وجود میآورد که اقداماتی را در خصوص آن منابع انجام دهد. این اقدامات میتواند ایجاد منابع جدید (مثلاً ایجاد یک کاربر جدید) یا تغییر منابع فعلی (مثلاً ویرایش یک پست) و سایر اقدامات از این دست باشد.
RESTful API چیست ؟
تفاوت REST و RESTful چیست ؟
REST یک سبک از معماری نرمافزار است که به بیانی ساده تکنولوژی و پروتکلهای موجود در وب را به کار میگیرد. عبارت RESTful یا رست فول معمولاً برای اشاره به وبسرویسهایی به کار گرفته میشود که سبک معماری REST را پیادهسازی میکنند. در واقع، پسوند «ful» که به REST اضافه شده، به معنی «داشتن قابلیت» REST یا تطابق داشتن با این سبک معماری است. یعنی این وبسرویسها یا APIها از سبک و شیوه معماری REST استفاده میکنند.
نگاهی عمیقتر به REST API
محدودیت های REST API چه هستند ؟
همانطور که در ابتدای مطلب REST چیست بیان شد، دکتر فیلدینگ همان شخصی است که معماری و طراحی REST API را در اوایل دهه ۸۰ شمسی تعریف کرد. در ادامه مطلب REST چیست این شش اصل راهگشا شرح داده شدهاند.
مستقل از حالت
مستقل بودن از حالت یعنی سرور هیچ چیزی در مورد کاربری که از API استفاده میکند، نمیداند. سرور به یاد نمیآورد که آیا کاربر API قبلاً یک درخواست GET برای همان منبع در گذشته دریافت کرده است یا خیر و همچنین، سرور به یاد نمیآورد که کاربر API قبلاً درخواست برای دریافت کدام منابع ارسال کرده است.
درخواستهایی که از جانب یک کلاینت به سرور ارسال میشوند حاوی همه اطلاعات لازم خواهد بود تا سرور بتواند دقیقاً متوجه شود که چه چیزی مدنظر کلاینت است. این میتواند بخشی از URL (آدرس منبع)، پارامترهای رشته پرس و جو (Query-String Parameter)، بدنه (Body) یا حتی سربرگ (Header) باشد. URL برای شناسایی منبع به صورت منحصربهفرد استفاده میشود و بدنه حالت (وضعیت) منبع درخواست شده را نگهداری میکند. وقتی سرور درخواست را پردازش کند، یک پاسخ از طریق بدنه، حالت یا سربرگها به کلاینت ارسال میشود.
جداسازی کلاینت-سرور
کلاینت و سرور، هر یک به تنهایی و به صورت مستقل عمل میکنند و تعامل میان این دو تنها در قالب درخواستها (Request) و پاسخها (Response) است. آغاز کننده این درخواستها تنها کلاینت است و پاسخها فقط در واکنش به یک درخواست از جانب سرور به کلاینت ارسال میشوند. سرور فقط آنجا مینشیند و منتظر دریافت درخواست از جانب کلاینت میماند. سرور هیچ وقت خودسرانه شروع به ارسال و پخش کردن اطلاعات در خصوص حالت منابع نمیکند.
واسط یکپارچه
برای دستیابی به یکپارچگی (Uniformity) در سراسر برنامه کاربردی، REST دارای چهار محدودیت واسط کاربری است که در ادامه مطلب REST چیست فهرست شدهاند.
شناسایی منابع
شناسایی منبع (Resource Identification) یعنی درخواست ارسالی به سرور باید دارای یک شناسه منبع باشد.
دستکاری منابع با استفاده از بازنماییها
دستکاری منابع با استفاده از بازنماییها (Resource Manipulation Using Representations) یعنی پاسخی که سرور بازمیگرداند باید حاوی اطلاعات کافی باشد تا کلاینت بتواند منبع را تغییر دهد و ویرایش کند.
پیامهای خود-توصیفگر
پیامهای خود-توصیفگر (Self-Descriptive Messages) یعنی هر درخواست به API باید شامل تمام اطلاعاتی باشد که سرور برای اجرای آن درخواست به آن نیاز دارد و هر پاسخی که سرور باز میگرداند، باید شامل تمام اطلاعاتی باشد که کلاینت برای درک آن پاسخ به آن اطلاعات نیازمند است.
ابررسانه به عنوان موتور حالت اپلیکیشن
توضیح بیشتر پیرامون ابررسانه به عنوان موتور حالت
اگر کلاینت در مورد یک کاربر خاص درخواست ارسال کند، نه تنها سرور میتواند حالت آن کاربر را فراهم کند، بلکه میتواند اطلاعاتی در مورد نحوه تغییر حالت آن کاربر مثل چگونگی ویرایش نام آن کاربر یا حذف کاربر نیز ارائه دهد. میتوان در مورد نحوه انجام آن این گونه تصور کرد که یک سرور پاسخی را در قالب HTML به یک مرورگر (کلاینت) باز میگرداند.
HTML حاوی برچسبهایی است به همراه لینک (اینجا مربوط به Hypermedia میشود) به یک صفحه وب دیگر، جایی که اطلاعات کاربر میتواند بهروزرسانی شود (مثلاً لینکی به صفحه تنظیمات پروفایل). برای ارائه یک چشمانداز، اکثر صفحات وب، ابررسانه را به عنوان موتور حالت اپلیکیشن به کار میبرند. اما، اکثر APIهای وب رایج به این اصل پایبند نیستند.
قابل ذخیرهسازی بودن
چون کلاینت میداند که در حال حاضر کدام نسخه داده را (از یک پاسخ قبلی) در اختیار دارد، میتواند از ارسال درخواست پیدرپی برای دادههای یکسان خودداری کند. همچنین، کلاینت باید بداند که آیا نسخه فعلی داده منقضی شده است یا خیر. در این صورت کلاینت متوجه خواهد شد که باید یک درخواست دیگر برای دریافت بهروزترین دادهها درباره حالت یک منبع به سرور بفرستد.
سیستم لایهبندی شده
میان یک کلاینت که یک بازنمایی از حالت یک منبع را درخواست میکند و سرور که پاسخ را بازمیگرداند، ممکن است چند سرور بین راه وجود داشته باشد. این سرورها ممکن دارای یک لایه امنیتی، یک لایه ذخیرهسازی موقت یا یک لایه توازن بار باشند یا هر قابلیت دیگری را ارائه دهند. آن لایهها نباید درخواست یا پاسخ را تحت تأثیر قرار بدهند. کلاینت هیچ دخالتی ندارد در اینکه چه تعداد لایه میان کلاینت و سرور پاسخدهنده مورد نظر وجود دارد.
کد در صورت تقاضا
کد در صورت تقاضا (Code On Demand) یک اصل اختیاری است. یک API حتی بدون فراهم کردن کد در صورت تقاضا میتواند RESTful در نظر گرفته شود. کلاینت میتواند از سرور درخواست کد بدهد و سپس، پاسخ از سرور حاوی مقداری کُد خواهد بود. وقتی پاسخ در قالب HTML است، معمولاً این پاسخ به صورت یک اسکریپت خواهد بود. پس از دریافت کد، کلاینت میتواند آن را اجرا کند. در ادامه مطلب REST چیست نحوه عملکرد REST API توضیح داده شده است.
REST API چطور کار میکند ؟
RESTful API یک تراکنش را برای ایجاد یک سری ماژولهای کوچک تجزیه میکند. هر ماژول یک بخش زیربنایی از تراکنش را خطاب قرار میدهد. این ماژولبندی انعطافپذیری بسیاری را برای توسعهدهندگان فراهم میکند. اما میتواند برای توسعهدهندگان چالشبرانگیز باشد که بخواهند REST API خود را از صفر بسازند.
یک RESTful API از دستوراتی برای دستیابی به منابع استفاده میکند. حالت یک منبع در هر برچسب زمانی (Timestamp) مربوطه را یک بازنمایی منبع مینامند. یک RESTful API از روشهای موجود HTTP که به وسیله پروتکل RFC 2616 تعیین شدهاند استفاده میکند. در ادامه مطلب REST چیست با جزئیاتی بیشتری در مورد ساز و کار REST بحث شده است.
عملیات اصلی REST
شیوه عملکرد RESTful API در چهار عمل حیاتی خلاصه میشود. این چهار عمل در ادامه فهرست شدهاند.
- دریافت دادهها در یک قالب مناسب
- ایجاد داده جدید
- بهروزرسانی دادهها
- پاک کردن دادهها
REST به شدت به HTTP وابسته است. هر کدام از عملیات بیان شده در بالا، از متُد HTTP مختص خودش استفاده میکند.
متدهای HTTP استفاده شده در REST
هر یک از این چهار متد در ادامه فهرست شدهاند.
- GET: برای دریافت دادهها استفاده میشود.
- POST: برای ایجاد داده جدید استفاده میشود.
- PUT: برای بهروزرسانی (ویرایش) دادهها استفاده میشود.
- DELETE: برای حذف دادهها مورد استفاده قرار میگیرد.
قالب های داده در REST
در REST اجزاء شبکه یک منبع هستند که کاربر درخواست دسترسی به آنها را ارسال میکند. درست مثل جعبه سیاهی که جزئیات پیادهسازی آن روشن نیست، همه فراخوانیها مستقل از حالت هستند. با سرویس RESTful نمیتوان هیچ چیزی را بین اجراها حفظ کرد. فرمتهایی (قالبهایی) که یک REST API از آنها پشتیبانی میکند شامل موارد زیر است:
متد های درخواست
تمام درخواستهایی که ارسال میشوند کدهای حالت HTTP مختص به خودشان را دارند. تعداد زیادی از این کدها وجود دارد که به پنج دسته طبقهبندی میشوند. اولین رقم تعیین میکند که یک کد به کدام دسته تعلق دارد. این پنج دسته در ادامه فهرست شده است.
- 1xx - اطلاعاتی (Informational)
- 2xx - موفقیت (Success)
- 3xx - تغییرمسیر (Redirection)
- 4xx - خطای کلاینت (Client Error)
- 5xx - خطای سرور (Server Error)
تفاوت REST و SOAP چیست ؟
تفاوت REST و SOAP برای مدتی است که به عنوان یک مسئله مهم مطرح میشود.
اگرچه هر دوی آنها پاسخی برای این سوال مشترک است: «چگونه میتوان به سرویسهای وب دسترسی پیدا کرد؟» اما به طور شگفتآوری، تصمیمگیری برای انتخاب یکی نسبت به دیگری میتواند کار دشواری باشد.
تفاوت های کلیدی REST و SOAP
در این بخش از مطلب REST چیست تفاوتهای کلیدی REST و SOAP به صورت خلاصه و فهرستوار ارائه شده است.
- SOAP سرنامی برای عبارت Simple Object Access Protocol به معنای شیوهنامه دسترسی به شیٔ، در حالی که REST سرنامی برای Representational State Transfer به معنای تبادل حالت بازنمودی است.
- SOAP یک پروتکل (شیوهنامه)، در حالی که REST یک الگوی معماری است.
- SOAP از واسطهای خدمات برای ارائه قابلیتهایش به اپلیکیشنهای کلاینت استفاده میکند در حالی که، REST مکانیاب خدمات یکپارچه را برای دسترسی به اجزاء در دستگاه سختافزاری به کار میگیرد.
- برای استفاده از SOAP پهنای باند بیشتری نیاز است در حالی که REST نیاز چندانی به پهنای باند ندارد.
- SOAP تنها با فرمتهای XML کار میکند در حالی که REST با متن خام، HTML، XML و JSON سازگاری دارد.
- SOAP نمیتواند از REST استفاده کند. درحالی که، REST میتواند SOAP را به کار گیرد.
اکنون، برای درک بهتر تفاوت میان SOAP و REST بهتر است شناخت بیشتری در مورد SOAP بدست آورد. لذا، در ادامه مطلب REST چیست به این مهم پرداخته شده است.
SOAP چیست ؟
SOAP یک پروتکل مبتنی بر XML است که برای دسترسی به سرویسهای وب از طریق HTTP استفاده میشود. SOAP یک شیوهنامه دسترسی به خدمات وب بر پایه استانداردها است که قدمت زیادی هم دارد. SOAP در ابتدا توسط مایکروسافت معرفی شده است. مفهوم SOAP برخلاف آنچه از سرنامش (Simple Object Access Protocol | شیوهنامه دسترسی به شیٔ) برمیآید، چندان ساده نیست.
هم SOAP و هم REST دارای مسائلی هستند که باید در زمان تصمیم برای انتخاب یکی از آنها مد نظر قرار گرفته شوند. بنابراین، در ادامه مطلب REST چیست و برای درک بهتر مفهوم SOAP مرور سریعی در مورد آن ارائه شده است.
مروری سریع بر SOAP
تعمیمیافتگی در SOAP
SOAP به گونهای طراحی شده تا بتواند از گسترش (Expansion) پشتیبانی کند. بنابراین، سرنامهای متعدد دیگری در ارتباط با آن وجود دارد. از جمله این سرنامها میتوان به WS-Addressing ،WS-Policy ،WS-Federation ،WS-Coordination ،WS-Security و WS-RemotePortlets اشاره کرد.
شباهت های REST و SOAP
در حالی که SOAP و REST به واسطه پروتکل HTTP با هم شباهتهایی دارند، SOAP دارای الگوهای مکاتبه سفت و سختتری نسبت به REST است. قوانین در SOAP اهمیت دارند چرا که، بدون این قوانین نمیتوان به سطحی از استانداردسازی دست یافت. REST به عنوان یک سبک معماری، نیازمند پردازش نیست و ذاتاً انعطافپذیرتر است. هم REST و هم SOAP بر قوانین معتبری تکیه دارند که همه توسعهدهندگان تبعیت از این قوانین را به نفع تبادل اطلاعات پذیرفتهاند. در ادامه مطلب REST چیست به تفاوت میان این دو پرداخته شده است.
تفاوت های بین REST و SOAP
هر روش مزیتها و معایب خودش را دارد. بنابراین، خوب است که فرد بداند باید در چه شرایطی از کدام رویکرد استفاده کند. در ادامه مطلب REST چیست و در این بخش، برخی از تفاوتهای اساسی میان REST و SOAP به همراه چالشهای پیش رو حین استفاده از هر یک بیان شده است.
REST شیوه معماری ، SOAP پروتکل
REST یک شیوه معماری است که در آن یک سرویس وب تنها در صورتی میتواند به عنوان یک سرویس RESTful شناخته شود که اصول و قواعد بیان شده را رعایت کند. SOAP به عنوان یک پروتکل با یک مشخصه طراحی شده است. SOAP شامل یک فایل WSDL است که در آن اطلاعات مورد نیاز در مورد اینکه آن وب سرویس چه کاری انجام میدهد به همراه موقعیت آن وب سرویس موجود است.
استفاده REST از SOAP
REST میتواند از SOAP به عنوان پروتکل زیربنایی برای خدمات وب استفاده کند. چرا که هر چه باشد، REST یک الگوی معماری بیش نیست. در طرف مقابل، SOAP نمیتواند از REST استفاده کند زیرا SOAP یک پروتکل ولی REST یک سبک معماری است.
تفاوت عملکردی در REST و SOAP
REST از مکانیاب خدمات یکپارچه (URL) برای دسترسی به اجزاء یک دستگاه سختافزاری استفاده میکند. برای مثال، اگر یک شیٔ نمایندهای از دادههای یک کارمند باشد که در یک آدرس URL مثل http://demo.faradars میزبانی میشود، برخی از URLهایی که برای دسترسی به این دادهها ممکن است وجود داشته باشد به صورت زیر است:
- http://demo.faradars.com/Employee
- http://demo.faradars.com/Employee/1
این در حالی است که SOAP از واسطهای خدمات برای ارائه قابلیتهایش به اپلیکیشنهای کلاینت استفاده میکند. در SOAP، فایل WSDL اطلاعات لازم را فراهم کرده تا کلاینت بداند چه خدماتی قابل ارائه است.
تفاوت مصرف پهنای باند در REST و SOAP
SOAP نیاز به پهنای باند بیشتری برای مصرف خود دارد. زیرا پیامهای SOAP اطلاعات زیادی را در خود جای دادهاند. بنابراین، میزان تبادل داده با استفاده از SOAP بسیار زیاد است. در ادامه، یک نمونه پیام SOAP ارسالی به سرور آمده است.
REST به پهنای باند زیادی در زمان ارسال درخواستها به سرور نیاز ندارد. پیامهای REST بیشتر فقط شامل پیامهای JSON است. در ادامه، مثالی آمده است از یک پیام JSON که به وبسرور فرستاده میشود. میتوان ملاحظه کرد که حجم پیام در مقایسه با SOAP بسیار کمتر است.
تفاوت فرمت استفاده شده در REST و SOAP
در REST فرمتهای داده مختلفی از جمله متن خام، JSON ،XML ،HTML و سایر موارد مجاز است. اگرچه، JSON به عنوان ایدهآلترین فرمت برای تبادل داده شناخته میشود. اما، SOAP تنها میتواند با فرمت XML کار کند. همانطور که در کدهای مربوط به پیام SOAP ملاحظه شد، تمام دادههای ارسالی در قالب XML هستند.
یکی از مسائل قابل بحث این است که برای طراحی خدمات وب (APIها)، چه زمانی باید از SOAP و چه زمانی از REST استفاده کرد؟
چه زمانی باید از SOAP استفاده کرد ؟
در این بخش از مطلب REST چیست به بحث در مورد مواقعی پرداخته شده است که باید از SOAP به عنوان پروتکل دسترسی به اشیاء یک API استفاده شود.
پردازش غیر همزمان و فراخوانی پی در پی
در شرایطی که کلاینت به یک سطح تضمین شده از پایائی (Reliability) و امنیت نیاز داشته باشد، استاندارد جدید SOAP به نام SOAP 1.2 ویژگیهای افزوده بسیاری را ارائه میدهد. خصوصاً وقتی که بحث امنیت در میان باشد.
یک ابزار ارتباطی رسمی
اگر کلاینت و سرور هر دو در خصوص فرمت توافق داشته باشند، آنگاه، SOAP 1.2 مشخصات سفت و سختی را برای چنین تعاملی فراهم میکند. در ادامه مطلب REST چیست، مثالی برای درک بهتر این مسئله ارائه شده است.
مثالی از ابزار ارتباط رسمی
عملیات مبتنی بر حالت
در شرایطی که نیاز به نگهداری حالت از یک درخواست به درخواست دیگر وجود داشته باشد، آنگاه استاندارد SOAP 1.2 ساختار *WS را برای پشتیبانی از چنین نیازمندی ارائه میدهد.
کاربردهای REST API
چون فراخوانیها مستقل از حالت هستند، REST برای کاربردهای ابری مناسب است. در صورت بروز نقص، میتوان اجزاء مستقل از حالت را مجدد به کار گرفت. همچنین، برای پاسخدهی به تغییرات بار (Load) وارده میتوان مقیاس این اجزاء را تنظیم کرد. این امکان به این دلیل وجود دارد که هر درخواستی را میتوان به هر رخداد (Instance) از یک جزء هدایت کرد.
چه زمانی باید از REST استفاده شود؟
در این بخش از مطلب REST چیست برخی از معیارهای کلیدی که مشخص میکنند چه زمانی باید از الگوی REST برای APIها استفاده شود، ارائه شده است.
پهنای باند و منابع محدود
به دلیل اینکه پیامهای SOAP در محتوا حجیمتر هستند و پهنای باند بسیار بیشتری را مصرف میکنند، در مواقعی که محدودیت در پهنای باند شبکه وجود دارد، باید از سبک معماری REST استفاده شود.
شرایط مستقل از حالت
اگر نیازی به نگهداری حالت اطلاعات از یک درخواست به درخواست دیگر وجود نداشته باشد، آنگاه باید از REST استفاده شود. همانطور که بیان شد، اگر نیاز به یک جریان اطلاعاتی مناسب وجود داشته باشد که در آن برخی اطلاعات باید از یک درخواست به داخل درخواست دیگری جریان داشته باشد، SOAP برای چنین هدفی مناسبتر است.
مثالی برای درک بهتر
کدنویسی آسان
کدنویسی سرویسهای REST و پیادهسازی متعاقب آن، نسبت به SOAP بسیار سادهتر است. بنابراین، اگر یک راهکار سریع و موفق برای APIها نیاز باشد، REST انتخاب مناسبی به حساب میآید.
چالش ها در REST API
در این بخش از مطلب REST چیست برخی از چالشهای REST API بیان شده است.
کمبود امنیت
REST نسبت به SOAP امنیت چندانی تحمیل نمیکند. به همین دلیل، REST برای URLهای عمومی در دسترس مناسب است. اما، در مورد تبادل دادههای محرمانه میان کلاینت و سرور، REST بدترین سازوکاری است که میتواند برای APIها مورد استفاده قرار بگیرد.
کمبود حالت
اکثر وباپلیکیشنها نیاز به یک سازوکار حالتمند دارند. اگر باز هم به مثال فروشگاه آنلاین و سازوکار یک سبد خرید مراجعه شود، لازم است قبل از انجام تراکنش خرید، تعداد اقلام موجود در سبد مشخص باشد. در استفاده از شیوه REST، بار نگهداری از حالت بر عهده کلاینت خواهد بود. این مسئله اپلیکیشن کلاینت را سنگینتر و نگهداری از آن را دشوارتر میکند.
آموزش RESTful API
برای ساخت این اپلیکیشن نیاز به نصب موارد زیر وجود دارد:
- Node.js
- Express.js
- Joi
- (nodemon (Node Monitor
مرحله اول ایجاد پوشه پروژه
مرحله دوم: فراخوانی npm
حالا، npm باید با استفاده از دستور زیر فراخوانی شود. این دستور ماژولهای npm را روی سیستم آمادهسازی میکند. npm یا Node Package Manager بستهای برای زبان برنامهنویسی جاوا اسکریپت است.
مرحله سوم: نصب Express.js
در این مرحله از ساخت RESTful API در مطلب REST چیست، باید Express.js را با استفاده از دستور زیر نصب کرد:
مرحله 3.1: نصب Joi
در این مرحله از ساخت RESTful API در مطلب REST چیست، باید Joi را نصب کرد:
مرحله 3.۲: نصب nodemon
در نهایت، بسته نظارت node به نام nodemon با استفاده از دستور زیر نصب میشود.
nodemon روی همه فایلها با انواع تعمیمها در داخل این پوشه نظارت میکند. همچنین، با نظارت nodemon نیازی نیست برای اعمال هر تغییری سرور را بازنشانی (Restart) کرد. nodemon به طور نامحسوس تغییرات را شناسایی و سرور را بازنشانی میکند. در ادامه مطلب REST چیست دو قطعه کد مربوط به ساخت RESTful API ارائه شده است.
فایل package.json
فایل script.js
علاوه بر package.json، فایل دیگری به نام script.js نیز باید در پوشه محل پروژه ایجاد و کدهای زیر در آن کپی شود. در ادامه مطلب REST چیست کدهای مربوط به فایل script.js ارائه شدهاند.
مرحله چهارم: نصب Postman
مرحله پنجم: اجرای Postman
حال پس از نصب Postman در این مرحله از ساخت RESTful API از مطلب REST چیست برای آزمایش اپلیکیشن باید Postman را اجرا کرد.
مرحله ششم: اجرای سرور
اما، قبل از شروع به کار با Postman و استفاده از رست فول API ساخته شده، باید سرور را اجرا کرد. برای اجرای سرور از دستور زیر استفاده میشود.
خروجی به صورت زیر خواهد بود:
اکنون آزمایش متُد GET انجام خواهد شد.
مرحله هفتم : استفاده از متد GET
برای آزمایش متد GET باید از فهرست کشویی گزینه GET انتخاب کرد و سپس، URL تعریف شده را تایپ کرده و گزینه Send را زد. اگر کد به درستی کار کند، فهرستی از همه مشتریان که به صورت دستی در کدها افزوده شدهاند، ملاحظه خواهد شد. در تصویر زیر میتوان دید نتایج به چه شکل هستند. در تصویر مشخص شده که URL مربوطه، «localhost:8080/api/customers» است.
مرحله هشتم : استفاده از متد POST
اکنون، در این بخش از مطلب REST چیست و این مرحله، میتوان سعی کرد یک مشتری جدید به پشته مشتریان افزوده شود. برای این کار، باید از منوی کشویی گزینه «POST» را انتخاب کرد و «URL» تعریف شده برای متُد «POST» را وارد کرد.
سپس، باید روی «Body» کلیک کرده و «Raw» را انتخاب کرد و در ادامه در منوی کشویی مقابل، همانطور که در تصویر نشان داده شده، «JSON» انتخاب میشود. اکنون، در قسمت متن نام مشتری تایپ و گزینه ارسال کلیک میشود.
اگر متد POST به درستی کار کند، بدنه پیام پاسخ، حاوی نام و شناسه مشتری جدید خواهد بود. در اینجا اگر دقت شود، فقط نام مشتری ذکر شده و شناسه مشتری ارائه نشده است. این مسئله به این معنی است که شناسه مشتری به صورت خودکار حذف (کسر) شده است.
مرحله نهم: بهروزرسانی با استفاده از PUT
اکنون میتوان بهروزرسانی نام یک مشتری را آزمایش کرد. مثلاً اگر قصد بهروزرسانی مشتری با شناسه ۳ وجود داشته باشد، ابتدا باید متد PUT از جدول کشویی انتخاب شده و URL درخواست PUT به همراه شناسه مشتری که قصد بهروزرسانی نامش وجود دارد، وارد شود. سپس، در قسمت بدنه نام جدید آن مشتری وارد و کلید اینتر زده میشود. این کار باعث میشود یک پاسخ شامل شناسه مشتری به همراه نام بهروزرسانی شده وی از سمت سرور ارسال شود.
مرحله دهم: حذف با استفاده از DELETE
در پایان، یک درخواست DELETE برای پاک کردن یک رکورد موجود انجام میشود. برای این کار باید گزینه DELETE را از فهرست کشویی انتخاب کرد. سپس، URL ناظر درخواست حذف به همراه جزئیات مشتری که قصد حذفش وجود دارد وارد میشود و بعد باید کلید اینتر را زد.
اگر تراکنش موفق باشد، جزئیات کامل موردی که حذف شده در بدنه بازخورد ملاحظه خواهد شد.

اکنون برای بررسی فهرست نهایی مشتریان، باید یک درخواست GET ارسال کرد. خروجی ارسال درخواست GET در تصویر زیر ملاحظه میشود.
همانطور که در تصویر بالا ملاحظه میشود، بدنه مجموعاً دارای پنج مشتری است و مشتری با شناسه ۳ وجود ندارد به دلیل اینکه این مشتری با متد DELETE حذف شده است. به این ترتیب، در مطلب REST چیست آموزش ساخت یک REST API به عنوان نمونه ارائه شد.
جمعبندی
در مطلب REST چیست سعی شد تا جای ممکن همه چیز درباره RESTful API و به طور کلی شیوه معماری REST ارائه و با بیانی ساده به سوالات رایجی مانند «REST چیست»، «RESTful API چیست» یا «REST API چیست» که در واقع همگی بیانگر یک مفهوم هستند پاسخ داده شود. همانطور که بیان شد، REST به عنوان یک شیوه و سبک معماری ساخت API و برنامههای کاربردی وب، کار ارتباط کلاینت و سرور را بسیار راحتتر کرده است.
به واقع، REST به واسطه محدودیتها و استانداردهایی که وضع میکند، موجب سازماندهی نحوه ارتباط و ساختار ارسال و دریافت درخواستها در وب شده است. همانطور که در ابتدای مطلب REST چیس بیان شد، امروزه، REST APIها «شالوده و استخوانبندی اینترنت» بهشمار میروند.
مطالب مجله فرادرس را در جستجوی گوگل سریعتر ببینید































اگر از متد های http استفاده نکنیم چه اتفاقی میافته دیگه نمیشه گفت rest full ??
مثلا من همه end point هامو بصورت post تعریف کردم چه delete بوده چه update همه رو گفتم بصورت post بفرسته
این مقاله انقدر به فکر این بود که با استفاده از تکرار کلمات کلیدی در گوگل سئو خوبی پیدا بکنه از اصل موضوع که کیفیت مقاله باشه غافل شد
بیشتر از اینکه بفهمیدم restful api چیست ؟ این جمله رو بارها خواندیم و حفظ شدیم…!
سلام
من خیلی دنبال مطلب در مورد rest api , soap بود تو همه این سایت ها واقعا سایت شما عالی بود.
دستت درد نکنه خدا اجرتون بده.