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

۱۵۸۹۴ بازدید
آخرین به‌روزرسانی: ۱ خرداد ۱۴۰۲
زمان مطالعه: ۲۸ دقیقه
REST چیست؟ | همه چیز درباره RESTful API — به زبان ساده

REST یک «شیوه معماری» یا «الگوی طراحی» برای APIها است. از زمان اختراع اینترنت، افراد برنامه‌های کاربردی و صفحات وب مختلفی برای کسب اطلاعات در خصوص منابع گوناگون را مورد استفاده قرار داده‌اند. اگرچه، تاکنون کم‌تر کسی به این مسئله توجه کرده است که این داده‌ها از کجا می‌آیند؟ این داده‌ها از سرورها (Server) دریافت می‌شوند و اپلیکیشن‌ها برای دریافت و ارسال داده‌ها با وب‌سرورها در ارتباط هستند. یک REST API راهی برای ارتباط دو سیستم کامپیوتری مثل یک مرورگر وب و سرورها از طریق HTTP است. در این مطلب به نحوه ارتباط یک کلاینت با سرور به سبک REST برای استخراج اطلاعات مورد نیاز پرداخته و به سوالاتی نظیر «REST چیست»، «RESTful API چیست» یا «REST API چیست» پاسخ داده شده است.

فهرست مطالب این نوشته
997696

اکنون، قبل از پرداختن به تعریف 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) | راهنمای کامل و رایگان جنگو برای شروع» + اینجا کلیک کنید.
تصویر برای سوال API چیست در مطلب REST چیست

اکنون در ادامه مطلب 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 چه محدودیت‌ها و قوانینی باید دنبال شوند،‌ لازم است دو اصطلاح کلیدی توضیح داده شود.

کلاینت چیست ؟

کلاینت (مشتری | Client) شخص یا نرم‌افزاری است که از API استفاده می‌کند. کلاینت می‌تواند یک توسعه‌دهنده باشد. برای مثال، یک شخص به عنوان توسعه‌دهنده می‌تواند در برنامه‌ای که می‌نویسد API توییتر را برای خواندن و نوشتن داده‌ها از توییتر، ایجاد یک توییت جدید و کارهای بیش‌تر به کار گیرد.

بنابراین، برنامه آن توسعه‌دهنده API‌ توییتر را فراخوانی می‌کند. همچنین، کلاینت می‌تواند یک مرورگر وب باشد. وقتی شخصی وب‌سایت توییتر را باز می‌کند، مرورگر کلاینتی است که API توییتر را فراخوانی کرده و از داده‌‌های دریافتی برای پردازش (رندر | Render) اطلاعات روی صفحه استفاده می‌کند.

منبع چیست ؟

یک منبع (Resource) می‌تواند هر شیئی باشد که API امکان فراهم‌سازی اطلاعاتی را در موردش داشته باشد. به عنوان مثال در API اینستاگرام، منبع می‌تواند یک کاربر، یک عکس یا یک هشتگ باشد. هر منبع دارای یک شناسه منحصربه‌فرد (Unique Identifier) است. شناسه می‌تواند یک نام یا یک عدد باشد.

ساز و کار یک API که در مطلب REST چیست در مورد آن توضیح داده شده است.

تاریخچه REST

در مورد تاریخچه REST باید گفت که قبل از REST توسعه‌دهندگان از معماری SOAP برای توسعه APIها استفاده می‌کردند. توسعه‌دهندگان ناچار بودند یک سند XML را با یک فراخوانی پروسه از راه دور (Remote Procedure Call | RPC) در بدنه (Body) به صورت دستی وارد کنند. سپس، آن‌ها نقطه انتهایی را مشخص می‌کردند و پاکت SOAP را به آن نقطه انتهایی می‌فرستادند. در این بخش از مطلب REST‌ چیست مطالبی در ارتباط با تاریخچه REST بیان شده است.

چه کسی REST‌ را به وجود آورد ؟

REST توسط دانشمند رایانه، روی فیلدینگ (Roy Fielding) بنا نهاده شد. او قواعد REST‌ را در پایان‌نامه دکتری خود در دانشگاه کالیفرنیا (Irvine) در سال ۱۳۸۰ ارائه کرد.

REST چگونه شکل گرفت ؟

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

REST چگونه بر سر زبان‌ها افتاد ؟

