آشنایی کامل با REST API

آشنایی با REST API

ما قبلا در رابطه با API ها صحبت کرده ایم و می دانیم که کارایی آن ها چیست. در واقع آشنایی با مبحث این مقاله که REST API ها هستند نیاز به آشنایی با API ها می باشد. به همین دلیل پیشنهاد می کنم قبل از شروع این مقاله، به مقاله ی «API چیست؟» سری بزنید.

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

Client (به معنی کاربر یا مشتری): کلاینت ما همان کاربر یا نرم افزاری است که از API استفاده می کند. به طور مثال اگر شما با استفاده از API توییتر اطلاعاتی را دریافت کرده و تغییر دهید، توییت کنید و یا هر کار دیگری انجام دهید، اینجا کلاینت شما هستید. از طرفی اگر با مرورگر خود به وب سایت توییتر بروید، مرورگر درخواستی را به API توییتر ارسال کرده و اطلاعات آن را برایتان نمایش می دهد. در اینجا کلاینت مرورگر شما است.
Resource (به معنی منبع): resource یعنی هر شیء ای که API اطلاعاتی را راجع به آن ارائه دهد. به طور مثال در API اینستاگرام، یک کاربر، یک عکس، یک هشتگ و... همگی resource هستند. تمامی resource ها دارای شناسه ی یکتا می باشند که یا عدد است و یا یک نام خاص.

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

در واقع REST مخفف REpresentational State Transfer (به معنی «انتقال وضعیت نماینده») است. یعنی زمانی که یک RESTful API صدا زده می شود، سرور نماینده ای (representational) از state یا همان وضعیتِ resource درخواست شده را به سمت client ارسال می کند. «وضعیتِ نماینده» یعنی اطلاعاتی راجع به وضعیت فعلی یک resource که نماینده ی آن resource هستند (چرا که ما خود resource را به کسی ارسال نمی کنیم بلکه برخی از اطلاعات را ارسال می نماییم). بگذارید این مسئله را در قالب یک مثال توضیح دهم.

زمانی که یک توسعه دهنده API اینستاگرام را صدا می زند تا کاربر خاصی (resource) را دریافت کند، API وضعیت کاربر را بر می گرداند، یعنی نام کاربری، تعداد پست ها، تعداد فالوئرها و غیره. این اطلاعات نماینده ای از وضعیت یک resource هستند و معمولا در قالب JSON ارسال می شوند (گرچه می توانند در قالب XML یا حتی HTML نیز باشند).

اینکه سرور هنگام صدا زده شدن توسط client چه کاری انجام دهد به دو مورد ارسال توسط شما بستگی دارد:

یک identifier (شناسه: مقداری برای شناسایی) برای resource مورد نظر خود. این مقدار همان URL مربوط به resource است که در این زمینه endpoint یا «نقطه ی پایانی» خوانده می شود. احتمالا می دانید که URL مخفف Uniform Resource Locator (به معنی «مکان یاب یکپارچه منبع») است مگر نه؟
عملیاتی که می خواهید توسط سرور روی این resource انجام شود. این عملیات معمولا از نوع HTTP است (عملیات هایی مانند GET و POST و PUT و DELETE).

بر این اساس اگر بخواهیم اطلاعات کاربر خاصی را از API توییتر دریافت کنیم باید یک شناسه (identifier – در اینجا همان URL) برای resource (کاربر) داشته باشیم تا کاربر مشخص شود و سپس متد GET را نیز صدا بزنیم. در واقع API توییتر از نام کاربری برای شناسایی resource ها استفاده می کند. به طور مثال اگر URL ای به شکل www.twitter.com/jk_rowling داشته باشیم و بخواهیم اطلاعات این کاربر (خانم جی کی رولینگ، نویسنده ی داستان های هری پاتر) را دریافت کنیم باید از قسمت jk_rowling که نام کاربری ایشان می باشد استفاده کنیم. در توییتر مانند بسیاری از شبکه های اجتماعی هیچ دو نفری پیدا نمی شوند که نام کاربری یکسانی داشته باشند.

هر برنامه ی RESTful باید دارای شش constraint (به معنی «قید») باشد. این قید ها همان قوانینی هستند که هنگام ساخت API باید از آن ها پیروی کنیم:

Uniform interface (اینترفیس یکپارچه)
Client — server separation (انفصال کلاینت و سرور)
Stateless (بی وضعیتی – بدون state)
Layered system (سیستم لایه دار)
Cacheable (کش پذیر بودن)
Code-on-demand (در دسترس بودن لحظه ای)

من تک تک این موارد را به صورت خلاصه توضیح می دهم.

