فصل چهارم

(API (Application Programming Interfaces

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

API ها چیست؟

API ها یا Application Programming Interfaces مجموعه ای از پروتکل ها، ابزارها و تعاریف هستند که به نرم افزارهای مختلف اجازه می دهند تا با یکدیگر ارتباط برقرار کنند. آنها توسعه دهندگان را قادر می سازند تا به عملکردهای داخل یا خارج از محیط خود دسترسی داشته باشند بدون اینکه نیازی به درک یا بازسازی آنها از ابتدا داشته باشند. این شبیه به استفاده از اجزای آماده در ساخت و ساز است که به طور قابل توجهی روند ساخت سازه های پیچیده را ساده می کند.

انواع API ها

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

1. APIهای باز (Public API): اینها برای هر توسعه‌دهنده‌ای برای استفاده با حداقل محدودیت در دسترس هستند. ممکن است رایگان باشند یا نیاز به اشتراک داشته باشند. APIهای باز برای به اشتراک گذاری داده ها و خدمات با جامعه توسعه دهندگان گسترده تر هستند، اما معمولاً دسترسی محدودی به منابع برای اطمینان از امنیت و مدیریت بار ارائه می دهند.
2. API های شریک (Partner APIs): همانطور که از نام آن پیداست، API های شریک در معرض شرکای تجاری استراتژیک قرار دارند. آنها به حقوق و مجوزهای خاصی برای دسترسی و ارائه یک محیط کنترل شده برای به اشتراک گذاری داده ها و عملکردهای حساس یا ارزشمندتر نیاز دارند.
3. APIهای داخلی (Private API): این APIها که برای استفاده در یک سازمان طراحی شده اند، عملیات را با امکان برقراری ارتباط سیستم ها یا برنامه های مختلف در یک سازمان با یکدیگر ساده می کنند. آنها در معرض عموم قرار نمی گیرند و سطح بالایی از امنیت و کنترل را تضمین می کنند.
4. API های ترکیبی (Composite APIs): ترکیبی از API های مختلف هستند که برای انجام یک کار یا حل یک مشکل پیچیده با هم کار می کنند. APIهای ترکیبی به توسعه‌دهنده اجازه می‌دهند تا چندین تماس API را در یک تماس جمع کند، بار سرور را کاهش دهد، کد مشتری را ساده‌تر کند و عملکرد برنامه را بهبود بخشد.

معماری API

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

معماری یک API نحوه برقراری ارتباط، سطح امنیتی که ارائه می دهد، کارایی آن در مدیریت داده ها و سهولت یکپارچه سازی آن را تعیین می کند. از REST و SOAP پرکاربرد گرفته تا GraphQL و gRPC تخصصی، هر معماری جای خود را در جعبه ابزار توسعه دهنده دارد.

SOAP) Simple Object Access Protocol)

SOAP یا Simple Object Access Protocol سنگ بنای دنیای معماری های API است که برای اطمینان از قابلیت همکاری و تبادل یکپارچه داده در سیستم های مختلف طراحی شده است. SOAP با رعایت مجموعه ای از قوانین جهانی، تعامل قابل اعتماد بین برنامه های کاربردی سرویس گیرنده و سرور را بدون توجه به پشته فناوری زیربنایی آنها تسهیل می کند. در اینجا، ما به نکات ضروری SOAP می پردازیم، ویژگی های آن، موارد استفاده، و تعادل مزایا و معایب آن را برجسته می کنیم.

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

ویژگی های کلیدی SOAP

• مبتنی بر XML: پیام های SOAP در XML ساخته می شوند، یک زبان نشانه گذاری همه کاره که تضمین می کند پیام ها در سیستم های مختلف قابل درک هستند.

• پهنای باند فشرده: به دلیل ساختار دقیق پیام، SOAP پهنای باند بیشتری را در مقایسه با سایر سبک‌های API مصرف می‌کند و داده‌های گسترده‌ای را در پیام‌های خود جای می‌دهد.

• ناسازگاری با REST :REST و SOAP سبک های معماری متفاوتی هستند که هر کدام رویکرد منحصر به فرد خود را در طراحی و تعامل API دارند. استانداردها و ساختارهای SOAP با اصول RESTful همخوانی ندارند.

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

SOAP در سناریوهایی که سطوح بالایی از امنیت، قابلیت اطمینان و ارتباطات رسمی را می طلبد می درخشد. مناسب بودن آن به برنامه های مختلف گسترش می یابد:

• عملیات همزمان: ایده آل برای برنامه هایی که نیاز به تبادل داده های قابل اعتماد و پردازش بلادرنگ دارند.

• ارتباطات رسمی: زمانی که قالب‌های پیام از پیش تعریف‌شده و سخت‌گیرانه برای مبادلات سرور و مشتری ضروری باشد.