Salesforce‌ اولین شرکتی بود که یک API را به عنوان بخشی از بسته (Package) «اینترنت به عنوان یک سرویس» در همان سال ۱۳۸۰ به فروش رساند. اگر چه، توسعه‌دهندگان اندکی توانستند از آن API پیچیده XML استفاده کنند. پس از آن، eBay یک REST API ساخت که به وسیله آن REST API امکان گسترش فروشگاه eBay‌ به هر سایتی که از آن API استفاده می‌کرد، وجود داشت. این مسئله توجه یک غول دیگر تجارت الکترونیک را به خود جلب کرد و «آمازون» API خود را یک سال بعد معرفی کرد.

شرکت‌های پیشتاز در ارائه REST API

Flickr نیز RESTful API خود را در سال ۱۳۸۳ شمسی ارائه کرد که این امکان را به وبلاگ‌نویسان می‌داد تا به راحتی از تصاویر Flickr در سایت‌ها و خوراک‌های (Feed) شبکه‌های اجتماعی خود استفاده کنند. فیسبوک و توییتر، هر دو APIهای خود را در ۱۳۸۵ منتشر کردند. وقتی سرویس‌های وب آمازون (Amazon Web Services | AWS) سرویس ابری را در سال ۱۳۸۵ ارائه کرد، توسعه‌دهندگان می‌توانستند تنها در چند دقیقه با استفاده از REST API سرویس AWS، به فضای ذخیره‌سازی بزرگی دست پیدا کنند.

و به این ترتیب، تقاضا برای APIهای عمومی به طور تصاعدی رشد کرد. از آن زمان، توسعه‌دهندگان APIهای RESTful را پذیرا بوده‌اند و از آن‌ها برای به‌کارگیری قابلیت‌های افزوده به وب‌سایت‌ها و اپلیکیشن‌هایشان بهره می‌برند. امروزه، REST APIها «شالوده و استخوان‌بندی اینترنت» به‌شمار می‌روند.

چرا نیاز به REST API وجود دارد ؟

برای پاسخ به سوال چرا نیاز به REST API وجود دارد می‌توان از یک مثال کمک گرفت. بنابراین می‌توان استفاده از یک اپلیکیشن خرید بلیت سینما را در نظر گرفت. واضح است که این اپلیکیشن به داده‌های ورودی بسیاری نیاز دارد چرا که، ارائه داده‌ها در چنین اپلیکیشنی هرگز ایستا (Static | ثابت) نخواهند بود.

مثلاً، داده‌ها شامل فیلم‌های در حال اکران هستند که به طور مرتب تغییر می‌کنند. فیلم‌های جدید اضافه می‌شوند و اکران برخی فیلم‌ها به اتمام می‌رسد. بنابراین، داده‌ها هیچ‌گاه ایستا نخواهند بود. حال، این سوال به وجود می‌آید که این داده‌ها از کجا دریافت می‌شوند؟

داده ها در اپلیکیشن ها از کجا می‌آیند ؟

داده‌های استفاده شده در اپلیکیشن‌ها و وب‌سایت‌ها از سرور یا همان وب‌سرورها (Web-Server) دریافت می‌شوند. بنابراین، کلاینت از طریق API اطلاعات مورد نیاز را از سرور درخواست می‌کند و سپس، سرور به کلاینت پاسخ لازم را ارسال خواهد کرد. در اینجا، پاسخ ارسال شده به کلاینت در قالب یک صفحه وب HTML است. اما، آیا ارسال یک صفحه وب در قالب HTML، می‌تواند پاسخی مناسب و مورد انتظار برای کلاینت باشد؟

آیا ارسال داده توسط سرور در قالب HTML‌ مناسب است ؟

به احتمال زیاد پاسخ این سوال منفی است. چرا که کلاینت ترجیح می‌دهد به جای یک صفحه HTML، داده‌ها را در یک قالب ساختاریافته (Structured Format) دریافت کند. به همین دلیل، ارسال داده‌ از سمت سرور در پاسخ به درخواست کلاینت در قالب JSON یا XML روش بهتری است. هم JSON و هم XML دارای یک ساختار سلسله‌مراتبی (Hierarchical) و منظم هستند. تا اینجا همه چیز ساده و مرتب به نظر می‌رسد.

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

REST چیست ؟

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

بنابراین یک شیٔ وجود دارد که سرور یک حالت (وضعیت | State) خاص از آن شیٔ را ارسال می‌کند. به همین دلیل است که REST سرنامی برای عبارت Representational State Transfer به معنی انتقال حالت بازنمودی است.

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

مفهوم REST

