API RESTful چیست؟

API RESTful چیست؟

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

API چیست؟

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

می‌توانید API وب را به‌عنوان دروازه‌ای بین کلاینت‌ها و منابع در وب در نظر بگیرید.

کلاینت‌ها

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

منابع

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

REST چیست؟

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

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

در ادامه برخی از اصول سبک معماری REST آورده شده است:

رابط یکنواخت

رابط یکنواخت اساس طراحی هر سرویس وب RESTful است. این نشان می‌دهد که سرور اطلاعات را در قالبی استاندارد منتقل می‌کند. منبع قالب‌بندی‌شده در REST به‌عنوان نمایندگی شناخته می‌شود. این قالب می‌تواند با نمایندگی داخلی منبع در برنامه سرور متفاوت باشد. برای مثال، سرور می‌تواند داده‌ها را به‌صورت متن ذخیره کند اما آن‌ها را در قالب نمایندگی HTML ارسال کند.

رابط یکنواخت چهار محدودیت معماری را اعمال می‌کند:

1. درخواست‌ها باید منابع را شناسایی کنند. این کار با استفاده از یک شناسه منبع یکنواخت انجام می‌شود.
2. کلاینت‌ها اطلاعات کافی در نمایندگی منبع دارند تا در صورت تمایل منبع را اصلاح یا حذف کنند. سرور این شرط را با ارسال متادیتایی که منبع را بیشتر توصیف می‌کند، برآورده می‌کند.
3. کلاینت‌ها اطلاعاتی درباره نحوه پردازش بیشتر نمایندگی دریافت می‌کنند. سرور این کار را با ارسال پیام‌های خودتوصیفی که حاوی متادیتا درباره نحوه استفاده بهینه کلاینت از آن‌ها هستند، انجام می‌دهد.
4. کلاینت‌ها اطلاعاتی درباره تمام منابع مرتبط دیگر که برای تکمیل یک وظیفه نیاز دارند دریافت می‌کنند. سرور این کار را با ارسال لینک‌های هایپر در نمایندگی انجام می‌دهد تا کلاینت‌ها بتوانند به‌صورت پویا منابع بیشتری را کشف کنند.

بی‌حالتی

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

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

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

قابلیت ذخیره‌سازی

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

کد درخواستی

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

مزایای APIهای RESTful چیست؟

APIهای RESTful مزایای زیر را شامل می‌شوند:

مقیاس‌پذیری

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

انعطاف‌پذیری

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

استقلال

APIهای REST از فناوری مورد استفاده مستقل هستند. می‌توانید برنامه‌های کلاینت و سرور را به زبان‌های برنامه‌نویسی مختلف بنویسید بدون اینکه بر طراحی API تأثیر بگذارد. همچنین می‌توانید فناوری زیربنایی را در هر طرف بدون تأثیر بر ارتباط تغییر دهید.

APIهای RESTful چگونه کار می‌کنند؟

عملکرد اصلی یک API RESTful مشابه مرور اینترنت است. کلاینت هنگامی که به منبعی نیاز دارد، با استفاده از API با سرور تماس می‌گیرد. توسعه‌دهندگان API توضیح می‌دهند که کلاینت چگونه باید از API REST در مستندات API برنامه سرور استفاده کند. مراحل کلی برای هر فراخوانی API REST عبارتند از:

1. کلاینت درخواستی به سرور ارسال می‌کند. کلاینت درخواست را طبق مستندات API قالب‌بندی می‌کند تا سرور آن را درک کند.
2. سرور کلاینت را احراز هویت می‌کند و تأیید می‌کند که کلاینت حق انجام آن درخواست را دارد.
3. سرور درخواست را دریافت کرده و به‌صورت داخلی پردازش می‌کند.
4. سرور پاسخی به کلاینت برمی‌گرداند. پاسخ شامل اطلاعاتی است که به کلاینت می‌گوید آیا درخواست موفق بوده است یا خیر. پاسخ همچنین شامل هر اطلاعاتی است که کلاینت درخواست کرده است.

جزئیات درخواست و پاسخ API REST بسته به نحوه طراحی API توسط توسعه‌دهندگان کمی متفاوت است.

درخواست کلاینت API RESTful شامل چه چیزهایی است؟

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

شناسه منبع یکتا

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

روش

