REST API and RESTFul API

وقتی صحبت از 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 یکنواخت دست یابند:

• شناسایی منابع (Identification of resources)

اینترفیس (Interface) باید به طور منحصر به فرد هر منبع (resource) درگیر در تعامل بین کلاینت و سرور را شناسایی کند.

• دستکاری منابع( Manipulation of resources through representations)
• منابع باید نمایش یکنواختی (uniform representations) در پاسخ (Response) سرور داشته باشند. استفاده کنندگان API باید از این نمایش ها برای تغییر وضعیت (State) منابع در سرور استفاده کنند.
• پیام های خود توصیفی (Self-descriptive messages)

هر resource representation باید حاوی اطلاعات کافی برای توصیف نحوه پردازش پیام باشد. همچنین باید اطلاعات اقدامات اضافی را که کلاینت می‌تواند روی منبع انجام دهد ارائه کند.

• هایپر مدیا به عنوان موتور حالت برنامه (Hypermedia as the engine of application state)

کلاینت باید فقط 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 در نظر گرفته می‌شود.

منبع چیست؟ (What is a Resource)

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

هر منبع دارای یک شناسه منحصربه‌فرد (Unique Identifier) است. شناسه می‌تواند یک نام یا یک عدد باشد.

وضعیت منبع، در هر زمان خاص، به عنوان نمایش منبع شناخته می‌شود.

چرا از REST استفاده کنیم؟

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