API در برنامه نویسی ( بخش دوم )

API در برنامه نویسی شاید قدمتی طولانی نداشته باشد اما API ها در اوایل محاسبات، دقیقاً قبل از رایانه شخصی ظهور کردند. در آن زمان، معمولاً از API به عنوان کتابخانه ای برای سیستم عامل ها استفاده می شد. API تقریباً همیشه بخشی از سیستمی بود که روی آن کار می شد، اگرچه گاهی اوقات پیام هایی را بین رایانه های اصلی ارسال می کرد. پس از نزدیک به 30 سال، API ها از محیط محلی خود خارج شدند. در اوایل سال 2000، آنها در حال تبدیل شدن به یک فناوری مهم برای ادغام از راه دور داده ها بودند.

API های از راه دور

API های از راه دور برای تعامل از طریق یک شبکه ارتباطی طراحی شده اند. منظور ما از “از راه دور” این است که منابعی که توسط API دستکاری می شوند در جایی خارج از رایانه فعلی درخواست می دهند. از آنجا که پرکاربردترین شبکه ارتباطی، اینترنت است، بیشتر API ها براساس استانداردهای وب طراحی می شوند. همه API های از راه دور API های وب نیستند، اما فرض بر این است که API های وب از راه دور هستند.

استفاده از HTTP

API های وب معمولاً از HTTP برای پیام های درخواستی استفاده می کنند و تعریفی از ساختار پیام های پاسخ ارائه می دهند. این پیام های پاسخ معمولاً به صورت فایل XML یا JSON در می آیند. XML و JSON هر دو قالب ارجح هستند زیرا داده را به روشی ارائه می دهند که دستکاری آن برای سایر برنامه ها آسان است.

برای بهبود API ها چه کاری انجام شده است؟

همزمان با توسعه API ها و همچنین API در برنامه نویسی که اکنون در همه جا موجود است، تلاش های زیادی صورت گرفته است تا طراحی آنها کمی ساده تر و کاربرد آنها بیشتر مفید باشد.

استفاده از SOAP

با گسترش API های وب، یک مشخصات پروتکل برای کمک به استاندارد سازی تبادل اطلاعات ایجاد شد؛ پروتکل دسترسی به اشیا ساده، که بیشتر به عنوان SOAP شناخته می شود. API های طراحی شده با SOAP از XML برای قالب پیام خود استفاده کرده و از طریق HTTP یا SMTP درخواست دریافت می کنند. SOAP اشتراک برنامه ها را برای برنامه هایی که در محیط های مختلف اجرا می شوند یا به زبان های مختلف نوشته شده اند آسان می کند.

مشخصات دیگر انتقال نمایندگی دولت (REST) ​​است. به API های وب که به محدودیت های معماری REST پایبند هستند، RESTful API گفته می شود.

تفاوت REST با SOAP به روشی اساسی:

SOAP یک پروتکل است، در حالی که REST یک سبک معماری است. این بدان معنی است که هیچ استاندارد رسمی برای RESTful web API ها وجود ندارد. API ها تا زمانی که با 6 محدودیت راهنمای یک سیستم RESTful مطابقت داشته باشند، RESTful هستند:

    معماری مشتری-سرور: معماری REST از کلاینت ها، سرورها و منابع تشکیل شده است و درخواست ها را از طریق HTTP رسیدگی می کند.

    بی تابعیتی: هیچ محتوای سرویس گیرنده ای بین درخواستها در سرور ذخیره نمی شود. درعوض، اطلاعات مربوط به حالت جلسه با مشتری ارائه می شود.

    قابلیت Cache: حافظه پنهان می تواند نیاز به برخی از تعاملات مشتری و سرور را از بین ببرد.

    سیستم لایه ای: تعاملات مشتری و سرور می تواند توسط لایه های اضافی واسطه شود. این لایه ها می توانند ویژگی های اضافی مانند تعادل بار، حافظه نهان مشترک، یا امنیت را ارائه دهند.

    Code on demand (اختیاری): سرورها می توانند با انتقال کد اجرایی، عملکرد مشتری را افزایش دهند.

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

        شناسایی منابع در درخواست ها: منابع در درخواست ها مشخص می شوند و از نمایندگی های ارسالی به مشتری جدا هستند.

        دستکاری منابع از طریق نمایش ها: مشتری ها پرونده هایی را دریافت می کنند که معرف منابع هستند. این نمایش ها باید اطلاعات کافی برای اجازه اصلاح یا حذف داشته باشند.

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

        Hypermedia به عنوان موتور حالت كاربرد: پس از دستیابی به منبعی، مشتری REST باید بتواند از طریق پیوندها سایر اقدامات موجود را كه در حال حاضر در دسترس هستند، كشف كند.

این محدودیت ها ممکن است زیاد به نظر برسند اما بسیار ساده تر از پروتکل تجویز شده هستند. به همین دلیل RESTful API ها بیشتر از SOAP شیوع پیدا می کنند.

سخن پایانی

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

منبع