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

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

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

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

مزایای استفاده از api

با استفاده از APIها می‌توانید برنامه‌های Cloud-native و زیرساخت‌های داخلی را به هم متصل کنید و داده‌های خود را با سایر مشتریان و کاربران بیرونی به اشتراک بگذارید. API‌های عمومی (public)، ارزش کسب‌وکاری منحصربه‌فردی دارند؛ زیرا، می‌توانند نحوه‌ی ارتباط با شریکان و همچنین کسب درآمد بالقوه از داده‌ها را ساده‌تر کنند. مثلا API نقشه گوگل، نمونه‌ی محبوبی از یک API عمومی به حساب می‌آید.

به عنوان مثال، یک شرکت توزیع کتاب را تصور کنید. توزیع‌کننده‌ی کتاب می‌تواند با توسعه‌ی یک برنامه ابری، اجازه دهد تا کارکنان کتاب‌فروشی در دسترس بودن کتاب‌ها را با توزیع‌کننده بررسی کنند؛ اما، توسعه‌ی کامل این برنامه ممکن است به هزینه‌ی زیاد، پلتفرم خاص یا توسعه‌ی طولانی‌مدت و نگهداری مداوم نیاز داشته باشد.

اما در حالتی دیگر، توزیع‌کننده‌ی کتاب می‌تواند از APIهای عمومی جهت بررسی میزان موجودی کتاب استفاده کند. این روش مزیت‌های زیادی دارد:

• دسترسی به داده‌ها از طریق API به کارکنان کتاب‌فروشی کمک می‌کند تا به اطلاعات مربوط به موجودی کتاب‌ها در مکان‌های مشخص دسترسی داشته باشند.
• توزیع‌کننده‌ی کتاب نیز می‌تواند بدون تاثیرگذاری بر روند انجام برنامه، در سیستم‌های داخلی خود تغییراتی ایجاد کند. 
• با استفاده از API‌ عمومی، توسعه‌دهندگان می‌توانند برنامه‌هایی را برای توزیع‌کننده‌ی کتاب، فروشنده‌ی کتاب، خریدار کتاب یا دیگر اشخاص ثالث طراحی کنند تا امکان جستجو یا دسترسی به کتاب‌های موردنظر به راحتی فراهم شود. این امر می‌تواند باعث فروش بیشتر یا فرصت‌های کسب‌وکاری دیگر شود. 

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

سه سیاست‌ اصلی برای انتشار APIها وجود دارد، این سیاست‌ها عبارتند از:

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

نوآوری با API

وقتی APIهای شما در حالت عمومی یا شبکه‌ی همکار باشند، می‌توانید:

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

پیشنهاد می‌کنیم یادداشت «open API چیست؟» را هم بخوانید.

این‌ها بسیار عالی به نظر می‌رسند؛ اما، API‌ها چگونه می‌توانند همه‌ی این کارها را انجام دهند؟

بیایید به مثال شرکت توزیع‌ کتاب برگردیم!

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

حتی ممکن است یک شخص ثالث دیگر با توسعه‌ی یک برنامه و استفاده از یک API عمومی، این امکان را به کاربران خود بدهد تا به جای خرید از کتاب‌فروشی، کتاب موردنظرشان را مستقیماً از توزیع‌کننده‌ی کتاب خریداری کنند. این کار نیز می‌تواند کانال درآمدی جدیدی را برای توزیع‌کننده‌ی کتاب ایجاد کند.

اشتراک‌گذاری API با شرکای منتخب یا کل جهان، می‌تواند تاثیرات مثبتی داشته باشد. هر مشارکتی که در این زمینه داشته باشید، فرآیندهای بازاریابی شما به سرعت گسترش پیدا می‌کند. ایجاد یک فناوری مثل یک API عمومی برای استفاده‌ی همه، توسعه‌دهندگان را ترغیب می‌کند تا اکوسیستمی از برنامه‌های مختلف را به کمک این API‌ها ایجاد کنند. در این حالت، بیشتر افراد از فناوری شما استفاده خواهند کرد و این کار یعنی افراد بیشتری تمایل خواهند داشت تا با شما همکاری داشته باشند.

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

تاریخچه‌ای مختصر از API‌ها