همان‌طور که بیان شد، REST‌ سرنامی برای REpresentational State Transfer و به معنی انتقال حالت بازنمودی است.

  • یعنی وقتی یک RESTful API فراخوانی می‌شود، سرور یک بازنمایی (Representation) از حالت منبع درخواستی برای کلاینت (درخواست کننده) ارسال خواهد کرد.

در ادامه برای درک بهتر و پاسخ به سوال REST چیست یک مثال ساده ارائه شده است.

یک مثال برای درک بهتر

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

قالب بازنمایی

بازنمایی (بازنمود | Representation) یک حالت می‌تواند در قالب JSON باشد که احتمالاً برای اکثر APIها این چنین است. همچنین، این بازنمایی می‌تواند در قالب XML‌ یا HTML نیز باشد.

تعریف REST

بنابراین، می‌توان انتقال حالت بازنمودی را که به عنوان REST شناخته می‌شود، اینگونه تعریف کرد:

  • REST یک شیوه معماری و یک رویکرد برای مقاصد ارتباطی است که اغلب در توسعه خدمات مختلف وب مورد استفاده قرار می‌گیرد.

شیوه و سبک معماری‌گونه REST به مصرف پهنای باند کم‌تر کمک می‌کند و باعث می‌شود یک اپلیکیشن برای اینترنت مناسب‌تر و بهتر باشد. REST اغلب به عنوان «زبان اینترنت» (Language of the Internet) شناخته می‌شود. برای درک بهتر، باید بررسی عمیق‌تری انجام شود و نحوه دقیق کارکرد یک REST API را شناخت. به همین دلیل،‌ در ادامه مطلب REST چیست برای درابتدا درخواست API با یک مثال ساده شرح داده شده است.

مثال ساده درخواست و پاسخ در API

اکثراً افراد با وب‌اپلیکیشن گیت‌هاب آشنایی دارند. Github دارای API خودش است که با کمک آن می‌توان اطلاعاتی را درباره کاربران، مخازن (Repository) آن‌ها و موارد کاربردی دیگر برای توسعه یک اپلیکیشن و کار روی پروژه‌های برنامه‌نویسی یافت. می‌توان این داده‌ها را دستکاری و از آن‌ها در پروژه خود استفاده کرد. در ادامه مطلب REST چیست مثال ساده‌ای از یک درخواست API‌ به مخازن گیت‌هاب ارائه شده است.

درخواست به API

مثالی از یک «درخواست به API» به صورت زیر است:

در تصویر مثالی از یک درخواست به API برای مطلب REST چیست آورده شده است.

این درخواست با کمک CURL (یک ابزار خط فرمان) اجرا شده است. همچنین، ابزارهای دیگری برای ارسال و دریافت درخواست HTTP‌ به API از طریق مرورگر مانند REST Client ،Postman و سایر موارد نیز موجود هستند. همان‌طور که ملاحظه می‌شود، این درخواست دارای یک URL‌ است. URL می‌تواند حاوی آدرس درخواست ارسالی و موارد درخواستی باشد.

پاسخ از سرور

پاسخ سرور چیزی شبیه به تصویر زیر خواهد بود:

تصویر مربوط به پاسخ سرور به درخواست API در مطلب REST چیست

پاسخ سرور در REST چگونه است ؟

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

  1. یک شناسه (Identifier) برای منبع مورد نظر نیاز است. این شناسه، همان URL منبع مربوطه است که همچنین، به عنوان نقطه انتهایی (Endpoint) نیز شناخته می‌شود. در واقع، URL‌ سرنامی برای Uniform Resource Locator به معنای «موقعیت‌یاب یکپارچه منبع» است.
  2. عملیاتی که سرور باید روی آن منبع انجام دهد. این عملیات می‌تواند در قالب یک متُد 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‌ چیست ؟

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

تفاوت REST و RESTful چیست ؟

REST یک سبک از معماری نرم‌افزار است که به بیانی ساده تکنولوژی و پروتکل‌های موجود در وب را به کار می‌گیرد. عبارت RESTful یا رست فول معمولاً برای اشاره به وب‌سرویس‌هایی به کار گرفته می‌شود که سبک معماری REST را پیاده‌سازی می‌کنند. در واقع، پسوند «ful» که به REST‌ اضافه شده، به معنی «داشتن قابلیت» REST یا تطابق داشتن با این سبک معماری است. یعنی این وب‌سرویس‌ها یا APIها از سبک و شیوه معماری REST استفاده می‌کنند.

نگاهی عمیق‌تر به REST API

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

محدودیت های REST API چه هستند ؟

