مرجع پیکربندی پروکسی API

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

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

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

رایج‌ترین روش‌های ویرایش تنظیمات پروکسی عبارتند از:

• استفاده از ویرایشگر XML در رابط کاربری Edge
• پیکربندی را دانلود کنید و آن را به صورت محلی ویرایش کنید، همانطور که در توسعه محلی تنظیمات پروکسی توضیح داده شده است.

توسعه محلی تنظیمات پروکسی

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

این بخش نحوه استفاده از رابط کاربری را برای دانلود یک پراکسی مخدوش موجود، ویرایش و سپس آپلود مجدد آن به Edge برای استقرار توضیح می‌دهد. همچنین می توانید از apigeetool برای دانلود و استقرار یک پیکربندی پراکسی جدید استفاده کنید (به ترتیب با استفاده از دستورات fetchproxy و deployproxy .)

برای ویرایش یک پیکربندی پروکسی به صورت محلی با استفاده از رابط کاربری:

1. پیکربندی پراکسی فعلی را در رابط کاربری Edge دانلود کنید. (در نمای API Proxies، Project > Download Revision را انتخاب کنید.)
2. در دستگاه محلی خود، یک دایرکتوری جدید ایجاد کنید و فایل ZIP دانلود شده را در آن گسترش دهید.

   برای گسترش فایل ZIP، می توانید از ابزاری مانند unzip استفاده کنید، همانطور که در مثال زیر نشان داده شده است:

   mkdir myappdir
   unzip ./my-app_app_rev3_2019_04_20.zip -d myappdir

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

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

   به عنوان مثال، برای فعال کردن نظارت بر سلامت در پروکسی API خود، فایل پیکربندی TargetEndpoint را در فهرست /apiproxy/targets/ ویرایش کنید. فایل پیش فرض در این دایرکتوری default.xml است، اگرچه اگر از اهداف شرطی استفاده کنید ممکن است فایل هایی با نام های مختلف وجود داشته باشد.

   در این حالت، اگر فایل پیکربندی TargetEndpoint و دایرکتوری آن وجود نداشت، آنها را ایجاد کنید.

4. پس از اتمام ویرایش فایل های پیکربندی پروکسی، حتما تغییرات خود را ذخیره کنید.
5. به دایرکتوری جدیدی که هنگام گسترش فایل‌های ZIP (ریشه فایل‌های پیکربندی توسعه‌یافته) ایجاد کرده‌اید، تغییر دهید.

   به عنوان مثال، اگر فایل ها را در پوشه /myappdir گسترش داده اید، همانطور که در مثال زیر نشان می دهد، به آن دایرکتوری تغییر دهید:

   cd myappdir

   شما باید قبل از بایگانی مجدد فایل های پیکربندی پروکسی خود را به این دایرکتوری تغییر دهید زیرا نمی خواهید پوشه /myappdir در فایل ZIP گنجانده شود. دایرکتوری سطح بالای فایل ZIP باید /apiproxy باشد.

6. فایل های پیکربندی پروکسی، از جمله فایل های جدید یا تغییر یافته را دوباره بایگانی کنید. همانطور که در مثال زیر نشان داده شده است، می توانید از ابزاری مانند zip استفاده کنید:

   zip my-new-proxy.zip -r .

   دایرکتوری سطح بالای فایل ZIP باید /apiproxy باشد.

   هیچ شرایط خاصی برای نام فایل ZIP وجود ندارد. به عنوان مثال، شما نیازی به افزایش شماره ویرایش یا تعیین تاریخ در نام فایل ندارید، اما انجام این کار می تواند برای اشکال زدایی یا کنترل منبع مفید باشد.

   هنگامی که آن را آپلود می‌کنید، Edge شماره ویرایش پیکربندی پراکسی جدید را برای شما افزایش می‌دهد.

