وقتی صحبت از API میشه معمولا صحبت از Web APIs میکنیم. REST یکی از متدهای Web API هستش که برای برقراری ارتباط بین کلاینت و سرور استفاده میشه.
REST مخفف عبارت Representational State Transfer است مانند سایر سبک های معماری، REST دارای اصول و محدودیت هایی است. اگر یک API به عنوان RESTful نامیده شود، باید به این اصول پایبند باشد.
اگر نمیدونید HTTP چیه و قواعدش چجوری هست قبلا از خوندن ادامه این پست حتما در موردش مطالعه کنید.
در ادامه کلمات فارسی رو میخونید که قطعا گیج کننده هستند. هرچی گشتم نتونستم معادل مناسب پیدا کنم و پس از ترجمه لغوی استفاده کردم که بنظر میرسه ترجمه خیلی اشتباهی هم نیست. تلاش کردم بطور مجزا منظورم رو از هر کلمه یا اصطلاحی که گیج کننده هست رو توضیح بدم. پس اگر کلمه یا اصطلاحی رو متوجه نشدید کمی پایینترش توضیح را داده ام.
REST یک معماری است، نه یک پروتکل یا یک استاندارد. توسعه دهندگان API می توانند REST را به روش های مختلفی پیاده سازی کنند.
REST معمولاً توسط افراد در سیستم های وب برای تعامل با یکدیگر استفاده می شود. به عنوان مثال، بازیابی و به روز رسانی اطلاعات حساب در توییتر.
REST APIها را می توان تقریباً با استفاده از هر زبان برنامه نویسی توسعه داد و از انواع فرمت های داده پشتیبانی می کند. تنها شرط لازم این است که آنها با شش اصل طراحی REST زیر همسو شوند - که به عنوان محدودیت های معماری نیز شناخته می شوند:
همه ارتباطات دارای REST API باید بدون حالت باشند. این بدان معنی است که هر تعاملی مستقل است و هر Request و Response تمام اطلاعات مورد نیاز برای تکمیل تعامل را داخل خود دارند. هر درخواست کلاینت توسط سرور به عنوان یک درخواست کاملاً جدید تفسیر می شود و سرور چیزی در مورد درخواستهای گذشته به خاطر نمیآورد.
رابط یکنواخت برای طراحی هر REST اساسی است. این نشان می دهد که سرور اطلاعات را در قالبی استاندارد منتقل می کند. منبع در فرمتی خاص یک representation در REST نامیده می شود. این فرمت می تواند با نمایش داخلی منبع در سرور متفاوت باشد. برای مثال، سرور میتواند دادهها را به صورت متن ذخیره کند اما آنها را در قالب نمایش HTML ارسال کند.
چهار محدودیت زیر می توانند به یک رابط REST یکنواخت دست یابند:
اینترفیس (Interface) باید به طور منحصر به فرد هر منبع (resource) درگیر در تعامل بین کلاینت و سرور را شناسایی کند.
هر resource representation باید حاوی اطلاعات کافی برای توصیف نحوه پردازش پیام باشد. همچنین باید اطلاعات اقدامات اضافی را که کلاینت میتواند روی منبع انجام دهد ارائه کند.
کلاینت باید فقط URI اولیه برنامه را داشته باشد. برنامه کلاینت باید به صورت پویا تمامی منابع و تعاملات دیگر را با استفاده از لینک ها هدایت کند.
یک منبع (Resource) میتواند هر چیزی باشد که API امکان فراهمسازی اطلاعاتی را در موردش داشته باشد. به عنوان مثال در API اینستاگرام، منبع میتواند یک کاربر، یک عکس یا یک هشتگ باشد. هر منبع دارای یک شناسه منحصربهفرد (Unique Identifier) است. شناسه میتواند یک نام یا یک عدد باشد.
در طراحی REST API، کلاینت و سرور باید کاملاً مستقل از یکدیگر باشند. تنها اطلاعاتی که کلاینت باید بداند URI منبع درخواستی است. به طور مشابه، سرور نباید کلاینت را به جز ارسال داده های درخواستی به آن از طریق HTTP تغییر دهد.
در صورت امکان، منابع باید در سمت کلاینت یا سرور قابل کش شدن باشند. response های سرور همچنین باید حاوی اطلاعاتی در مورد مجاز بودن ذخیره سازی برای منبع باشد. هدف بهبود عملکرد در سمت کلاینت و در عین حال افزایش مقیاس پذیری در سمت سرور است.
در REST، request ها و response ها از لایه های مختلفی عبور می کنند. به عنوان یک قاعده کلی، فرض نکنید که کلاینت و سرور مستقیماً به یکدیگر متصل می شوند. ممکن است تعدادی واسطه مختلف در حلقه ارتباطی وجود داشته باشد. REST APIها باید طوری طراحی شوند که نه کلاینت و نه سرور نتوانند تشخیص دهند که آیا با برنامه نهایی( سرور با کلاینت / کلاینت با سرور) یا یک واسطه ارتباط برقرار می کند.
کد در صورت تقاضا (Code On Demand) یک اصل اختیاری است. یک API حتی بدون فراهم کردن کد در صورت تقاضا میتواند RESTful در نظر گرفته شود. کلاینت میتواند از سرور درخواست کد بدهد و سپس، پاسخ از سرور حاوی مقداری کُد خواهد بود. وقتی پاسخ در قالب HTML است، معمولاً این پاسخ به صورت یک اسکریپت خواهد بود. پس از دریافت کد، کلاینت میتواند آن را اجرا کند.
اگر یک API به این قوانین پایبند باشد یک RESTful API در نظر گرفته میشود.
مفهوم اطلاعات در REST یک منبع است. هر اطلاعاتی که بتوانیم نام ببریم می تواند منبع باشد. به عنوان مثال، یک منبع REST می تواند یک سند یا تصویر، مجموعه ای از منابع دیگر، یا یک شی غیر مجازی (به عنوان مثال، یک شخص) باشد. در API اینستاگرام، منبع میتواند یک کاربر، یک عکس یا یک هشتگ باشد.
هر منبع دارای یک شناسه منحصربهفرد (Unique Identifier) است. شناسه میتواند یک نام یا یک عدد باشد.
وضعیت منبع، در هر زمان خاص، به عنوان نمایش منبع شناخته میشود.