IFTTT: درآمدی بر شرکت‌های تکنولوژی مبتنی بر API که کار دولوپرها را آسان کرده‌اند!

IFTTT: درآمدی بر شرکت‌های تکنولوژی مبتنی بر API که کار دولوپرها را آسان کرده‌اند!

اگر تا قبل از سال ۲۰۱۰ به دولوپرها می‌‌گفتید که می‌‌توانند از طریق API درآمدزایی کنند، قطعاً به شما می‌‌خندیدند! در آن دوران، اساساً این ایده که شما لایه‌ای از نرم‌افزاری را بسازید و به‌ عنوان یک محصول آن‌ را بفروشید، نامعقول به‌ نظر می‌‌رسید چرا که عملاً API یک سرویس غیر‌قابل‌رؤیت است؛ اما زمانی که با یک پلتفرم (مثلاً وب‌سایت یا اپ موبایل) ادغام شود، به محصولی قابل‌روئیت و در عین حال بسیار ارزشمند مبدل خواهد شد (پیش از ادامهٔ این بحث، خوانندگانی که با مفهوم API آشنایی ندارند می‌توانند به مطالعهٔ آموزش API چیست؟ پرداخته تا مباحث طرح شده در این مقاله بیشتر برایش ملموس گردد.)

IFTTT در سال 2010 راه‌اندازی شد و به کاربران فرمولی تحت عنوان «اگر X بود، پس Y اتفاق بیافتد» را ارائه کرد که در نهایت باعث شد تا اینترنت به‌ معنای واقعی کلمه در دست دولوپرها قرار گیرد (IFTTT مخفف واژگان If This Then That است.)

به طور مثال، یک بلاگر خیلی راحت می‌تواند پس تولید محتوای مد نظر خود، آن را بر روی صفحات اجتماعی مختلفی مانند فیسبوک، توئیتر و اینستاگرام پُست کند و یا یک دانشجوی تازه فارغ‌التحصیل شده، می‌تواند یک ایمیل تشکر ایجاد کند که پس از هر مصاحبهٔ کاری، به‌ صورت خودکار برای شرکت مد نظر ارسال شود. به عبارتی، همه می‌توانند برنامه‌نویسی کنند، بدون آنکه برنامه‌نویس باشند! (Zapier کمتر از یک سال بعد (یعنی در سال ۲۰۱۱)، در قالب یک نسخهٔ تجاری‌تر منتشر شد به طوری که امروزه سرویس Zapier تَسک‌های تجاری خودکار بین قسمت‌های یک نرم‌افزار را تسهیل می‌کند.)

IFTTT و Zapier در واقع اکثر دولوپرها را مشتری خود کردند. آن‌ها حتی این امکان را به کاربران خود می‌دهند که چند API را ادغام کرده و نرم‌افزار اختصاصی خود را طراحی کنند. Linden Tibbets، مؤسس شرکت IFTTT، در این رابطه اعتقاد دارد که:

همانند دنیای واقعی که یک بچهٔ 12 ساله بااستفاده از دستهٔ تِی یا جارو شمشیر لیزری درست می‌کنه، در دنیای دیجیتال هم با ادغام دو چیز مختلف شما محصولی تولید می‌کنید که حتی تولیدکننده‌های اولیهٔ اون محصولات فکرش رو هم نمی‌کردن!

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

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

RapidAPI: سرویس اشتراک‌گذاری API
- ساخت وبلاگ مبتنی بر API با Butter در کمتر از 10 دقیقه
Insomnia: ابزاری به‌منظور دیباگ کردن API
- Strapi: فریمورک اپن‌سورس مبتنی بر Node.js برای ساخت RESTful API
- Toapi: ابزاری برای ساخت API برای هر نوع وب‌سایتی
apilist.fun: وب‌سایتی حاوی لیستی از API سرویس‌های مختلف

حال نوبت به نظرات شما می‌رسد. آیا به غیر از API، با مفهومی همچون RESTful API آشنایی دارید و آیا تاکنون در توسعهٔ اپلیکیشن‌های خود اقدام به طراحی سرویس‌هایی از این جنس کرده‌اید؟ به نظر شما اصطلاحاً Best Practice رایج در توسعهٔ API شامل چه مواردی می‌شود و تجربیات شما در این رابطه به چه شکل است؟ نظرات، دیدگاه‌ها و تجربیات خود را با دیگر کاربران سکان آکادمی به اشتراک بگذارید (همچنین خوانندگانی که با مفهوم RESTful API آشنایی ندارند، می‌توانند به آموزش آشنایی با مفهوم RESTful API مراجعه نمایند.)

از بهترین نوشته‌های کاربران سکان آکادمی در سکان پلاس


online-support-icon