شش محدودیت REST، مستقل بودن از حالت (Stateless)، کلاینت-سروری بودن، داشتن واسط یکپارچه، قابل ذخیره‌سازی بودن (Cacheable)، داشتن سیستم لایه‌ای و ارسال کد در صورت تقاضا است. این اصول، توسط دکتر فیلدینگ (Dr. Fielding) پایه‌گذاری شده‌اند.

همان‌طور که در ابتدای مطلب REST چیست بیان شد، دکتر فیلدینگ همان شخصی است که معماری و طراحی REST API‌ را در اوایل دهه ۸۰ شمسی تعریف کرد. در ادامه مطلب REST چیست این شش اصل راه‌گشا شرح داده شده‌اند.

این تصویر در مطلب REST چیست حاوی دیاگرامی است که در آن محدودیت‌های 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 باید شامل تمام اطلاعاتی باشد که سرور برای اجرای آن درخواست به آن نیاز دارد و هر پاسخی که سرور باز می‌گرداند، باید شامل تمام اطلاعاتی باشد که کلاینت برای درک آن پاسخ به آن اطلاعات نیازمند است.

ابررسانه به عنوان موتور حالت اپلیکیشن

ابررسانه به عنوان موتور حالت اپلیکیشن (Hypermedia as the Engine of Application State) می‌تواند کمی گنگ به نظر برسد. بنابراین، نیاز به تجزیه و تحلیل آن وجود دارد. منظور از اپلیکیشن همان وب‌اپلیکیشنی است که سرور در حال اجرای آن است. منظور از ابررسانه (Hypermedia)، ابرلینک (Hyperlink) یا همان لینک‌هایی است که سرور می‌تواند در پاسخش به کلاینت آن‌ها را لحاظ کند. تمام عبارت «ابررسانه به عنوان موتور حالت اپلیکیشن» به این معناست که سرور در یک پاسخ می‌تواند کلاینت را از روش‌های تغییر حالت وب‌اپلیکیشن مطلع سازد.

توضیح بیش‌تر پیرامون ابررسانه به عنوان موتور حالت

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

HTML حاوی برچسب‌هایی است به همراه لینک‌ (اینجا مربوط به Hypermedia می‌شود) به یک صفحه وب دیگر، جایی که اطلاعات کاربر می‌تواند به‌روزرسانی شود (مثلاً لینکی به صفحه تنظیمات پروفایل). برای ارائه یک چشم‌انداز، اکثر صفحات وب، ابررسانه را به عنوان موتور حالت اپلیکیشن به کار می‌برند. اما، اکثر APIهای وب رایج به این اصل پایبند نیستند.

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

قابل ذخیره‌سازی بودن

قابل ذخیره‌سازی بودن (Cacheable) به این معناست که داده‌های ارسال شده از سمت سرور حاوی اطلاعاتی در این مورد هستند که آیا این داده‌ها قابل ذخیره‌سازی در حافظه موقت (Cahce) هستند یا خیر. اگر داده‌ها قابل ذخیره‌سازی باشند، ممکن است حاوی نوعی شماره نسخه باشند. شماره نسخه ذخیره‌سازی را امکان‌پذیر می‌کند.

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

سیستم لایه‌بندی شده

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

کد در صورت تقاضا

کد در صورت تقاضا (Code On Demand) یک اصل اختیاری است. یک API حتی بدون فراهم کردن کد در صورت تقاضا می‌تواند RESTful در نظر گرفته شود. کلاینت می‌تواند از سرور درخواست کد بدهد و سپس، پاسخ از سرور حاوی مقداری کُد خواهد بود. وقتی پاسخ در قالب HTML‌ است، معمولاً این پاسخ به صورت یک اسکریپت خواهد بود. پس از دریافت کد، کلاینت می‌تواند آن را اجرا کند. در ادامه مطلب REST چیست نحوه عملکرد REST API توضیح داده شده است.

REST API چطور کار می‌کند ؟

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

در حال حاضر، شرکت‌های بسیاری ماژول‌هایی را برای استفاده توسعه‌دهندگان ارائه می‌کنند. ماژول‌هایی که توسط واسط مدیریت داده‌های ابری (CDMI) آمازون S3 و OpenStack Swift ارائه می‌شوند، بسیار محبوب هستند.

تصویر نمایش دهنده نحوه عملکرد 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 چیست ؟

به طور کلی، به همه این متُدها (عملیات) اصطلاحاً «CRUD» گفته می‌شود. این متدهای HTTP داده‌ها را مدیریت می‌کنند. CRUD سرنامی برای هر یک از کلمات «Update» ،«Reard» ،«Create» و «Delete» است.

قالب های داده در REST