توسعه‌دهندگان اغلب APIهای RESTful را با استفاده از پروتکل انتقال ابرمتن (HTTP) پیاده‌سازی می‌کنند. یک روش HTTP به سرور می‌گوید که چه کاری باید با منبع انجام دهد. در ادامه چهار روش HTTP رایج آورده شده است:

GET

کلاینت‌ها از GET برای دسترسی به منابعی که در URL مشخص‌شده در سرور قرار دارند استفاده می‌کنند. آن‌ها می‌توانند درخواست‌های GET را کش کنند و پارامترهایی را در درخواست API RESTful ارسال کنند تا سرور داده‌ها را قبل از ارسال فیلتر کند.

POST

کلاینت‌ها از POST برای ارسال داده به سرور استفاده می‌کنند. آن‌ها نمایندگی داده را همراه با درخواست شامل می‌شوند. ارسال چندین‌بار درخواست POST یکسان اثر جانبی ایجاد چندین‌بار منبع یکسان را دارد.

PUT

کلاینت‌ها از PUT برای به‌روزرسانی منابع موجود در سرور استفاده می‌کنند. برخلاف POST، ارسال چندین‌بار درخواست PUT یکسان در یک سرویس وب RESTful نتیجه یکسانی می‌دهد.

DELETE

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

هدرهای HTTP

هدرهای درخواست متادیتاهایی هستند که بین کلاینت و سرور تبادل می‌شوند. برای مثال، هدر درخواست فرمت درخواست و پاسخ را نشان می‌دهد، اطلاعاتی درباره وضعیت درخواست ارائه می‌دهد و غیره.

داده

درخواست‌های API REST ممکن است شامل داده‌هایی برای عملکرد موفقیت‌آمیز روش‌های POST، PUT و سایر روش‌های HTTP باشند.

پارامترها

درخواست‌های API RESTful می‌توانند شامل پارامترهایی باشند که جزئیات بیشتری درباره آنچه باید انجام شود به سرور ارائه می‌دهند. در ادامه برخی از انواع مختلف پارامترها آورده شده است:

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

روش‌های احراز هویت API RESTful چیست؟

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

API RESTful چهار روش احراز هویت رایج دارد:

احراز هویت HTTP

HTTP برخی از طرح‌های احراز هویت را تعریف می‌کند که می‌توانید هنگام پیاده‌سازی API REST مستقیماً از آن‌ها استفاده کنید. در ادامه دو مورد از این طرح‌ها آورده شده است:

احراز هویت پایه

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

احراز هویت حامل

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

کلیدهای API

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

OAuth

OAuth رمزهای عبور و توکن‌ها را برای دسترسی ورود بسیار امن به هر سیستم ترکیب می‌کند. سرور ابتدا یک رمز عبور درخواست می‌کند و سپس یک توکن اضافی برای تکمیل فرآیند مجوز درخواست می‌کند. می‌تواند توکن را در هر زمان و همچنین در طول زمان با دامنه و طول عمر خاصی بررسی کند.

پاسخ سرور API RESTful شامل چه چیزهایی است؟

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

خط وضعیت

خط وضعیت شامل یک کد وضعیت سه‌رقمی است که موفقیت یا شکست درخواست را اعلام می‌کند. برای مثال، کدها 2XX نشان‌دهنده موفقیت هستند، اما کدها 4XX و 5XX نشان‌دهنده خطاها هستند. کدها 3XX نشان‌دهنده تغییر مسیر URL هستند.

در ادامه برخی از کدهای وضعیت رایج آورده شده است:

• ۲۰۰: پاسخ موفقیت عمومی
• ۲۰۱: پاسخ موفقیت روش POST
• ۴۰۰: درخواست نادرست که سرور نمی‌تواند پردازش کند
• ۴۰۴: منبع یافت نشد

بدنه پیام

بدنه پاسخ شامل نمایندگی منبع است. سرور قالب نمایندگی مناسب را بر اساس محتوای هدرهای درخواست انتخاب می‌کند. کلاینت‌ها می‌توانند اطلاعات را در قالب‌های XML یا JSON درخواست کنند، که نحوه نوشتن داده‌ها را در متن ساده تعریف می‌کنند. برای مثال، اگر کلاینت نام و سن فردی به نام جان را درخواست کند، سرور یک نمایندگی JSON به‌صورت زیر برمی‌گرداند: ‘{“name”:”John”, “age”:30}’

هدرها

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