چرخه عمر توسعه API

شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

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

API Services ابزارها و API های RESTful را ارائه می دهد که به شما امکان می دهد استقرار و مدیریت پراکسی API را در SDLC سازمان خود ادغام کنید. استفاده رایج از RESTful API نوشتن اسکریپت ها یا کدهایی است که به صورت برنامه نویسی پراکسی های API را مستقر می کند، یا پروکسی های API را از یک محیط به محیط دیگر منتقل می کند، به عنوان بخشی از یک فرآیند خودکار بزرگتر که برنامه های کاربردی دیگر را نیز مستقر یا انتقال می دهد. API Services هیچ فرضی در مورد SDLC شما (یا هر شخص دیگری) نمی کند. در عوض، عملکردهای اتمی را نشان می دهد که می تواند توسط تیم توسعه شما هماهنگ شود تا چرخه عمر توسعه API شما را خودکار و بهینه کند.

API های خدمات API در مرجع API مستند شده اند. برای شروع به مرجع API مراجعه کنید.

برای آشنایی با محیط های API و چرخه عمر توسعه API، این ویدیو را تماشا کنید.

محیط ها

هر سازمانی در Apigee Edge دارای حداقل دو محیط استقرار است که برای پراکسی‌های API در دسترس است: "test" و "prod". تمایز بین دو محیط دلخواه است - هر محیط به سادگی توسط مجموعه متفاوتی از آدرس های شبکه (URL) شناسایی می شود. هدف این است که دامنه‌ای را در اختیار شما قرار دهیم که در آن بتوانید پروکسی‌های API را قبل از اینکه API در معرض توسعه‌دهندگان خارجی قرار گیرد، بسازید و تأیید کنید.

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

سرور ورودی، TLS/SSL به طور خودکار برای هر محیط فعال می شود. دو VirtualHost در هر محیط از پیش تعریف شده است: default و secure . پیش فرض یک آدرس HTTP را تعریف می کند، در حالی که ایمن یک آدرس HTTP/S را با TLS/SSL از پیش پیکربندی شده سمت سرور تعریف می کند. در یک پیکربندی پراکسی API، شما مشخص می‌کنید که ProxyEndpoint باید به کدام VirtualHost‌ها گوش دهد. هنگام ارتقاء به prod، معمولاً با حذف VirtualHost default از پیکربندی پروکسی API، HTTP را غیرفعال می‌کنید.

به عنوان مثال، ProxyEndpoint زیر به HTTP و HTTPS گوش می دهد.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>default</VirtualHost>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

با حذف VirtualHost default از پیکربندی ProxyEndpoint، یک پروکسی API ایجاد می‌کنید که فقط در HTTPS و نه در HTTP گوش می‌دهد.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

با انتخاب Environments در منوی اصلی مدیریت UI می توانید ببینید کدام VirtualHost در یک محیط موجود است.

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

استقرار پراکسی های API در محیط ها

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

برای اطلاعات بیشتر، به درک استقرار مراجعه کنید.

توسعه تکراری در آزمون

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

ارتقاء به تولید

هنگامی که یک پروکسی API به طور کامل پیاده سازی و آزمایش شد، آماده ارتقاء به "prod" است. بازنگری پراکسی API در آزمایش برای بازنویسی بازبینی پروکسی API مستقر در prod استفاده خواهد شد.

API Services قابلیت‌هایی را برای اطمینان از استقرار یکپارچه پراکسی‌های API، به حداقل رساندن تأثیر بر برنامه‌ها و کاربران نهایی در طول فرآیند استقرار، ارائه می‌کند.

استقرار اسکریپت

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

منابع محیطی

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

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

  • URL های هدف: معمولاً پروکسی های API در طول آزمایش و تولید، URL های Backend مختلف را فراخوانی می کنند. شما می توانید از تنظیمات TargetServer برای ایجاد تنظیمات TargetEndpoint مستقل از محیط استفاده کنید. به تعادل بار در سرورهای باطن مراجعه کنید.
  • حافظه های پنهان و نقشه های کلید/مقدار: هر دو منبع ماندگاری بر اساس محیط تعیین می شوند. باید اطمینان حاصل کنید که از قراردادهای نامگذاری برای فعال کردن پراکسی های API برای ذخیره داده ها بدون نیاز به تغییرات پیکربندی در حین ارتقا استفاده می شود. به ایجاد و ویرایش کش محیطی مراجعه کنید.
  • اهداف ServiceCallout: پیام‌های سرویس ممکن است از اهداف مختلفی بسته به محیط استفاده کنند، اگر برای مثال، ServiceCallout در محیط آزمایشی یک سرویس آزمایشی را مصرف کند. به خط مشی Callout Service مراجعه کنید.

برای اینکه تنظیمات پروکسی API مستقل از محیط باشد، می توانید از دستورات شرطی نیز استفاده کنید. بیانیه شرطی ساخته شده با environment.name name می تواند برای ارزیابی محیط فعلی قبل از اجرای یک خط مشی یا قبل از مسیریابی به URL در باطن استفاده شود.

برای اطلاعات بیشتر، به درک استقرار مراجعه کنید.