مقدمه

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

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

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

تفکر محصول محور در خصوص API

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

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

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

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

در زمان طراحی API سادگی استفاده در آینده را همیشه مد نظر داشته باشید. هدف این نیست که API را برای تمام نیازها طراحی کنیم. بلکه هدف شروع از این پایه و اساس قابل توسعه و ارائه ارزش به توسعه دهندگان می باشد. سپس می توان از آنها بازخورد گرفت و توسعه آینده را برنامه ریزی نمود. تفکر محصول محور در خصوص API نیاز به رفتار محصول-محور با API دارد. بایستی یک مدیر یا مالک محصول برای آن وجود داشته باشد – نه یک مدیر پروژه که تنها هدفش تولید لیستی از نیازمندیها باشد.

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