APIها اندکی پیش از رایانه‌های شخصی به وجود آمدند. در آن زمان، معمولاً از API به عنوان کتابخانه‌ای برای سیستم‌عامل‌ها استفاده می‌شد. API‌ها معمولاً به صورت محلی کار می‌کردند و گاهی اوقات نیز پیام‌هایی را بین رایانه‌های اصلی منتقل می‌کردند. پس از گذشت نزدیک به ۳۰ سال، API‌ها از محیط محلی خود خارج شدند و در اوایل دهه ۲۰۰۰، به یک فناوری مهم برای ادغام سیستم‌ها از راه دور تبدیل شدند.

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

APIهای از راه دور طراحی شده‌اند تا از طریق یک شبکه ارتباطی به یکدیگر مرتبط شوند. زمانی که از عبارت «از راه دور» استفاده می‌کنیم، منظورمان این است که منابعی که به وسیله‌ی API مورد استفاده قرار می‌گیرند، در جایی خارج از رایانه‌ای که درخواست را ارسال می‌کند، قرار دارند. به دلیل این‌که پراستفاده‌ترین شبکه‌ی ارتباطی اینترنت است، بیشتر APIها بر اساس استانداردهای وب طراحی شده‌اند. همه‌ی APIهای از راه دور، از نوع APIهای وب نیستند؛ اما می‌توانیم بگوییم همه‌ی APIهای وب در گروه APIهای از راه دور قرار می‌گیرند. 

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

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

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

بررسی SOAP و REST

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

یک مشخصه‌ی دیگر، REST نام دارد که مخفف عبارت Representational State Transfer و به معنای انتقال بازنمودی حالت است. APIهای وبی که به معماری REST پایبند هستند، APIهای RESTful نامیده می‌شوند. REST یک تفاوت اساسی با SOAP دارد: این‌که SOAP یک پروتکل است، در حالی که REST یک سبک معماری در نظر گرفته می‌شود. این بدان معنا است که استاندارد رسمی خاصی برای APIهای وب RESTful وجود ندارد. 

شرایط طراحی RESTful

همان‌طور که در مقاله‌ی «مدل‌های معماری و طراحی‌های معماری نرم‌افزار وابسته به شبکه» آمده است، برای این‌که یک API بر پایه‌ی معماری RESTful طراحی شوند، شش ویژگی باید داشته باشد:

-معماری کلاینت-سرور (Client-server architecture):

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

-بدون حالت (stateless):

هیچکدام از محتواهای مرتبط با کلاینت در سرورها ذخیره نمی‌شود. در عوض، اطلاعات مربوط به وضعیت session نگهداری می‌شود. 

-حافظه پنهان (Cacheability):

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

-سیستم لایه‌‌بندی شده (Layered system):

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

-انتقال کد بر حسب تقاضا یا Code on demand (این محدودیت اختیاری است):

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

-واسط یکنواخت(Uniform interface):

این ویژگی اساسی برای طراحی APIهای RESTful بوده و شامل چهار جنبه‌ی زیر است:

• شناسایی منابع در درخواست‌ها (Resource identification in requests): در درخواست‌های ارسالی به سمت سرور، منابع با یک کد شناسه منبع مشخص می‌شوند و از اطلاعاتی که به کلاینت ارائه می‌شوند، جدا هستند. 

• دستکاری کردن منابع از طریق بازنمایی (Resource manipulation through representation): سرور یک بازنمایی از منبع را برای کلاینت ارسال می‌کند. به عنوان مثال، یک کلاینت ممکن است فرمت JSON یک منبع یا XML منبع را درخواست کند. اگر سرور قادر به انجام این کار باشد، این فرمت را ارائه می‌دهد. بنابراین، کلاینت فایل‌هایی را دریافت می‌کند که بازنمایی منابع هستند. این بازنمایی‌ها یا پاسخ‌های برگشتی از سمت سرور، باید از اطلاعات کافی برخوردار باشند تا کلاینت توسط آن‌ها بتواند منبع را اصلاح یا حذف کند.

• پیام‌های خود توصیف‌گر (Self-descriptive messages): هر پیامی که به یک کلاینت بازگردانده می‌شود، دارای اطلاعات کافی برای توصیف نحوه‌ی پردازش اطلاعات توسط کلاینت است. در واقع، پیام خود شامل تمام اطلاعاتی است که گیرنده برای درک پیام به آن‌ها نیاز دارد. اطلاعات اضافی نباید در اسناد جداگانه یا در پیام دیگری وجود داشته باشد. برای درک چگونگی این کار، مثال زیر را در نظر بگیرید: وقتی کاربر http://www.example.com را در نوار آدرس مرورگر وب خود تایپ می‌کند، مرورگر درخواست HTTP زیر را ارسال می‌کند:

GET / HTTP/1.1

Host: www.example.com

این پیام «خود توصیف‌گر» است، زیرا به سرور می‌گوید از چه متد HTTP و پروتکلی استفاده شده است (HTTP 1.1).

• هاپرمدیا به عنوان یک موتور وضعیت برنامه (Hypermedia as the engine of application state): عبارت Hypermedia یک کلمه‌ی فانتزی برای داده‌های ارسال شده از سرور به سمت کلاینت است. همچنین حاوی اطلاعاتی درباره‌ی آن‌چه که کلاینت در مرحله‌ی بعدی می‌تواند انجام دهد است. (به عبارت دیگر، درخواست‌های بیشتری که می‌تواند ایجاد کند). در REST، سرورها باید فقط هایپرمدیا را برای کلاینت ارسال کنند. مثلاً HTML نوعی هایپرمدیا است. برای درک بهتر این موضوع، به دو مثال زیر توجه کنید:

لینک زیر به کلاینت می‌گوید که اگر کاربر می‌خواهد یک درخواست GET را از http://www.recurse.com درخواست کند، باید روی پیوند مشخص شده کلیک کند:

<a href= “http://www.recurse.com”> Check out the Recurse Center! </a>

لینک زیر هم به کلاینت می‌گوید که بلافاصله درخواست GET را از http://www.example.com/awesome-pic.jpg درخواست کند تا سرور بتواند تصویر را برای کاربر نمایش دهد:

<img src=”awesome-pic.jpg”>

بنابراین، سبک معماری REST این امکان را می‌دهد تا از پیوندهای هایپر‌مدیا در محتوای پاسخ استفاده کنیم. این امر اجازه می‌دهد تا کلاینت با استفاده از لینک‌های هایپر‌مدیا، به طور پویا به منابع موردنظر دست پیدا کند.

امکان دارد محدودیت‌های گفته شده، به نظر شما زیاد باشند؛ اما ساده‌تر از یک پروتکل تعیین‌شده هستند. به همین دلیل، APIهای RESTful بیشتر از SOAP گسترش پیدا می‌کنند. 

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

 یکی دیگر از استانداردهای نوظهور در عرصه API، استاندارد GraphQL است. GraphQL یک زبان کوئری‌نویسی و runtime سمت سرور است که جایگزینی برای REST به شمار می‌رود. GraphQL دقیقاً همان داده‌هایی را که توسط کلاینت درخواست می‌‌‌شود، در اختیار کلاینت قرار می‌دهد. اگر GraphQL را به عنوان یک گزینه‌ی جایگزین برای REST در نظر بگیریم، GraphQL به توسعه‌دهندگان این امکان را می‌دهد که درخواست‌هایی ایجاد کنند که داده‌ها را از چندین منبع در یک ارتباط API دریافت می‌کنند.

SOA در برابر معماری میکروسرویس‌ها

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

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

معماری میکروسرویس‌ در استفاده از سرویس‌های اختصاصی و مشترک، شبیه به الگوهای SOA است؛ اما آن‌ها برای نابود کردن معماری‌های سنتی حتی بیشتر پیش می‌روند. سرویس‌های معماری میکروسرویس‌ها از یک الگوی پیام‌رسانی معمول مانند APIهای RESTful استفاده می‌کنند. این سرویس‌ها به این دلیل از RESTful API ها برای تعامل با یکدیگر استفاده می کنند که آن‌ها را از تبدیل داده‌ها و وجود لایه‌های واسط اضافی بی نیاز می‌کند. استفاده از APIهای RESTful امکان تحویل سریع ویژگی‌ها و به‌روزرسانی‌های جدید را فراهم می‌کند. هر سرویس مجزا از سرویس دیگر است. یک سرویس می‌تواند جایگزین شود، ارتقا داده شود یا بدون اینکه بر روی سرویس‌های دیگر موجود در معماری تاثیر بگذارد، خارج شود. این معماری سبک به بهینه‌سازی منابع توزیع شده یا ابری کمک می‌کند و از مقیاس‌پذیری پویا برای خدمات اختصاصی پشتیبانی می‌کند. 

سوالات متداول

منبع:

What is an API