نحوه ساختن API (از صفر تا صد)

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

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

ما در دوران خوبی زندگی می‌کنیم، چرا که ابزارهای زیادی وجود دارند که ساختن API را بسیار قابل کنترل‌تر می‌کنند. با چیزی مانند Postman، می‌توانیم مشخصات API را ایجاد کنیم، مشخصات API را آزمایش کنیم و در نهایت API خود را آزمایش کنیم تا اطمینان حاصل کنیم که مطابق انتظار کار می‌کند. برای ساختن back end  برای API خود، به مجموعه‌ای از ابزارها مانند Flask، Heroku و موارد دیگر نیاز داریم، یا می‌توانیم یک ابزار low-code را برای میزبانی و در درجه اول ساختن API خود انتخاب کنیم.

در این پست به مراحل ساختن API و چگونگی کارآمدتر شدن این فرآیند خواهیم پرداخت.

فرآیند ساختن API

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

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

به عنوان مثال، ممکن است از Postman برای طراحی و ساختن API خود (Open APISpecification) استفاده کنیم و از چیزی مانند flask برای firebase اتصال کد، یا از برخی دیتابیس‌ها برای ذخیره یا ریکاوری داده‌ها بهره ببریم. همچنین ممکن است لازم باشد تماس‌های REST اضافی با سایر APIها و سرویس‌ها برقرار کنیم. برای تست، می‌توانیم دوباره از Postman استفاده کنیم، اما باگ‌زدایی کد و همه Connector های ما ممن است مشکل‌ساز شوند. سپس برای استقرار، ممکن است Heroku را انتخاب کنیم، اما این بستگی به نیازهای API ما دارد. در نهایت برای Monitoring ، می‌توانیم سیستم Monitoring خود را ایجاد کنیم یا از چیزی مانند Splunk استفاده کنیم. و هنگامی که ما نیاز به حفظ API خود داریم، باید دوباره تمام این کارها را تکرار کنیم. فکر می‌کنم الان متوجه شدید که من چه می‌خواهم بگویم. توسعه و ساختن API کار بسیار پیچیده‌ای است.

یافتن راه بهتر برای ساختن API

من با داشتن ابزارهای زیاد، راهی برای ساده کردن چرخه توسعه API و ساختن API های خود، از طراحی تا تولید می‌خواستم. به لطف ابزارهای low-code مانند Linx، این امکان وجود دارد. من فقط با استفاده از سه ابزار توانستم تمام مراحل ساختن API از طراحی تا استقرار را به اتمام برسانم:

Postman

من از postman برای ایجاد مشخصات API خود (بر اساس YAML) و برای آزمایش API خود استفاده کردم.

Linx

 من از Linx برای ساختن API خود، پیاده سازی logic ، باگ زدایی و در نهایت میزبانی آن استفاده کردم.

SQL Server

 SQL Server برای ذخیره داده های API من استفاده شد. من از دیتابیس از پیش ساخته شده AdventureWorks2019 و داده‌های آن استفاده کردم.

موارد لازم برای ساختن API

من یک API ساده را انتخاب کردم که نگهداری سوابق کاربر را انجام می‌دهد. API دارای پنج متد است:

ایجاد مشخصات (Specification)

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

ساختن API

اکنون که تعریف API را دارید، می توانید کد را ایجاد کنید. Linx به شما این امکان را می‌دهد که مشخصات OpenAPI 3.0 را وارد کنید، و به طور خودکار رویدادها را برای هر متد مشخص شده ایجاد می کند. من فقط نیاز داشتم که URI را مشخص کنم و سپس logic را بسازم.

پس از نصب پلاگین دیتابیس، ایجاد منطق (logic) هر رویداد نسبتاً تسریع می‌شود. Linx مانند هر ابزار دیگری منحنی یادگیری دارد، اما زمانی که نحوه کار با آن را فهمیدید، سرعتتان در آن بالا می‌رود.

من منطق و عملکرد را به هر رویداد برای API اضافه کردم. به عنوان مثال، برای متد GetAllUsers، همه ما باید از دیتابیس SQL بخوانیم و نتایج را از طریق Response body برگردانیم.

تست API

از آنجایی که API از قبل بر روی Postman تنظیم شده است، آزمایش نحوه عملکرد API  به صورت Real-time ، و در حالتی که منطق آن پیاده سازی شده است، بسیار آسان است. GIF زیر نشان می دهد که چگونه از طراح Linx برای باگ زدایی REST API که خودم ساختم، استفاده کردم و چگونه آن را در حالت باگ زدایی تست می‌کنم.

با باگ زدایی در Linx، API میزبانی می‌شود تا بتوانم با آن call کنم تا ببینم هنگام استقرار چگونه رفتار می‌کند. این به من امکان می‌دهد آن را تست کنم و نتیجه واقعی را دریافت کنم:

استقرار API

اکنون که ساختن API مراحل توسعه و آزمایش را هم گذرانده است، نیاز به استقرار دارد. این می‌تواند یک کار بنیادی با traditional API باشد، زیرا ما باید یک استراتژی استقرار ارائه دهیم، بفهمیم کجا میزبان چه چیزی خواهیم بود و مطمئن شویم که نظارت و ثبت گزارش انجام می‌شود و … .

فرآیند استقرار من بسیار ساده بود. من API را از Linx Designer و مستقیماً روی سرور Linx مستقر کردم. حدود 2 دقیقه طول کشید تا راه حل ساخته شد، به سرور فرستاده شد و برای استفاده آماده شد. مشکل میزبانی API دیگر وجود ندارد، زیرا سرور Linx این کار و همچنین کارهای مربوط به نظارت و ثبت را انجام می دهد:

من متد GetUser را با ID نادرست call کردم تا ببینم اگر خطای غیرمنتظره‌ای رخ دهد چه اتفاقی می افتد. سرور خطا را ثبت می‌کند و با رنگ قرمز نشان می دهد که خطایی رخ داده است:

من توانستم دوباره از Postman با API مربوطه call کنم و سرور هر بار که API فراخوانی می‌شود، علامت می‌دهد.

من هیچ نوعی از امنیت یا Authentication را به API خود اضافه نکردم، اما این تنظیمات در Linx designer موجود است. گزینه دیگری که در این مرحله از ساختن API امتحان کردم، این بود که API Documentation را در قالب swagger ایجاد کنم. معلوم شد که این کار بسیار مفید است. زیرا با افزودن /swagger به URI پایه، documentation در دسترس هستند و با خود API ذخیره می‌شوند. این امر توزیع اسناد API را در صورت نیاز آسان می‌کند.

جمع‌بندی

هنگامی که به طور همزمان از Linx و Postman استفاده می‌کنیم، می توانیم API خود را طراحی، ایجاد، document و میزبانی کنیم. مانند هر ابزار دیگری، کمی طول می‌کشد تا به این کارها عادت کنید. از آنجایی که Linx از پارادایم‌ها و اصطلاحات برنامه نویسی استاندارد استفاده می‌کند، اگر با زبان برنامه نویسی‌ای مانند C# آشنایی داشته باشید، به راحتی می توانید از آن استفاده کنید. من احساس می‌کنم که هنگام استقرار و میزبانی یک API با Linx زمان زیادی را صرفه‌جویی می‌کنیم. با انجام دادن Monitoring و میزبانی از مشکلات بزرگی پیشگیری می‌کنید. اگر Logging و Monitoring به اندازه کافی جزئی نیست، می توانید عملکرد خود را به راه حل Linx اضافه کنید.

اگر می‌خواهید با Linx یک API بسازید، موارد زیر برایتان مفید خواهد بود:

• استفاده از design first (با Postman)
• code first (فقط ساختن)

منبع: hackernoon