RESTful API رابطی است که دو سیستم نرم افزاری از آن برای ارتباط و تبادل امن اطلاعات از طریق اینترنت استفاده می کنند. در واقع API های RESTful نوع خاصی از APIهای REST هستند که در تعامل با وب سرویس ها هستند که از این جهت می توان گفت که از نوع WEB API هستند.
API های RESTful چگونه کار می کنند؟
عملکرد اصلی RESTful API شبیه مرور اینترنت (Internet browsing) است. مشتری زمانی که به منبعی نیاز دارد با استفاده از API با سرور تماس می گیرد. توسعه دهندگان API باید در مستندات خود ، روش استفاده از REST API را به مشتری ارائه کنند. مراحل کلی برای هر تماس REST API به شرح زیر است:
- کلاینت، درخواستی را به سرور ارسال می کند. در اینجا کلاینت از مستندات API پیروی می کند تا درخواست را به گونه ای قالب بندی کند که سرور بفهمد.
- سرور، کلاینت را احراز هویت می کند و تأیید می کند که حق دارد آن درخواست را ارائه دهد.
- سرور، درخواست را دریافت کرده و آن را به صورت داخلی پردازش می کند.
- سرور، پاسخی را به مشتری برمی گرداند. پاسخ حاوی اطلاعاتی است که به مشتری می گوید آیا درخواست موفقیت آمیز بوده است یا خیر. پاسخ همچنین شامل هر گونه اطلاعاتی است که مشتری درخواست کرده است.
جزئیات درخواست و پاسخ REST API بسته به نحوه طراحی API توسط توسعه دهندگان کمی متفاوت است.
درخواست کلاینت RESTful API شامل چه چیزهایی است؟
API های RESTful به درخواست هایی نیاز دارند که شامل اجزای اصلی زیر باشند:
شناسه منحصر به فرد منبع (Unique Resource Identifier)
سرور هر منبع را با یک شناسه های منحصر به فرد شناسایی می کند. برای سرویس های REST، سرور معمولاً با استفاده از یک آدرس URL شناسایی منبع را انجام می دهد. URL مسیر منبع را مشخص می کند و مشابه آدرس وب سایتی است که برای بازدید از هر صفحه وب در مرورگر خود وارد می کنید. URL در واقع نقطه نهایی درخواست است و به وضوح، نیازهای کلاینت را برای سرور مشخص می کند. نتیجه این که هر مرکز برای ارائه خدمات وب خود از طریق REST باید آدرس URL خدمات خود را به شکل مستند به مشتری ارائه دهد.
متد (Method)
توسعه دهندگان اغلب API های RESTful را با استفاده از پروتکل HTTP پیاده سازی می کنند. یک متد HTTP به سرور می گوید که باید چه کاری با منبع انجام دهد. پنج متد رایج HTTP اینها هستند:
GET
کلاینت ها از GET برای دسترسی به منابعی که در URL معین در سرور قرار دارند استفاده می کنند. آنها می‌توانند درخواست‌های GET را ذخیره کنند و پارامترهایی را در درخواست RESTful API ارسال کنند تا از آن طریق به سرور دستور دهند تا داده‌ها را قبل از ارسال فیلتر کند.
POST
کلاینت ها از POST برای ارسال داده ها به سرور استفاده می کنند. آنها با این درخواست شکل نمایش داده ها را نیز تعیین می کنند. توجه کنید که با ارسال مکرر یک درخواست POST مشابه، منبع مورد نظر به شکل تکراری ایجاد می شود.
PUT
کلاینت ها از PUT برای به روز رسانی منابع موجود روی سرور استفاده می کنند. برخلاف POST، ارسال مکرر یک درخواست PUT مشابه در یک وب سرویس RESTful نتیجه یکسانی دارد.
PATCH
این متد همانند PUT برای بروزرسانی منابع موجود در سرور استفاده می شود با این تفاوت که می تواند بخشی از اطلاعات منبع را بروزرسانی کند.
DELETE
کلاینت ها از درخواست DELETE برای حذف منبع استفاده می کنند. درخواست DELETE می تواند وضعیت سرور را تغییر دهد. با این حال، اگر کاربر احراز هویت مناسب نداشته باشد، درخواست با شکست مواجه می شود.
هدرهای HTTP
هدرها فهرستی از فراداده های به فرمت رشته حرفی هستند که در هر درخواست و پاسخ بین کلاینت و سرور رد و بدل می شوند. این هدرها معمولا برای کاربر نهایی نامرئی هستند و فقط توسط سرور یا برنامه کلاینت، پردازش و ثبت می شوند. محتوای هدرها شامل یک سری Data و پارامتر هاست :
DATA
درخواست‌های REST API ممکن است شامل داده‌هایی برای POST، PUT، و سایر متد‌های HTTP باشد تا با موفقیت کار کنند.
پارامترها
درخواست‌های RESTful API می‌توانند شامل پارامترهایی باشند که به سرور جزئیات بیشتری درباره کارهایی که باید انجام شود می‌دهد. در زیر انواع مختلفی از پارامترها وجود دارد:
- پارامترهای مسیر که جزئیات URL را مشخص می کند.
- پارامترهای پرس و جو (Query) که اطلاعات بیشتری در مورد منبع درخواست می کنند.
- پارامترهای کوکی که مشتریان را به سرعت احراز هویت می کند.
یک نمونه از درخواست GET در شکل زیر نمایش داده شده است. در این مثال، سطرهای مربوط به هدر را پس از دستور GET مشاهده می کنید:
روش های احراز هویت RESTful API چیست؟
یک وب سرویس RESTful قبل از اینکه بتواند پاسخی ارسال کند باید درخواست ها را احراز هویت کند. احراز هویت فرآیند تأیید هویت است. برای مثال می توانید هویت خود را با نشان دادن کارت شناسایی یا گواهینامه رانندگی ثابت کنید. در اینجا نیز به طور مشابه، مشتریان سرویس RESTful باید هویت خود را برای ایجاد اعتماد به سرور ثابت کنند.
RESTful API دارای چهار روش رایج احراز هویت است:
احراز هویت HTTP
HTTP برخی از روشهای احراز هویت را تعریف می‌کند که می‌توانید مستقیماً هنگام اجرای REST API از آنها استفاده کنید. دو مورد از این طرح ها به شرح زیر است:
Basic authentication
در احراز هویت Basic، کلاینت نام کاربری و رمز عبور را در هدر درخواست ارسال می کند. آنها را با base64 رمزگذاری می کند، که یک تکنیک رمزگذاری است.
Bearer authentication
اصطلاح احراز هویت Bearer به فرآیند دادن کنترل دسترسی به توکن اشاره دارد. توکن معمولاً یک رشته رمزگذاری شده از کاراکترها است که سرور در پاسخ به درخواست ورود ایجاد می کند. سپس کلاینت، این توکن را در هدرهای درخواست به سرور ارسال می کند.
کلیدهای API
کلیدهای API گزینه دیگری برای احراز هویت REST API هستند. در این رویکرد، سرور یک مقدار تولید شده منحصر به فرد را به یک کلاینت برای اولین بار اختصاص می دهد. هر زمان که مشتری سعی می کند به منابع دسترسی پیدا کند، از کلید منحصر به فرد API برای تأیید خود استفاده می کند. کلیدهای API از امنیت کمتری برخوردار هستند زیرا کلاینت باید کلید را منتقل کند که این امر آن را در برابر سرقت شبکه آسیب پذیر می کند.
OAuth
OAuth رمزهای عبور و توکن ها را برای دسترسی بسیار امن به سیستم ترکیب می کند. در این روش، سرور ابتدا یک رمز عبور درخواست می کند و سپس برای تکمیل فرآیند احراز هویت، یک رمز اضافی درخواست می کند. با این روش، سرور می تواند در هر زمان، توکن را با دامنه و طول عمر مشخص چک کند.
پاسخ سرور RESTful API شامل چه محتوایی است؟
طبق اصول REST پاسخ سرور باید شامل اجزای اصلی زیر باشد:
سطر وضعیت (Status line)
سطر وضعیت شامل یک کد وضعیت سه رقمی است که موفقیت یا عدم موفقیت درخواست را به اطلاع می رساند. به عنوان مثال، کدهای 2XX نشان دهنده موفقیت هستند، اما کدهای 4XX و 5XX نشان دهنده خطا هستند. کدهای 3XX نشان دهنده تغییر مسیر URL هستند.
در زیر برخی از کدهای وضعیت رایج آمده است:
200: پاسخ موفقیت عمومی
201: پاسخ موفقیت آمیز متد POST
400: درخواست نادرست است و سرور قادر به پردازش آن نیست
404: منبع یافت نشد
بدنه ی پیام (Message body)
بدنه پاسخ حاوی نمایش منبع است. سرور یک قالب نمایش مناسب را بر اساس آنچه هدرهای درخواست در بر دارند انتخاب می کند. کلاینت ها می‌توانند اطلاعاتی را در قالب‌های XML یا JSON درخواست کنند که نحوه نوشتن داده‌ها به فرمت متن ساده را تعیین می‌کند. به عنوان مثال، اگر مشتری نام و سن شخصی به نام جان را درخواست کند، سرور یک نمایش JSON را به صورت زیر برمی گرداند:
'{name":"John", "age":30"}'
هدرها (Headers)
پاسخ سرور، حاوی هدر شامل اطلاعات تکمیلی در مورد پاسخ است. اطلاعاتی مانند سرور، نوع رمزگذاری، تاریخ، نوع محتوا و ... در شکل زیر یک نمونه از هدرهای پاسخ به یک درخواست GET را مشاهده می کنید:
