طراحی API فرآیند اتخاذ تصمیمهای آگاهانه و هدفمند درباره این است که یک API چگونه دادهها و قابلیتهای خود را در اختیار مصرفکنندگان قرار دهد. یک طراحی موفق API، نقاط پایانی (endpoints)، متدها و منابع API را در قالب یک فرمت استاندارد مشخصات توصیف میکند.
فرآیند طراحی API هم برای مصرفکنندگان و هم برای تولیدکنندگان مزایایی دارد، زیرا تضمین میکند که APIها ضمن پشتیبانی از اهداف کسبوکار، همچنان ساده برای استفاده، انعطافپذیر، قابل آزمون و بهخوبی مستندسازیشده باقی بمانند. طراحی API باید در مراحل ابتدایی چرخه عمر API انجام شود تا همراستایی میان ذینفعان کلیدی ایجاد گردد و به تیمها کمک کند مشکلات را پیش از آنکه ریشهدار شوند شناسایی کنند. طراحی API همچنین بخش مهمی از یک استراتژی مؤثر حاکمیت API محسوب میشود، زیرا به تیمها کمک میکند الگوهای استاندارد API را تعریف کنند که در سراسر سازمان قابل استفاده مجدد باشند.
در اینجا، به بررسی رابطه میان طراحی API و مدل توسعه API-first، مراحل کلیدی طراحی API، نقش موککردن در طراحی API و این که چگونه پلتفرم Postman API میتواند به سازمان شما در پیادهسازی فرآیندهای بالغ طراحی API کمک کند، میپردازیم.
طراحی API چگونه از مدل توسعه API-first پشتیبانی میکند؟
API-first یک مدل توسعه است که در آن برنامهها با سرویسهایی که از طریق API ارائه میشوند، مفهومپردازی و ساخته میشوند. در حالی که شرکتهایی که رویکرد code-first را دنبال میکنند ممکن است APIها را بهعنوان یک موضوع ثانویه در نظر بگیرند، شرکتهای API-first پیش از توسعه برنامههای خود، APIها را طراحی میکنند. این استراتژی به مصرفکنندگان و تولیدکنندگان اجازه میدهد پیش از پیادهسازی، بر سر تعریف API با یکدیگر همکاری کنند؛ موضوعی که هم کیفیت و هم قابلیت استفاده APIها را بهبود میدهد.
برخی از رویکردهای طراحی API کداماند؟
چند رویکرد مختلف در طراحی API وجود دارد که بهطور رایج مورد استفاده قرار میگیرند، از جمله:
طراحی API از درون به بیرون (Inside-out API design)
در رویکرد inside-out، سیستم بکاند از پیش موجودِ ارائهدهنده API بهعنوان نقطه شروع در نظر گرفته میشود. سپس جزئیات پیادهسازی داخلی و قابلیتهای بکاند از طریق API در معرض استفاده قرار میگیرند. این رویکرد کنترل جزئی، دسترسی مستقیم به فرآیندهای داخلی و قابلیتهای غنی را فراهم میکند، اما ممکن است به APIهای بهشدت وابسته و افزایش پیچیدگی برای مصرفکنندگان منجر شود.
طراحی API از بیرون به درون (Outside-in API design)
طراحی API به روش outside-in بر طراحی API بر اساس نیازها و الزامات مصرفکنندگان خارجی تمرکز دارد و پیچیدگیهای داخلی را پنهان میکند. این رویکرد سادگی، سهولت استفاده و انعطافپذیری را در اولویت قرار میدهد و به مصرفکنندگان اجازه میدهد بدون آگاهی از پیادهسازی زیرساختی با API تعامل داشته باشند. این رویکرد معمولاً APIهایی با وابستگی کمتر تولید میکند که نگهداری و توسعه آنها سادهتر است.
طراحی چابک ایپیآی (Agile API design)
در رویکرد طراحی چابک API، توسعهدهندگان بدون داشتن یک مشخصات کامل، کار روی API را آغاز میکنند. این رویکرد بر انعطافپذیری، همکاری و واکنشپذیری نسبت به تغییر در طول فرآیند توسعه API تأکید دارد. توسعهدهندگان باید بهسرعت تکرار کنند تا ارزش را به مصرفکنندگان ارائه دهند و همزمان با نیازها و اولویتهای در حال تغییر سازگار شوند. این رویکرد همکاری نزدیک میان توسعهدهندگان، ذینفعان و کاربران نهایی را تشویق میکند تا اطمینان حاصل شود API نیازهای آنها را برآورده میکند.
مراحل کلیدی طراحی API کداماند؟
چهار گام کلیدی در فرآیند طراحی API وجود دارد که هر سازمانی باید آنها را دنبال کند. هر گام نیازمند همکاری میان ذینفعان مختلف مانند رهبران کسبوکار، توسعهدهندگان، مصرفکنندگان و شرکا است تا اطمینان حاصل شود API تمام نیازهای مرتبط را پوشش میدهد. همکاری در تمام مراحل طراحی API همچنین به توسعهدهندگان کمک میکند از ساخت قابلیتهای غیرضروری جلوگیری کنند. این مراحل عبارتاند از:
گام اول: تعیین هدف API
نخستین گام در فرآیند طراحی API این است که تمام ذینفعان بر سر مورد استفاده کسبوکاری API به توافق برسند. APIای که مسئول یک جریان احراز هویت است، الزامات متفاوتی نسبت به APIای دارد که به کاربران اجازه مرور یک کاتالوگ محصول را میدهد؛ بنابراین همراستایی بر سر مورد استفاده، پیش از هر تصمیم دیگری ضروری است. مورد استفاده همچنین میتواند بر نوع معماری انتخابی تأثیر بگذارد. برای مثال، معماری مبتنی بر gRPC ممکن است برای APIای که میکروسرویسهای داخلی را به هم متصل میکند مناسبتر باشد، در حالی که یک API مبتنی بر GraphQL برای سرویسی که به منابع داده متنوع متکی است گزینه بهتری خواهد بود. پس از رسیدن به توافق، ذینفعان باید اهداف خود از API را بهصورت شفاف و با زبان طبیعی بیان کنند و توضیح دهند این API دقیقاً چگونه نیازهای مشخص را برآورده خواهد کرد.
گام دوم: تعریف قرارداد API با استفاده از مشخصات
پس از همراستایی ذینفعان بر سر مورد استفاده API، باید تصمیم بگیرید چه منابعی مورد نیاز هستند، دادههای آنها چگونه قالببندی و ساختاربندی شوند، چه ارتباطی با یکدیگر دارند و چه متدهایی باید روی نقاط پایانی مرتبط با آنها در دسترس باشند. همچنین تعیین سطح انتزاع و کپسولهسازی در API اهمیت دارد، زیرا به ایجاد تعادل میان قابلیت استفاده مجدد و خوانایی کمک میکند.
APIهای قابل استفاده مجدد، APIهای سلفسرویسی هستند که توسعهدهندهای دیگر، یک تیم، یک شریک یا یک شرکت میتواند بدون نیاز به همکاری همزمان با تیم دیگر از آنها استفاده کند. این APIها با نامهایی مانند API بهعنوان محصول، APIهای خارجی، APIهای پلتفرمی، APIهای شراکتی یا APIهای عمومی نیز شناخته میشوند.
این تصمیمات باید در قالب یک تعریف API ثبت شوند؛ تعریفی که نمایشدهندهای قابل خواندن برای انسان و ماشین از قابلیتهای مورد انتظار API است و از APIهای آماده برای هوش مصنوعی پشتیبانی میکند. تعاریف API از مشخصات استانداردی مانند OpenAPI و AsyncAPI پیروی میکنند که فرمت استانداردی برای تعریف API ارائه میدهند و پایهای برای قراردادها، مستندات، موکها و تستها فراهم میکنند.
گام سوم: اعتبارسنجی فرضیات با موکها و تستها
پس از تکمیل تعریف API، میتوانید از آن برای تولید سرورهای موک استفاده کنید. سرورهای موک در پاسخ به درخواستها، دادههای نمونه بازمیگردانند و به شما امکان میدهند بررسی کنید آیا API مطابق انتظار عمل میکند یا خیر. موکها همچنین میتوانند در کنار تستهای API استفاده شوند؛ تستهایی که میتوان آنها را بهصورت دستی، زمانبندیشده یا خودکار در خطوط CI/CD اجرا کرد. تست و موککردن در مرحله طراحی API به شما کمک میکند مشکلات را پیش از ورود به کد مصرفکنندگان شناسایی و رفع کنید؛ زمانی که رفع آنها بسیار دشوارتر خواهد بود.
در بخشهای بعدی، سرورهای موک را با جزئیات بیشتری بررسی خواهیم کرد.
گام چهارم: مستندسازی API
آخرین گام در فرآیند طراحی API، نوشتن مستندات است. این گام که شامل تعریف جزئیات کلیدی هر منبع، متد، پارامتر و مسیر است، به اعتبارسنجی طراحی کمک میکند و اطمینان میدهد مصرفکنندگان بتوانند در سریعترین زمان ممکن استفاده از API را آغاز کنند. مستندات ممکن است شامل نمونههایی از درخواستها و پاسخهای API نیز باشد که دید ارزشمندی درباره نحوه پشتیبانی API از نیازهای رایج کسبوکار در اختیار مصرفکنندگان قرار میدهد. برخی ابزارها میتوانند مستندات را بهصورت خودکار از روی تعریف API تولید کنند تا تیمها نگران قدیمی شدن مستندات نباشند.
چرا از Postman برای طراحی API استفاده کنیم؟
پلتفرم Postman API که توسط G2 بهعنوان بهترین ابزار طراحی API رتبهبندی شده است، مجموعهای قدرتمند از قابلیتها را در اختیار تیمها قرار میدهد تا فرآیندهای بالغ طراحی API را پیادهسازی کنند. با Postman میتوانید:
تولید و ویرایش تعاریف API:
Postman به شما امکان میدهد یک تعریف API موجود را وارد کنید یا از ابتدا یک تعریف جدید بسازید. Postman از OpenAPI، RAML، Protobuf، GraphQL و WSDL پشتیبانی میکند تا بتوانید مناسبترین مشخصات را انتخاب کنید.
مستندسازی API:
Postman بهطور خودکار برای هر کالکشن و همچنین برای هر تعریف OpenAPI 3.0 مستندات تولید میکند. این مستندات همزمان با تغییرات شما بهروزرسانی میشوند و همواره برای مصرفکنندگان قابل استفاده باقی میمانند.
ساخت، اجرا و خودکارسازی تستهای قرارداد API:
Postman کتابخانهای از قطعهکدهای قابل شخصیسازی ارائه میدهد که میتوان از آنها برای ایجاد تستهای قرارداد API استفاده کرد. این تستها را میتوان بهصورت دستی در Postman اجرا کرد یا با استفاده از Newman یا Postman CLI بهصورت خودکار در خط CI/CD اجرا نمود.
شبیهسازی رفتار API با سرورهای موک:
Postman به شما امکان میدهد سرورهای موکی راهاندازی کنید که حتی پیش از آماده شدن API در محیط تولید، دادههای نمونه بازمیگردانند. این کار به تولیدکنندگان اجازه میدهد بدون عجله در توسعه، فرضیات خود را اعتبارسنجی کنند و همزمان به مصرفکنندگان امکان میدهد فرآیند یکپارچهسازی را زودتر آغاز کنند.
همکاری در سطح سازمان:
همکاری در DNA Postman نهادینه شده است. کاربران میتوانند از ورکاسپیسهای تیمی برای همکاری آسان روی پروژههای API استفاده کنند. Postman همچنین از امکان کامنتگذاری در سراسر پلتفرم پشتیبانی میکند تا تیمها بتوانند در همان جایی که کار میکنند، با هم ارتباط داشته باشند. در نهایت، Postman ابزاری شهودی و کاربرپسند است که هم برای توسعهدهندگان و هم برای ذینفعان کسبوکار قابل استفاده است.