Uniform interface

این قسمت چهار زیر مجموعه دارد:

درخواست ارسال شده به سمت سرور باید دارای شناسه ی resource باشد.
اطلاعات برگشت داده شده از سمت سرور آنچنان وسیع باشد که client بتواند resource را تغییر بدهد.
هر درخواستی به سمت API باید شامل تمامی اطلاعات مورد نیاز سرور برای انجام عملیات باشد و همچنین پاسخ ارسال شده توسط سرور نیز باید شامل تمامی اطلاعات عملیات باشد به طوری که client متوجه پاسخ بشود.
Hypermedia (فرا رسانه) به عنوان موتور وضعیت برنامه: ممکن است این مورد برایتان عجیب باشد بنابراین بگذارید ساده تر توضیح بدهم. منظور من از Hypermedia یا فرا رسانه همان لینک هایی است که سرور درون پاسخ قرار می دهد. تمام جمله ی بالا یعنی سرور باید client را از روش های تغییر resource نیز مطلع کند. به طور مثال اگر client در مورد کاربر خاصی اطلاعاتی را درخواست کرد علاوه بر اطلاعات کاربر، اطلاعاتی راجع به نحوه ی تغییر این resource (مثلا نام کاربر) نیز توسط سرور به client ارسال شود. برای کسب اطلاعات بیشتر در این مورد به این ویدیو در یوتیوب مراجعه کنید.

نتیجه ی استفاده از اینترفیس یکپارچه این است که درخواست ها، از هر client ای ارسال شوند (مرورگر کروم، سرور لینوکسی، اسکریپت پایتون، برنامه اندرویدی و ...)، یکسان هستند.

Client — server separation

در RESTful API ها client و سرور مستقل از یکدیگر عمل می کنند. تعامل بین این دو نیز فقط در فرم درخواست هایی است که از client به سرور ارسال شده و پاسخ هایی که سرور به client برمی گرداند. تعامل بین سرور و client همیشه با یک درخواست از سمت client شروع می شود، یعنی سرور همیشه منتظر درخواست ها است و از جلوی خودش هیچ اطلاعاتی را ارسال نمی کند.

Stateless

نبود state یا وضعیت در اینجا بدین معنی است که سرور هیچ چیزی در مورد کاربری که از API استفاده کرده است به خاطر ندارد. سرور به یاد ندارد که آیا کاربر قبلا درخواست GET ای را برای یک resource خاص ارسال کرده بوده است یا خیر. سرور به یاد ندارد که کاربر قبلا چه resource هایی را درخواست کرده است. به همین دلیل است که در هر درخواست باید تمامی اطلاعات مورد نیاز سرور (مثل شناسه) را ارسال کنیم. این مسئله بدین معنی است که اگر یک درخواست را 10 بار تکرار کنیم، 10 بار جواب می گیریم.

Layered system

ممکن است بین client ای که درخواست را ارسال می کند و سروری که پاسخ را برمی گرداند، سرورهای مختلفی وجود داشته باشند؛ یک سرور به عنوان لایه ای امنیتی، یک سرور به عنوان لایه ی cache، یک سرور به عنوان و غیره. هیچ کدام از این لایه ها نباید درخواست اصلی یا پاسخ آن را تغییر بدهند. در چنین سیستمی، client از وجود سرور های میانجی بی خبر است.

Cacheable

کش پذیر بودن در این زمینه یعنی داده های ارسال شده توسط سرور دارای اطلاعاتی باشند که مشخص کند این داده ها کش پذیر هستند یا خیر. اگر داده ها کش پذیر باشند، احتمالا دارای version number (شماره نسخه) هستند که کش پذیر شدن را ممکن می سازد. از آنجایی که client می داند کدام نسخه یا ورژن از داده ها را دارد (این اطلاعات را از درخواست قبلی دریافت کرده است) می تواند از ارسال درخواست های تکراری و چند باره جلوگیری کند.

Code-on-demand

این قید که قید آخر ما است، اختیاری می باشد و اگر برنامه ی شما code on demand (به معنی لفظی «کد هنگام درخواست» یا «کد هنگام نیاز») نداشته باشد باز هم RESTful محسوب می شود. این قابلیت یعنی Client بتواند از سرور درخواست کد بکند و پاسخ ارسالی از سمت سرور نیز دارای کد هایی باشد که client بتواند آن را اجرا کند. معمولا در مواقعی که پاسخ سرور در قالب HTML است، کد های ارسالی به صورت یک اسکریپت هستند.

امیدوارم با مفهوم RESTful API ها آشنا شده باشید.