• عملیات Stateful: SOAP از برنامه هایی پشتیبانی می کند که نیاز به حفظ متن یا حالت در چندین درخواست دارند.

نمونه ای از SOAP API

یک مثال پیام SOAP ساختار آن را نشان می‌دهد، از جمله یک اعلان فضای نام، سرصفحه‌های ابرداده و بدنه حاوی درخواست.

 

<?xml version=”1.0″?>
<soap:Envelope xmlns:soap=”https://www.example.com/soap-envelope/” soap:encodingStyle=”http://www.example.com/soap-encoding”>
 <soap:Header>
   <m:Trans xmlns:m=”https://www.example.com/transaction/” soap:mustUnderstand=”1″>bcd</m:Trans>
 </soap:Header>
 <soap:Body>
   <m:GetEmployee xmlns:m=”https://www.example.com/prices”>
     <m:EName>Joe</m:EName>
   </m:GetEmployee>
 </soap:Body>
</soap:Envelope>

 
 

مزایا و معایب SOAP

مزایا:

• یکپارچه سازی WSDL: از زبان توصیف خدمات وب (WSDL) برای مستندسازی دقیق خدمات وب، افزایش مصرف و توسعه API استفاده می کند.

• توسعه پذیر: سازگار با افزونه های متعدد (مانند WS-Security، WS-Federation)، ایجاد برنامه های کاربردی بسیار کاربردی و ایمن را تسهیل می کند.

• Protocol Agnostic: روی چندین پروتکل حمل و نقل (HTTP، SMTP، TCP) کار می کند و آن را برای موارد استفاده مختلف همه کاره می کند.

معایب:

• سربار عملکرد: استفاده از XML برای انتقال داده ها به دلیل ماهیت پرمخاطب آن، نگرانی های عملکردی را ایجاد می کند.

• نحو پیچیده: اتکای SOAP به XML و نحو پیچیده آن می‌تواند استخراج داده‌ها را پیچیده و زمان‌بندی توسعه را طولانی کند.

بی‌طرفی پروتکل، ویژگی‌های امنیتی و پشتیبانی از قابلیت اطمینان تراکنشی SOAP، آن را به گزینه‌ای قوی برای برنامه‌های کاربردی در سطح سازمانی تبدیل می‌کند که در آن این ویژگی‌ها بسیار مهم هستند. با این حال، سربار عملکرد و پیچیدگی نحوی آن نشان می‌دهد که قبل از پذیرش، به‌ویژه برای برنامه‌هایی که کارایی و سادگی در آن‌ها اهمیت دارد، به دقت توجه شود. SOAP یک معماری API محوری باقی می‌ماند که تعادلی بین عملکرد جامع و الزامات یکپارچه‌سازی سیستم پیچیده را در بر می‌گیرد.

REST) Representational State Transfer)

REST، مخفف Representational State Transfer، یک رویکرد معماری متمایز را برای طراحی API اتخاذ می کند. این الگویی است که به طور گسترده در برنامه های کاربردی وب مدرن استفاده می شود و روشی انعطاف پذیر و کارآمد برای مدیریت اجزای مختلف برنامه مانند فایل ها، اشیاء و رسانه ها ارائه می دهد. API های REST عملکرد را بر روی HTTP تسهیل می کنند و از افعال HTTP مانند GET و POST برای پشتیبانی از قابلیت همکاری در سراسر وب استفاده می کنند و آنها را به انتخابی ارجح برای بسیاری از توسعه دهندگان تبدیل می کند.

موارد استفاده ایده آل برای REST

REST ارزش خود را در سناریوهایی ثابت می کند که پهنای باند محدود است، عملیات بدون حالت مورد نیاز است، کش بسیار مهم است، و سرعت توسعه ضروری است:

• پهنای باند محدود: اگر با محدودیت‌های پهنای باند کار می‌کنید، فرمت تبادل داده سبک REST (معمولاً JSON) بسیار کارآمدتر از XML پرمخاطب مورد استفاده در پیام‌های SOAP است.

• عملیات بدون حالت: REST برای ارتباطات بدون حالت طراحی شده است، و برای تراکنش هایی که نیازی به یادآوری تعاملات قبلی از سوی سرور ندارند، مناسب است.

• حجم بالای درخواست ها: امکان ذخیره درخواست ها با REST نیاز به تماس های مکرر باطن را کاهش می دهد و عملکرد و سرعت توسعه را افزایش می دهد.

• سادگی و سرعت در توسعه: رویکرد ساده REST و نگاشت مستقیم به افعال HTTP، فرآیند کدگذاری را ساده می‌کند و چرخه‌های توسعه سریع‌تر را ممکن می‌سازد.

مزایا و معایب REST:

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

• معایب:
  • عدم استانداردسازی: بدون استانداردهای پذیرفته شده جهانی، پیاده سازی REST می تواند متفاوت باشد و به طور بالقوه توسعه و یکپارچه سازی API را پیچیده کند.
  • محدودیت HTTP: همراهی محکم با HTTP می‌تواند REST را در محیط‌هایی که ممکن است پروتکل‌های ارتباطی جایگزین ترجیح داده شوند، محدود کند.

روش های REST API و ساختار درخواست

هر درخواست REST شامل چهار بخش اساسی است: یک روش HTTP، یک نقطه پایانی، هدرها و یک بدنه.

یک روش HTTP توصیف می کند که با یک منبع چه کاری باید انجام شود. چهار روش اساسی وجود دارد که عملیات CRUD نیز نامیده می شود:

• POST برای ایجاد یک منبع پست کنید،

• Get دریافت یک منبع،

• PUT قرار دادن برای به روز رسانی یک منبع، و

• DELETE برای حذف یک منبع.

یک نقطه پایانی (Endpoint) حاوی یک شناسه منبع یکنواخت (URI) است که نشان می دهد کجا و چگونه منبع را در اینترنت پیدا کنید. متداول ترین نوع URI یک مکان منبع منحصر به فرد (URL) است که به عنوان یک آدرس وب کامل عمل می کند.

هدرها (Headers) اطلاعات مربوط به مشتری و سرور را ذخیره می کنند. به طور عمده، هدرها داده‌های احراز هویت را ارائه می‌کنند – مانند یک کلید API، نام یا آدرس IP رایانه‌ای که سرور در آن نصب شده است، و اطلاعات مربوط به فرمت پاسخ.

یک بدنه (Body) برای انتقال اطلاعات اضافی به سرور استفاده می شود. به عنوان مثال، ممکن است بخشی از داده باشد که می خواهید اضافه یا جایگزین کنید.

ساختار پاسخ REST

در پاسخ، سرور نه خود منبع مورد نظر، بلکه نمایش آن را می فرستد – یک توصیف قابل خواندن توسط ماشین از وضعیت فعلی آن. یک منبع را می توان در قالب های مختلف نشان داد، اما محبوب ترین آنها XML و JSON هستند.

هر زمان که مرتبط باشد، یک سرور در پاسخ، هایپرلینک ها یا ابررسانه هایی را که به منابع مرتبط دیگر پیوند می دهند، شامل می شود. به این ترتیب، سرور دستورالعمل هایی را در مورد کارهای بعدی که مشتری می تواند انجام دهد و درخواست های بعدی را ارائه می دهد.

نمونه ای از تماس REST API

سناریویی را در نظر بگیرید که در آن باید جزئیات یک کاربر را با استفاده از REST API فچ (فچ کردن) کنید. عملیات را می توان به صورت زیر ساختار داد:

Request:

GET https://api.example.com/users?name=JohnDoe

Response:

{

“name”: “John Doe”,

“location”: “New York”,

“title”: “Software Developer”,

“joinYear”: 2015

}

این مثال یک تماس REST API را نشان می‌دهد که در آن مشتری جزئیات کاربر را با یک درخواست GET درخواست می‌کند و سرور با اطلاعات کاربر در قالب JSON پاسخ می‌دهد.

REST در مقابل SOAP: ملاحظات عملکرد

REST اغلب از نظر سرعت و کارایی از SOAP پیشی می‌گیرد، زیرا ماهیت کمتر دست و پا گیر آن، اتکا به JSON (که معمولاً سبک‌تر از XML است) و توانایی آن در کش کردن داده‌ها. SOAP با مشخصات سختگیرانه و ویژگی های امنیتی خود، ذاتاً پیچیده تر و پرمخاطب تر است که منجر به استفاده از پهنای باند بیشتر و عملکرد کندتر در سناریوهایی می شود که REST می تواند کافی باشد.

به طور خلاصه، APIهای REST یک رویکرد انعطاف‌پذیر، کارآمد و توسعه‌دهنده را برای ساخت سرویس‌های وب ارائه می‌کنند، به خصوص زمانی که عملکرد، سادگی و سرعت بسیار مهم هستند. توانایی آنها برای کار بر روی HTTP، پشتیبانی از فرمت های مختلف داده، و ارتباطات بدون حالت، آنها را برای طیف گسترده ای از برنامه های کاربردی وب مناسب می کند. با این حال، درک زمان و مکان استفاده از REST، بر خلاف معماری های دیگر مانند SOAP، کلیدی برای استفاده از پتانسیل کامل آن است.

🔑 نکات کلیدی

📝 آزمون / Quiz