7. پیکربندی پراکسی جدید را با استفاده از رابط کاربری Edge آپلود کنید. (در نمای API Proxies ، Project > Upload a New Revision را انتخاب کنید.)

   اگر با خطایی مانند Bundle is invalid. Empty bundle. ، سپس مطمئن شوید که دایرکتوری سطح بالای فایل ZIP شما /apiproxy است. اگر اینطور نیست، فایل های پیکربندی پروکسی خود را از ریشه دایرکتوری توسعه یافته مجدداً بایگانی کنید.

   پس از آپلود پیکربندی پراکسی جدید، Edge شماره ویرایش را افزایش می‌دهد و آن را در نمای Revision Summary نمایش می‌دهد.

   Edge نسخه جدید را پس از آپلود با رابط کاربری برای شما اجرا نمی کند.

8. بازبینی جدید خود را اجرا کنید.

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

ساختار پروکسی API

یک پروکسی API از پیکربندی زیر تشکیل شده است:

ساختار و محتویات دایرکتوری پروکسی API

اجزای جدول بالا توسط فایل های پیکربندی در ساختار دایرکتوری زیر تعریف شده اند:

فایل های پیکربندی و ساختار دایرکتوری یک پروکسی API

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

• پیکربندی پایه
• ProxyEndpoint
• TargetEndpoint
  • پیکربندی TLS/SSL TargetEndpoint
• سیاست ها
• جریان می یابد
• منابع

پیکربندی پایه

/apiproxy/weatherapi.xml

پیکربندی پایه برای یک پراکسی API، که نام پراکسی API را مشخص می کند. نام باید در یک سازمان منحصر به فرد باشد.

پیکربندی نمونه:

<APIProxy name="weatherapi">
</APIProxy>

عناصر پیکربندی پایه

ProxyEndpoint

تصویر زیر جریان درخواست/پاسخ را نشان می دهد:

/apiproxy/proxies/default.xml

پیکربندی ProxyEndpoint رابط ورودی (رو به مشتری) را برای یک پروکسی API تعریف می کند. هنگامی که یک ProxyEndpoint را پیکربندی می‌کنید، یک پیکربندی شبکه را تنظیم می‌کنید که مشخص می‌کند چگونه برنامه‌های سرویس گیرنده ("برنامه‌ها") باید API پروکسی را فراخوانی کنند.

نمونه پیکربندی ProxyEndpoint زیر در /apiproxy/proxies ذخیره می‌شود:

<ProxyEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <VirtualHost>default</VirtualHost>
  </HTTPProxyConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

عناصر پیکربندی مورد نیاز در یک ProxyEndpoint اولیه عبارتند از:

عناصر پیکربندی ProxyEndpoint

نحوه پیکربندی RouteRules

یک TargetEndpoint با نام به یک فایل پیکربندی در زیر /apiproxy/targets اشاره دارد که RouteRule پس از پردازش توسط ProxyEndpoint یک درخواست را به آن ارسال می کند.

به عنوان مثال، RouteRule زیر به پیکربندی /apiproxy/targets/myTarget.xml اشاره دارد:

<RouteRule name="default">
  <TargetEndpoint>myTarget</TargetEndpoint>
</RouteRule>

فراخوانی مستقیم URL

یک ProxyEndpoint همچنین می تواند مستقیماً یک سرویس Backend را فراخوانی کند. فراخوانی مستقیم URL هر پیکربندی TargetEndpoints با نام را در زیر /apiproxy/targets دور می‌زند. به همین دلیل، TargetEndpoint یک پیکربندی پروکسی API اختیاری است، اگرچه، در عمل، فراخوانی مستقیم از ProxyEndpoint توصیه نمی شود.

برای مثال، RouteRule زیر یک تماس HTTP با http://api.mycompany.com/v2 برقرار می کند.

<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL> 
</RouteRule>

مسیرهای مشروط

RouteRules را می توان برای پشتیبانی از مسیریابی پویا در زمان اجرا زنجیره ای کرد. درخواست‌های ورودی را می‌توان به پیکربندی‌های TargetEndpoint با نام، مستقیماً به URLها یا ترکیبی از این دو، بر اساس سرصفحه‌های HTTP، محتوای پیام، پارامترهای پرس و جو یا اطلاعات زمینه‌ای مانند زمان روز، منطقه محلی و غیره هدایت کرد.

RouteRules شرطی مانند سایر دستورات شرطی در Apigee Edge کار می کند. مرجع شرایط و مرجع متغیرها را ببینید.

به عنوان مثال، ترکیب RouteRule زیر ابتدا درخواست ورودی را برای تأیید مقدار هدر HTTP ارزیابی می کند. اگر هدر HTTP routeTo دارای مقدار TargetEndpoint1 باشد، آنگاه درخواست به TargetEndpoint با نام TargetEndpoint1 ارسال می شود. اگر نه، درخواست ورودی به http://api.mycompany.com/v2 ارسال می شود.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

مسیرهای پوچ

یک RouteRule پوچ را می توان برای پشتیبانی از سناریوهایی تعریف کرد که در آن پیام درخواست نیازی به ارسال به TargetEndpoint نیست. این زمانی مفید است که ProxyEndpoint تمام پردازش‌های لازم را انجام می‌دهد، برای مثال با استفاده از جاوا اسکریپت برای فراخوانی یک سرویس خارجی یا بازیابی داده‌ها از جستجو در ذخیره‌سازی کلید/مقدار سرویس‌های API.

به عنوان مثال، موارد زیر یک مسیر تهی را تعریف می کنند:

<RouteRule name="GoNowhere"/>

مسیرهای تهی شرطی می توانند مفید باشند. در مثال زیر، یک مسیر تهی پیکربندی شده است تا زمانی اجرا شود که یک هدر HTTP request.header.X-DoNothing دارای مقداری غیر از null باشد.

<RouteRule name="DoNothingOnDemand">
  <Condition>request.header.X-DoNothing != null</Condition>
</RouteRule>

به یاد داشته باشید که RouteRules را می توان زنجیره ای کرد، بنابراین یک مسیر تهی شرطی معمولاً یکی از اجزای مجموعه ای از RouteRules است که برای پشتیبانی از مسیریابی شرطی طراحی شده است.

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

<RouteRule name="DoNothingUnlessTheCacheIsStale">
  <Condition>lookupcache.LookupCache-1.cachehit is true</Condition>
</RouteRule>

TargetEndpoint

TargetEndpoint معادل خروجی ProxyEndpoint است. یک TargetEndpoint به عنوان سرویس گیرنده برای یک سرویس پشتیبان یا API عمل می کند - درخواست ها را ارسال می کند و پاسخ ها را دریافت می کند.

یک پروکسی API نیازی به هیچ نقطه هدفی ندارد. ProxyEndpoints را می توان برای فراخوانی مستقیم URL ها پیکربندی کرد. یک پراکسی API بدون TargetEndpoint معمولاً حاوی یک ProxyEndpoint است که مستقیماً یک سرویس پشتیبان را فراخوانی می کند یا برای فراخوانی یک سرویس با استفاده از جاوا یا جاوا اسکریپت پیکربندی شده است.

پیکربندی TargetEndpoint

/targets/default.xml

TargetEndpoint اتصال خروجی را از Apigee Edge به سرویس یا منبع دیگری تعریف می کند.

در اینجا یک نمونه پیکربندی TargetEndpoint آمده است:

<TargetEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <SSLInfo/>
  </HTTPTargetConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <ScriptTarget/>
  <LocalTargetConnection/>
</TargetEndpoint>

عناصر پیکربندی TargetEndpoint

یک TargetEndpoint می تواند یک هدف را به یکی از روش های زیر فراخوانی کند:

• HTTPTargetConnection برای تماس‌های HTTP(S).
• LocalTargetConnection برای زنجیره محلی پروکسی به پروکسی
• ScriptTarget برای تماس با اسکریپت Node.js میزبان Edge

فقط یکی از اینها را در TargetEndpoint پیکربندی کنید.

پیکربندی TLS/SSL TargetEndpoint

TargetEndpoints اغلب نیاز به مدیریت اتصالات HTTPS با زیرساخت باطن ناهمگن دارند. به همین دلیل، تعدادی از تنظیمات پیکربندی TLS/SSL پشتیبانی می شوند.

عناصر پیکربندی TLS/SSL TargetEndpoint

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>    
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>

<Protocols>
 <Protocol>TLSv1.1</Protocol>
 <Protocol>TLSv1.2</Protocol>
</Protocols>

<CommonName wildcardMatch="true">*.myhost.com</CommonName>

نمونه TargetEndpoint با فعال کردن احراز هویت مشتری خروجی

<TargetEndpoint name="default">
  <HttpTargetConnection>
        <URL>https://myservice.com</URL>
    <SSLInfo>
      <Enabled>true</Enabled>
      <ClientAuthEnabled>true</ClientAuthEnabled>
      <KeyStore>myKeystore</KeyStore>
      <KeyAlias>myKey</KeyAlias>
      <TrustStore>myTruststore</TrustStore>
    </SSLInfo>
  </HttpTargetConnection>
</TargetEndpoint>

برای دستورالعمل‌های دقیق، به پیکربندی TLS از Edge به باطن (Cloud و Private Cloud) مراجعه کنید.

استفاده از متغیرهای جریان برای تنظیم مقادیر TLS/SSL به صورت پویا

شما همچنین می توانید به صورت پویا جزئیات TLS/SSL را برای پشتیبانی از الزامات زمان اجرا انعطاف پذیر تنظیم کنید. به عنوان مثال، اگر پراکسی شما به دو هدف بالقوه متفاوت (یک هدف آزمایشی و یک هدف تولید) متصل شود، می‌توانید از پروکسی API خود بخواهید که به طور برنامه‌ریزی محیطی را که در حال فراخوانی است تشخیص دهد و به‌طور پویا ارجاع‌ها را به keystore و truststore مناسب تنظیم کنید. مقاله انجمن Apigee زیر این سناریو را با جزئیات بیشتری توضیح می‌دهد و نمونه‌های پراکسی API قابل اجرا را ارائه می‌کند: https://community.apigee.com/articles/21424/dynamic-sslinfo-for-targetendpoint-using-variable.html .

در مثال زیر از نحوه تنظیم تگ <SSLInfo> در پیکربندی TargetEndpoint، مقادیر را می توان در زمان اجرا ارائه کرد، به عنوان مثال، یک Java Callout، یک خط مشی جاوا اسکریپت، یا یک خط مشی Assign Message. از هر متغیر پیام حاوی مقادیری که می خواهید تنظیم کنید استفاده کنید.

متغیرها فقط در عناصر زیر مجاز هستند.

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled>
    <KeyStore>{myvars.ssl.keystore}</KeyStore>
    <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias>
    <TrustStore>{myvars.ssl.trustStore}</TrustStore>
</SSLInfo>

استفاده از مراجع برای تنظیم پویا مقادیر TLS/SSL

هنگام پیکربندی TargetEndpoint که از HTTPS استفاده می کند، باید موردی را در نظر بگیرید که گواهی TLS/SSL منقضی شود یا تغییر در پیکربندی سیستم شما را ملزم به به روز رسانی گواهی کند. در نصب Edge for Private Cloud، هنگام پیکربندی TLS/SSL با استفاده از مقادیر استاتیک یا با استفاده از متغیرهای جریان، این احتمال وجود دارد که مجبور شوید پردازشگرهای پیام را مجددا راه اندازی کنید.

برای اطلاعات بیشتر، به‌روزرسانی گواهی TLS را ببینید.

با این حال، می‌توانید به‌صورت اختیاری، TargetEndpoint را به گونه‌ای پیکربندی کنید که به جای آن از یک مرجع به keystore یا truststore استفاده کند. مزیت استفاده از مرجع این است که می‌توانید مرجع را به‌روزرسانی کنید تا به یک فروشگاه کلید یا Truststore دیگر برای به‌روزرسانی گواهی TLS/SSL بدون نیاز به راه‌اندازی مجدد پردازشگرهای پیام اشاره کند.

به عنوان مثال، نشان داده شده در زیر یک TargetEndpoint است که از یک مرجع به keystore استفاده می کند:

<SSLInfo> 
    <Enabled>true</Enabled> 
    <ClientAuthEnabled>false</ClientAuthEnabled> 
    <KeyStore>ref://keystoreref</KeyStore> 
    <KeyAlias>myKeyAlias</KeyAlias> 
</SSLInfo>

برای ایجاد مرجع با نام keystoreref از فراخوانی POST API زیر استفاده کنید:

curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
-d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

مرجع نام keystore و نوع آن را مشخص می کند.

برای مشاهده مرجع از تماس GET API زیر استفاده کنید:

curl -X GET https://api.enterprise.apigee.com/v1/o/[org_name}/e/{env_name}/references/keystoreref -u uname:password

برای اینکه بعداً مرجع را تغییر دهید تا به یک فروشگاه کلید دیگر اشاره کند، و مطمئن شوید که نام مستعار همان نام است، از فراخوانی PUT زیر استفاده کنید:

curl -X PUT -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references/keystoreref \
-d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

TargetEndpoint با متعادل کردن بار هدف

TargetEndpoints از تعادل بار در چندین TargetServer با نام با استفاده از سه الگوریتم متعادل کننده بار پشتیبانی می کند.

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

سیاست ها

دایرکتوری /policies در یک پراکسی API شامل تمام خط مشی های موجود برای پیوست شدن به جریان ها در پراکسی API است.

عناصر پیکربندی خط مشی

پیوست خط مشی

تصویر زیر دنباله اجرای جریان های پروکسی API را نشان می دهد:

همانطور که در بالا نشان داده شده است:

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

<Step><Name>MyPolicy</Name></Step>

خط‌مشی‌ها به ترتیبی که به یک جریان متصل می‌شوند اجرا می‌شوند. به عنوان مثال:

<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>

عناصر پیکربندی پیوست خط مشی

جریان می یابد

ProxyEndpoint و TargetEndpoint خط لوله ای را برای پردازش پیام درخواست و پاسخ تعریف می کنند. خط لوله پردازش از یک جریان درخواست و یک جریان پاسخ تشکیل شده است. هر جریان درخواست و جریان پاسخ به یک PreFlow، یک یا چند جریان اختیاری «شرطی» یا «نام» و یک PostFlow تقسیم می‌شود.

• PreFlow: همیشه اجرا می شود. قبل از هر جریان شرطی اجرا می شود.
• PostFlow: همیشه اجرا می شود. پس از هر جریان شرطی اجرا می شود.

علاوه بر این، می توانید یک PostClientFlow را به ProxyEndpoint اضافه کنید که پس از بازگشت پاسخ به برنامه مشتری درخواست کننده اجرا می شود. فقط خط مشی MessageLogging و Google Stackdriver Logging Extension را می توان به این جریان پیوست. PostClientFlow تأخیر پروکسی API را کاهش می‌دهد و اطلاعاتی را برای گزارش‌گیری در دسترس قرار می‌دهد که تا زمانی که پاسخ به مشتری بازگردانده نمی‌شود، محاسبه نمی‌شوند، مانند client.sent.start.timestamp و client.sent.end.timestamp . این جریان عمدتاً برای اندازه گیری فاصله زمانی بین مهرهای زمانی شروع و پایان برای پیام پاسخ.

یک ویدیوی نحوه سریع تماشا کنید

در اینجا نمونه ای از PostClientFlow با خط مشی ثبت پیام پیوست شده است.

    ...
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <PostClientFlow>
        <Request/>
        <Response>
            <Step>
                <Name>Message-Logging-1</Name>
            </Step>
        </Response>
    </PostClientFlow>
    ...

خط لوله پردازش پراکسی API Flow ها را به ترتیب زیر اجرا می کند:

خط لوله درخواست:

1. درخواست پراکسی PreFlow
2. جریانهای مشروط درخواست پروکسی (اختیاری)
3. درخواست پروکسی PostFlow
4. PreFlow درخواست هدف
5. جریانهای مشروط درخواست هدف (اختیاری)
6. درخواست هدف PostFlow

خط لوله پاسخ:

1. پاسخ هدف PreFlow
2. جریانهای شرطی پاسخ هدف (اختیاری)
3. پاسخ هدف PostFlow
4. PreFlow پاسخ پروکسی
5. جریانهای مشروط پاسخ پراکسی (اختیاری)
6. پاسخ پروکسی PostFlow
7. پاسخ PostClientFlow (اختیاری)

فقط جریان‌هایی که پیوست‌های خط‌مشی دارند باید در پیکربندی‌های ProxyEndpoint یا TargetEndpoint پیکربندی شوند. PreFlow و PostFlow فقط باید در یک پیکربندی ProxyEndpoint یا TargetEndpoint مشخص شوند که یک خط مشی باید در طول پردازش PreFlow یا PostFlow اعمال شود.

برخلاف جریان‌های شرطی، ترتیب عناصر PreFlow و PostFlow مهم نیست - پراکسی API همیشه هر کدام را در نقطه مناسبی از خط لوله اجرا می‌کند، صرف نظر از اینکه کجا در پیکربندی نقطه پایانی ظاهر می‌شوند.

جریان های مشروط

ProxyEndpoints و TargetEndpoints از تعداد نامحدودی از جریان‌های شرطی پشتیبانی می‌کنند (همچنین به عنوان «جریان‌های نام‌گذاری شده» نیز شناخته می‌شوند.

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

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

• درخواست URI
• فعل HTTP (GET/PUT/POST/DELETE)
• مقدار پارامتر پرس و جو، هدر و پارامتر فرم
• بسیاری از انواع دیگر شرایط

به عنوان مثال، جریان شرطی زیر مشخص می کند که تنها زمانی اجرا می شود که مسیر منبع درخواست /accesstoken باشد. هر درخواست ورودی با مسیر /accesstoken باعث می شود که این جریان به همراه هر سیاستی که به جریان متصل است اجرا شود. اگر مسیر درخواست شامل پسوند /accesstoken نباشد، جریان اجرا نمی‌شود (اگرچه ممکن است یک جریان شرطی دیگر).

<Flows>
  <Flow name="TokenEndpoint">
    <Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
    <Request>
      <Step>
        <Name>GenerateAccessToken</Name>
      </Step>
    </Request> 
  </Flow>
</Flows>   

عناصر پیکربندی جریان

پردازش مرحله ای

ترتیب متوالی جریان های شرطی توسط Apigee Edge اعمال می شود. جریان های شرطی از بالا به پایین اجرا می شوند. اولین جریان شرطی که شرط آن true ارزیابی می شود اجرا می شود و فقط یک جریان شرطی اجرا می شود.

به عنوان مثال، در پیکربندی Flow زیر، هر درخواست ورودی که شامل پسوند مسیر /first یا /second نباشد، باعث می‌شود ThirdFlow اجرا شود و سیاستی به نام Return404 را اجرا کند.

<Flows>
  <Flow name="FirstFlow">
    <Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="SecondFlow">
    <Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
      <Step><Name>SecondPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="ThirdFlow">
    <Request>
      <Step><Name>Return404</Name></Step>
    </Request>
  </Flow>
</Flows>

منابع

«منابع» (فایل‌های منبع برای استفاده در پراکسی‌های API) اسکریپت‌ها، کدها و تبدیل‌های XSL هستند که می‌توانند با استفاده از خط‌مشی‌ها به جریان‌ها پیوست شوند. اینها در بخش «اسکریپت‌ها» ویرایشگر پراکسی API در رابط کاربری مدیریت ظاهر می‌شوند.

فایل های منبع را برای انواع منابع پشتیبانی شده ببینید.

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

یک منبع ذخیره شده در سطح سازمان می تواند توسط سیاست ها در هر محیطی ارجاع داده شود. منبعی که در سطح محیط ذخیره شده است را می توان توسط سیاست های موجود در آن محیط ارجاع داد. منبعی که در سطح پراکسی API ذخیره شده است را فقط می توان توسط سیاست های موجود در آن پراکسی API ارجاع داد.