در REST اجزاء شبکه یک منبع هستند که کاربر درخواست دسترسی به آن‌ها را ارسال می‌کند. درست مثل جعبه سیاهی که جزئیات پیاده‌سازی آن روشن نیست، همه فراخوانی‌ها مستقل از حالت هستند. با سرویس RESTful نمی‌توان هیچ چیزی را بین اجراها حفظ کرد. فرمت‌هایی (قالب‌هایی) که یک REST API از آن‌ها پشتیبانی می‌کند شامل موارد زیر است:

  • اپلیکیشن/JSON
  • اپلیکیشن/XML
  • اپلیکیشن/X-wbe+xml
  • اپلیکیشن/x-www-form-urlencoded
  • چندبخشی/form-data

متد های درخواست

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

  • 1xx - اطلاعاتی (Informational)
  • 2xx - موفقیت (Success)
  • 3xx - تغییرمسیر (Redirection)
  • 4xx - خطای کلاینت (Client Error)
  • 5xx - خطای سرور (Server Error)

تفاوت REST و SOAP چیست ؟

تفاوت REST و SOAP‌ برای مدتی است که به عنوان یک مسئله مهم مطرح می‌شود.

اگرچه هر دوی آن‌ها پاسخی برای این سوال مشترک است: «چگونه می‌توان به سرویس‌های وب دسترسی پیدا کرد؟» اما به طور شگفت‌آوری، تصمیم‌گیری برای انتخاب یکی نسبت به دیگری می‌تواند کار دشواری باشد.

تصویر مربوط به تفاوت REST و SOAP‌ در مطلب REST چیست

تفاوت های کلیدی 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 به طور ویژه‌ای برای ارائه خدمات مکاتبه به XML وابسته است. مایکروسافت در اصل SOAP‌ را توسعه داد تا آن را با فناوری‌های قدیمی که به خوبی کار نمی‌کردند جایگزین کند. تکنولوژی‌های قدیمی به دلیل اینکه مکاتبه را به صورت دودویی (باینری) انجام می‌دادند عملکرد مناسبی نداشتند. بعد از یک نسخه اولیه، مایکروسافت SOAP‌ را برای استانداردسازی در کارگروه مهندسی اینترنت (Internet Engineering Task Force |‌ IETF) تسلیم کرد.

تعمیم‌یافتگی در SOAP

SOAP‌ به گونه‌ای طراحی شده تا بتواند از گسترش (Expansion) پشتیبانی کند. بنابراین، سرنام‌های متعدد دیگری در ارتباط با آن وجود دارد. از جمله این سرنام‌ها می‌توان به WS-Addressing ،WS-Policy ،WS-Federation ،WS-Coordination ،WS-Security و WS-RemotePortlets اشاره کرد.

در حقیقت، می‌توان یک لیست بلند بالا از این استانداردها برای خدمات وب یافت. مسئله این است که SOAP به شدت قابل تعمیم (Extensible) است اما برای یک هدف خاص تنها از بخش‌های مورد نیاز استفاده می‌شود. برای مثال، استفاده از یک سرویس وب عمومی برای همه در دسترس است.

شباهت های 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 ارسالی به سرور آمده است.

1<?xml version="1.0"?>
2<SOAP-ENV:Envelope 
3xmlns:SOAP-ENV
4="http://www.w3.org/2001/12/soap-envelope" 
5SOAP-ENV:encodingStyle
6=" http://www.w3.org/2001/12/soap-encoding">
7<soap:Body>
8 <Demo.guru99WebService
9 xmlns="http://tempuri.org/">
10   <EmployeeID>int</EmployeeID>
11   </Demo.guru99WebService>
12 </soap:Body>
13</SOAP-ENV:Envelope>

REST به پهنای باند زیادی در زمان ارسال درخواست‌ها به سرور نیاز ندارد. پیام‌های REST بیش‌تر فقط شامل پیام‌های JSON است. در ادامه، مثالی آمده است از یک پیام JSON که به وب‌سرور فرستاده می‌شود. می‌توان ملاحظه کرد که حجم پیام در مقایسه با SOAP‌ بسیار کم‌تر است.

1{"city":"Mumbai","state":"Maharastra"}

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

مثالی از ابزار ارتباط رسمی

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

عملیات مبتنی بر حالت

در شرایطی که نیاز به نگهداری حالت از یک درخواست به درخواست دیگر وجود داشته باشد، آنگاه استاندارد SOAP 1.2 ساختار *WS را برای پشتیبانی از چنین نیازمندی ارائه می‌دهد.

