آزمایش Web APIs توسط Postman - قسمت هفتم - استفاده از خروجی OpenAPI Swagger در Postman
اندازه‌ی قلم متن
تخمین مدت زمان مطالعه‌ی مطلب: سه دقیقه

در سری «OpenAPI Swagger» با نحوه‌ی مستندسازی یک Web API و همچنین آزمایش دستی اجزای آن به کمک Swagger-UI که رابط کاربری ایجاد شده‌ای بر اساس خروجی Open API است، آشنا شدیم. بنابراین اگر می‌توان رابط کاربری خودکاری را بر اساس OpenAPI Spec ایجاد کرد، به این معنا است که تمام اطلاعات لازم جهت انجام اینکار، هم اکنون در آن قرار دارد. در ادامه قصد داریم تعامل دستی با Swagger-UI را جهت آزمایش Web API، به Postman منتقل کرده تا اجرای مجموعه‌ای از آن‌ها را توسط Collection Runner، خودکار کنیم.


ساخت و ایجاد درخواست‌های Postman به کمک خروجی OpenAPI

در اینجا از همان برنامه‌ای که در سری «مستند سازی ASP.NET Core 2x API توسط OpenAPI Swagger» بررسی کردیم، استفاده خواهیم کرد. بنابراین، این برنامه از پیش تنظیم شده‌است و هم اکنون به همراه یک تولید کننده‌ی OpenAPI Specification نیز می‌باشد. آن‌را اجرا کنید تا بتوان به OpenAPI Specification تولیدی آن در آدرس زیر دسترسی یافت:
https://localhost:5001/swagger/LibraryOpenAPISpecification/swagger.json
سپس برنامه‌ی Postman را گشوده و از منوی File، گزینه‌ی Import آن‌را انتخاب کنید:


در برگه‌ی Import from link آن، همان URL فوق را که به خروجی OpenAPI Spec اشاره می‌کند، وارد کنید. اکنون با کلیک بر روی دکمه‌ی Import، یک مجموعه‌ی جدید، به نام Library API، به لیست مجموعه‌های Postman، اضافه می‌شود:


Postman تمام این اطلاعات را به صورت خودکار از OpenAPI Spec استخراج کرده‌است. تمام نام‌ها نیز بر اساس توضیحاتی که برای متدها نوشته‌ایم، انتخاب شده‌اند.


ارسال اولین درخواست به Web API

در اینجا برای نمونه اگر درخواست «Get list of authors» را انتخاب کنیم، یک چنین خروجی ظاهر می‌شود:


همانطور که مشاهده می‌کنید، متغیر {{baseUrl}} را جهت تنظیم آدرس پایه‌ی Web API انتخاب کرده‌است. این نکته در مطلب «قسمت پنجم - انواع متغیرهای قابل تعریف در Postman» بیشتر بحث شده‌است. هدف از تعریف متغیر {{baseUrl}} به این شکل در اینجا، امکان تعریف آن به صورت یک متغیر محیطی است تا بتوان آن‌را به سادگی بر اساس محیط‌های مختلفی که تعریف و انتخاب می‌کنیم، تغییر داد؛ بدون اینکه نیازی باشد اصل درخواست‌های تعریف شده، تغییری کنند. بنابراین در ادامه نیاز است یک محیط جدید را تعریف کنیم.
برای تعریف یک محیط جدید می‌توان بر روی دکمه‌‌ای با آیکن چشم، در بالای سمت راست صفحه و کلیک بر روی گزینه‌ی Add آن، یک محیط جدید را ایجاد کرد:


در صفحه‌ی باز شده ابتدا باید نامی را برای این محیط جدید انتخاب کرد و سپس می‌توان key/valueهایی را مخصوص این محیط، تعریف نمود:


ابتدا یک نام دلخواه وارد شده‌است و سپس متغیر محیطی baseUrl را با مقدار اولیه‌ی https://localhost:5001 تنظیم کرده‌ایم. پس از آن با کلیک بر روی Add پایین این صفحه، کار تعریف این محیط جدید به پایان می‌رسد.

مرحله‌ی بعد، انتخاب این محیط تعریف شده، به عنوان محیط کاری جاری است:


پس از این انتخاب، اگر اشاره‌گر ماوس را به متغیر baseUrl نزدیک کنیم، می‌توان مقدار تنظیم شده‌ی آن‌را مشاهده کرد:


اکنون اگر بر روی دکمه‌ی send این درخواست کلیک کنیم، چنین خروجی ظاهر می‌شود:


علت آن‌را می‌توان در برگه‌ی Authorization درخواست جاری مشاهده کرد:


همانطور که در مطلب «قسمت ششم - یک مثال تکمیلی: تبدیل رابط کاربری مثال JWT به یک مجموعه‌ی Postman» نیز مشاهده کردیم، برای تعریف هدرهای Authorization یا می‌توان به برگه‌ی هدرهای درخواست جاری مراجعه کرد و این هدرها را دستی تولید کرد و یا می‌توان با استفاده از برگه‌ی Authorization آن، کار تعریف این هدرها را ساده نمود. برای مثال در اینجا Postman بر اساس خروجی OpenAPI، دقیقا تشخیص داده‌است که این Web API از Basic authentication استفاده می‌کند. به همین جهت فیلدهای ورود نام کاربری و کلمه‌ی عبور را علاوه بر نوع اعتبارسنجی از پیش انتخاب شده، تدارک دیده‌است.
برای اینکه این مقادیر را نیز تبدیل به متغیرهای محیطی کنیم، برای ویرایش اطلاعات منتسب به محیط جاری، ابتدا باید آن‌را از dropdown محیط‌های بالای صفحه انتخاب کرد. اکنون با کلیک بر روی دکمه‌‌ای با آیکن چشم، در بالای سمت راست صفحه، لینک ویرایش این محیط انتخاب شده ظاهر می‌شود. با کلیک بر روی آن، می‌توان دو متغیر محیطی جدید را تعریف کرد:


پس از تعریف متغیرهای محیطی {{username}} و {{password}}، آن‌ها را در قسمت Authorization درخواست جاری استفاده می‌کنیم:


اینبار اگر مجددا بر روی دکمه‌ی Send کلیک کنیم، خروجی ذیل حاصل خواهد شد: