اگر می‌خواهید اپلیکیشن‌ها و استارتاپ‌های خود را به کمک  APIهای موجود بسازید و خودتان از اول چرخ را اختراع نکنید، چگونه بین گزینه‌های موجود تصمیم می‌گیرید؟ این یادداشت قرار است به شما کمک کند بتوانید بهترین APIها را برای کسب‌وکار خود انتخاب کنید و بدانید چه چیزهایی را باید از یک API انتظار داشته باشید. 

API چیست و چرا باید آن را داشته باشید؟

قبل از شروع، بهتر است API را تعریف کنیم. البته اگر می‌خواهید به طور کامل با API آشنا شوید، یادداشت «API چیست؟» را بخوانید. API  یک رابط استاندارد شده برای اجزای مختلف نرم‌افزار برای برقراری ارتباط  است. فرقی نمی‌کند API مبتنی بر REST باشد یا GrapQL و یا هر روشی دیگر، در هر صورت کارکرد API برقراری ارتباط است. 

در چند سال گذشته کلمه API با HTTP مبتنی بر معماری REST عجین شده بود. پیش از این هم به API های مبتنی بر SOAP توجه زیادی می‌شد. اما این روزها توسعه‌دهندگان از GRPC ،  GraphQL  و راه‌های دیگر برای فراخوانی و معماری APIها استفاده می‌کنند. 

این مقاله تا حد امکان سعی می‌کند مستقل از پروتکل‌ها و معماری‌ها نکاتی را ارائه کند، اما گرایش کلی مقاله به سمت HTTP  و REST  است، چرا که در حال حاضر بسیار رایج و متداول است. 

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

۱- موانع ورود به دنیای APIها را برطرف کنید

هزینه، جایگزین تجربه خوب نمی‌شود

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

مستندسازی

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

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

در زمان مستندنویسی، حداقل کاری که باید انجام شود این است که دستورالعمل‌های شروع کار یا همان به اصطلاح hello world  نوشته شود و بسته به پیچیدگی برنامه، شما می‌توانید از Time to first hello world  استفاده کنید. 

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

احراز هویت

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

به استانداردها پایبند باشید

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

به عنوان مثال، انتظار می‌رود APIهای مبتنی بر gRPC از بافرهای پروتکل استفاده کنند تا ساختارهای داده را تعریف کنند و در حالی که GraphQL بیشتر یک زبان پرس و جو برای داده‌های API است، مشتریان GraphQL که این داده‌ها را مصرف می‌کنند نیز انتظار ساختار خاصی را دارند. 

به عنوان مثال، یک API مبتنی بر REST را در نظر بگیرید. REST یک استاندارد نیست که باعث شده بسیاری از APIها خود را به عنوان RESTful یا یا HTTP API معرفی کنند. در عوض HTTP  یک استاندارد است، بنابراین ارزیابی اینکه یک API از HTTP  استفاده می‌کند یا REST، می‌تواند به شما در ارزیابی طراحی یک API کمک کند. به عنوان مثال در HTTP  باید عمل مورد نظر مطابقت داشته باشد. 

• GET: retrieve data
• POST: add new data
• PUT: update existing data
• PATCH: update a subset of existing data
• DELETE: remove data

همچنین می‌توانید ارزیابی کنید که آیا یک API از منابع اسمی معتبر استفاده می‌کند یا نه. برای مثال وقتی یک API  در زمینه صدور فاکتور فعالیت می‌کند، منطقی است که نام منبع آن invoice  باشد و در ادامه از ID  و P2P  و مواردی از این دست استفاده کند. 

در حال حاضر REST هیچ قالبی را برای بدنه تعریف نمی‌کند، اما به دنبال قالب‌هایی بگردید که از ساختارهایی استفاده می‌کنند که بتوان آن‌ها را تجزیه کرد، مانند XML یا JSON. خروجی باید با استفادده از کلیدها و مقادیر مفید و مناسب‌ترین ساختار برای مجموعه داده‌ها شکل گرفته باشد. به تمام زمان‌هایی که در یک ساختار داده JSON برای یافتن نحوه دسترسی به داده‌های مورد نظر خود هدر داده‌اید، فکر کنید. 

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

براساس نمونه‌های موردی طراحی شده باشد

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

۲- قبل از ورود به دنیای کسب‌وکار، تجربه کنید.

برنامه‌ها و محدودیت‌های دوستانه

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

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

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

شما باید همین منطق را برای روش دوم هم به کار برید. علاوه‌براین باید در نظر بگیرید که اگر میزان استفاده شما از سقف تعدادی بسته بیشتر شود، چه اتفاقی برای شما می‌افتد. آیا دسترسی شما قطع می‌شود؟ با هزینه‌ی زیادی به شما سرویس ارائه می‌شود؟ اخطار در چه زمانی برای شما ارسال می‌شود؟

پیشنهادهای بیشتری داشته باشید

یک API  خوب باید از معماری و تکنولوژی شناخته‌شده‌تر و الگوهای استاندارد پیروی کند. اما اگر یک تامین‌کننده از SDKهای مختلف برای تطبیق و ادغام سرویس با برنامه‌های شما استفاده کند و آن را ارائه دهد، بهتر است. مراقب باشید داکیومنت‌های API که به صورت خودکار SDK تولید می‌کنند، الزاما گزینه‌ی مناسبی برای شما نیستند و ممکن است با تنظیمات زبان برنامه‌نویسی شما مناسب نباشد. 

۳- پشتیبانی

نحوه برقراری ارتباط

یک API یکی از اجزای حیاتی کسب‌وکارهاست و همه ما شاهد شکست برنامه‌ها و کسب‌وکارهایی بودیم که از APi های بی‌کیفیت خارجی استفاده می‌کردند. این موضوع به همه‌ی ما اهمیت انتخاب تامین‌کننده API با کیفیت و با کم‌ترین میزان خرابی را ثابت می‌کند. علاوه‌براین در انتخاب تامین‌کننده API باید حواستان باشد که کدام تامین‌کننده در سریع‌ترین وقت ممکن شما را در جریان اختلال سرویس قرار می‌دهد و مهم‌تر از همه از اشتباهاتش درس می‌گیرد. 

پاسخگو بودن

امیدواریم به ندرت در مورد مسائل فنی و یا حساب و کتاب‌های مالی نیاز به کمک داشته باشید، اما اگر به این مشکلات برخوردید، چه گزینه‌هایی برای انجام این کار در دسترس شماست؟ برای دریافت پاسخ خود چقدر زمان باید صرف کنید؟ 

مسئولیت‌پذیری

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

آموزنده

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

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

در نهایت پیشنهاد می‌کنیم اگر می‌خواهید بیشتر با این موضوع آشنا شوید، مقاله «چگونه تامین کننده API مناسبی را پیدا کنیم؟» را هم بخوانید.