کاربردهای REST API

چون فراخوانی‌ها مستقل از حالت هستند، REST برای کاربردهای ابری مناسب است. در صورت بروز نقص، می‌توان اجزاء مستقل از حالت را مجدد به کار گرفت. همچنین، برای پاسخ‌دهی به تغییرات بار (Load) وارده می‌توان مقیاس این اجزاء را تنظیم کرد. این امکان به این دلیل وجود دارد که هر درخواستی را می‌توان به هر رخداد (Instance) از یک جزء هدایت کرد.

در الگوی REST هیچ چیزی که نیاز باشد به وسیله تراکنش بعدی به خاطر سپرده شود را نمی‌توان ذخیره کرد؛ این مسئله REST‌ را برای استفاده در وب مطلوب ساخته است. مدل مبتنی بر REST به این دلیل در سرویس‌های ابری کاربردی است که استفاده از خدمات از طریق API در واقع یک مسئله مدیریت نحوه کدگشایی URL است.

چه زمانی باید از 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

در این بخش از مطلب REST‌ چیست در یک نمایش کاربردی، نحوه ساخت یک اپلیکیشن CRUD REST‌ با استفاده از Node.js آموزش داده شده است.

برای ساخت این اپلیکیشن نیاز به نصب موارد زیر وجود دارد:

  1. Node.js
  2. Express.js
  3. Joi
  4. (nodemon (Node Monitor

برای این آموزش عملی، از محیط توسعه WebStorm جهت نوشتن و اجرای کدها استفاده شده است. اما می‌توان از هر IDE یا ویرایش‌گر کد دلخواه استفاده کرد. در ادامه مراحل ساخت یک RESTful API شرح داده شده است.

مرحله اول ایجاد پوشه پروژه

ابتدا باید یک پوشه پروژه ایجاد شود که شامل همه فایل‌های موجود در پروژه خواهد بود. سپس باید خط فرمان را باز کرد و از داخل خط فرمان وارد محل پوشه پروژه شد. در ادامه مطلب REST چیست و مرحله بعدی ساخت REST API فراخوانی nmp انجام شده است.

مرحله دوم: فراخوانی npm

حالا، npm باید با استفاده از دستور زیر فراخوانی شود. این دستور ماژول‌های npm را روی سیستم آماده‌سازی می‌کند. npm یا Node Package Manager بسته‌ای برای زبان برنامه‌نویسی جاوا اسکریپت است.

1npm init

با زدن کلید اینتر، Node.js درخواست خواهد کرد تا برخی جزئیات در خصوص پروژه وارد شود. این جزئیات اساساً فراداده‌هایی برای پروژه مربوطه خواهند بود. در اینجا می‌توان نقطه ورودی را به همراه بسیاری از اطلاعات دیگر تعریف کرد. برای این نمونه نمایشی (demo) از script.js به عنوان یک نقطه ورود استفاده شده است. سپس برای تایید اطلاعاتی که باید وارد می‌شد سوال پرسیده می‌شود که با زدن کلید Y این کار انجام خواهد شد.

مرحله سوم: نصب Express.js

در این مرحله از ساخت RESTful API در مطلب REST چیست، باید Express.js را با استفاده از دستور زیر نصب کرد:

1npm i express

Express یک فریم‌ورک وب است که می‌تواند به همراه Node.js مورد استفاده قرار گیرد. این فریم‌ورک وب، امکان ایجاد APIهای RESTful‌ را با کمک متُدهای Helper و لایه‌های میانی برای تنظیم اپلیکیشن فراهم خواهد ساخت.

مرحله 3.1: نصب Joi

در این مرحله از ساخت RESTful API در مطلب REST چیست، باید Joi‌ را نصب کرد:

1npm i joi

این بسته امکان ایجاد دستور کار (blueprint) برای اشیاء جاوا اسکریپت را فراهم می‌سازد. Joi اطلاعات را برای اطمینان از تایید اعتبار اطلاعات کلیدی ذخیره می‌کند.

مرحله 3.۲: نصب nodemon

در نهایت، بسته نظارت node به نام nodemon با استفاده از دستور زیر نصب می‌شود.

1npm i -g nodemon

nodemon روی همه فایل‌ها با انواع تعمیم‌ها در داخل این پوشه نظارت می‌کند. همچنین، با نظارت nodemon نیازی نیست برای اعمال هر تغییری سرور را بازنشانی (Restart) کرد. nodemon به طور نامحسوس تغییرات را شناسایی و سرور را بازنشانی می‌کند. در ادامه مطلب REST‌ چیست دو قطعه کد مربوط به ساخت RESTful API‌ ارائه شده است.

فایل package.json

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

1{
2"name": "restapidemo",
3"version": "1.0.0",
4"description": "Creation of REST API",
5"main": "script.js",
6"scripts": {
7"test": "echo \"Error: no test specified\" && exit 1"
8},
9"author": "sahiti_kappagantula",
10"license": "ISC",
11"dependencies": {
12"express": "^4.17.1",
13"joi": "^14.3.1"
14}
15}

فایل script.js

علاوه بر package.json، فایل دیگری به نام script.js نیز باید در پوشه محل پروژه ایجاد و کدهای زیر در آن کپی شود. در ادامه مطلب REST چیست کدهای مربوط به فایل script.js ارائه شده‌اند.

1const express = require('express'); //Import Express
2const Joi = require('joi'); //Import Joi
3const app = express(); //Create Express Application on the app variable
4app.use(express.json()); //used the json file
5 
6//Give data to the server
7const customers = [
8{title: 'George', id: 1},
9{title: 'Josh', id: 2},
10{title: 'Tyler', id: 3},
11{title: 'Alice', id: 4},
12{title: 'Candice', id: 5}
13]
14 
15//Read Request Handlers
16// Display the Message when the URL consist of '/'
17app.get('/', (req, res) => {
18res.send('Welcome to Edurekas REST API!');
19});
20// Display the List Of Customers when URL consists of api customers
21app.get('/api/customers', (req,res)=> {
22res.send(customers);
23});
24// Display the Information Of Specific Customer when you mention the id.
25app.get('/api/customers/:id', (req, res) => {
26const customer = customers.find(c => c.id === parseInt(req.params.id));
27//If there is no valid customer ID, then display an error with the following message
28if (!customer) res.status(404).send('<h2 style="font-family: Malgun Gothic; color: darkred;">Ooops... Cant find what you are looking for!</h2>');
29res.send(customer);
30});
31 
32//CREATE Request Handler
33//CREATE New Customer Information
34app.post('/api/customers', (req, res)=> {
35 
36const { error } = validateCustomer(req.body);
37if (error){
38res.status(400).send(error.details[0].message)
39return;
40}
41//Increment the customer id
42const customer = {
43id: customers.length + 1,
44title: req.body.title
45};
46customers.push(customer);
47res.send(customer);
48});
49 
50//Update Request Handler
51// Update Existing Customer Information
52app.put('/api/customers/:id', (req, res) => {
53const customer = customers.find(c=> c.id === parseInt(req.params.id));
54if (!customer) res.status(404).send('<h2 style="font-family: Malgun Gothic; color: darkred;">Not Found!! </h2>');
55 
56const { error } = validateCustomer(req.body);
57if (error){
58res.status(400).send(error.details[0].message);
59return;
60}
61 
62customer.title = req.body.title;
63res.send(customer);
64});
65 
66//Delete Request Handler
67// Delete Customer Details
68app.delete('/api/customers/:id', (req, res) => {
69 
70const customer = customers.find( c=> c.id === parseInt(req.params.id));
71if(!customer) res.status(404).send('<h2 style="font-family: Malgun Gothic; color: darkred;"> Not Found!! </h2>');
72 
73const index = customers.indexOf(customer);
74customers.splice(index,1);
75 
76res.send(customer);
77});
78//Validate Information
79function validateCustomer(customer) {
80const schema = {
81title: Joi.string().min(3).required()
82};
83return Joi.validate(customer, schema);
84 
85}
86 
87//PORT ENVIRONMENT VARIABLE
88const port = process.env.PORT || 8080;
89app.listen(port, () => console.log(`Listening on port ${port}..`));

مرحله چهارم: نصب Postman

حالا مرحله بعدی این است که بررسی شود که آیا ناظرها (Handler) به درستی کار می‌کنند یا خیر. برای این کار، از یک افزونه کروم به نام Postman استفاده خواهد شد.

برای نصب Postman می‌توان به صفحه مربوط به این افزونه [+] مراجعه و روی گزینه «Add to Chrome» کلیک کرد.

تصویر آدرس نصب افزونه Postman‌ برای ساخت یک REST API در مطلب REST چیست

مرحله پنجم: اجرای Postman

حال پس از نصب Postman در این مرحله از ساخت RESTful API از مطلب REST چیست برای آزمایش اپلیکیشن باید Postman را اجرا کرد.

مرحله ششم: اجرای سرور

اما، قبل از شروع به کار با Postman و استفاده از رست فول API ساخته شده، باید سرور را اجرا کرد. برای اجرای سرور از دستور زیر استفاده می‌شود.

1node script.js

خروجی به صورت زیر خواهد بود:

تصویر خروجی اجرای سرور در دمو REST API در مطلب REST چیست

اکنون آزمایش متُد GET انجام خواهد شد.

مرحله هفتم : استفاده از متد GET

برای آزمایش متد GET باید ‌از فهرست کشویی گزینه GET انتخاب کرد و سپس، URL‌ تعریف شده را تایپ کرده و گزینه Send را زد. اگر کد به درستی کار کند، فهرستی از همه مشتریان که به صورت دستی در کدها افزوده شده‌اند، ملاحظه خواهد شد. در تصویر زیر می‌توان دید نتایج به چه شکل هستند. در تصویر مشخص شده که URL مربوطه، «localhost:8080/api/customers» است.

تصویر خروجی دمو REST API در مطلب REST چیست ؟

مرحله هشتم : استفاده از متد POST

اکنون، در این بخش از مطلب REST چیست و این مرحله، می‌توان سعی کرد یک مشتری جدید به پشته مشتریان افزوده شود. برای این کار، باید از منوی کشویی گزینه «POST‌» را انتخاب کرد و «URL‌» تعریف شده برای متُد «POST‌» را وارد کرد.

سپس، باید روی «Body» کلیک کرده و «Raw» را انتخاب کرد و در ادامه در منوی کشویی مقابل، همان‌طور که در تصویر نشان داده شده، «JSON» انتخاب می‌شود. اکنون، در قسمت متن نام مشتری تایپ و گزینه ارسال کلیک می‌شود.

تصویر نحوه استفاده از POST در RESTful API در مطلب REST چیست

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

مرحله نهم: به‌روزرسانی با استفاده از PUT

اکنون می‌توان به‌روزرسانی نام یک مشتری را آزمایش کرد. مثلاً اگر قصد به‌روزرسانی مشتری با شناسه ۳ وجود داشته باشد، ابتدا باید متد PUT از جدول کشویی انتخاب شده و URL‌ درخواست PUT به همراه شناسه مشتری که قصد به‌روزرسانی نامش وجود دارد،‌ وارد شود. سپس، در قسمت بدنه نام جدید آن مشتری وارد و کلید اینتر زده می‌شود. این کار باعث می‌شود یک پاسخ شامل شناسه مشتری به همراه نام به‌روزرسانی شده وی از سمت سرور ارسال شود.

تصویر مربوط به استفاده از متد PUT در REST API در آموزش REST چیست

مرحله دهم: حذف با استفاده از DELETE

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

اگر تراکنش موفق باشد، جزئیات کامل موردی که حذف شده در بدنه بازخورد ملاحظه خواهد شد.

استفاده از متد DELETE در دموی REST API در مطلب REST چیست

اکنون برای بررسی فهرست نهایی مشتریان، باید یک درخواست GET ارسال کرد. خروجی ارسال درخواست GET در تصویر زیر ملاحظه می‌شود.

درخواست GET نهایی برای مشاهده لیست مشتریان در دمو REST API در مطلب REST چیست ؟

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

جمع‌بندی

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

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

بر اساس رای ۲۶ نفر
آیا این مطلب برای شما مفید بود؟
اگر بازخوردی درباره این مطلب دارید یا پرسشی دارید که بدون پاسخ مانده است، آن را از طریق بخش نظرات مطرح کنید.
منابع:
Medium/Shif Ben AvrahamMedium/Zulaikha GeerSearchAppArchitectureMLSDevSMARTBEARGURU99
۳ دیدگاه برای «REST چیست؟ | همه چیز درباره RESTful API — به زبان ساده»

اگر از متد های http استفاده نکنیم چه اتفاقی میافته دیگه نمیشه گفت rest full ??
مثلا من همه end point هامو بصورت post تعریف کردم چه delete بوده چه update همه رو گفتم بصورت post بفرسته

این مقاله انقدر به فکر این بود که با استفاده از تکرار کلمات کلیدی در گوگل سئو خوبی پیدا بکنه از اصل موضوع که کیفیت مقاله باشه غافل شد
بیشتر از اینکه بفهمیدم restful api چیست ؟ این جمله رو بارها خواندیم و حفظ شدیم…!

سلام
من خیلی دنبال مطلب در مورد rest api , soap بود تو همه این سایت ها واقعا سایت شما عالی بود.
دستت درد نکنه خدا اجرتون بده.

نظر شما چیست؟

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *