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

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

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

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

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

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

توسعه محلی پیکربندی‌های پروکسی

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

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

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

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

   برای باز کردن فایل 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 است، اگرچه اگر از targetهای شرطی استفاده کنید، ممکن است فایل‌هایی با نام‌های مختلف وجود داشته باشد.

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

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

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

   cd myappdir

   قبل از بایگانی مجدد فایل‌های پیکربندی پروکسی، باید به این دایرکتوری بروید زیرا نمی‌خواهید دایرکتوری /myappdir در فایل زیپ وجود داشته باشد. دایرکتوری سطح بالا در فایل زیپ باید /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 شماره ویرایش را یک واحد افزایش می‌دهد و آن را در نمای خلاصه ویرایش نمایش می‌دهد.

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

8. نسخه جدید خود را مستقر کنید.

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

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

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

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

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

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

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

• پیکربندی پایه
• پروکسی اندپوینت
• نقطه پایانی هدف
  • پیکربندی TLS/SSL TargetEndpoint
• سیاست‌ها
• جریان‌ها
• منابع

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

/apiproxy/weatherapi.xml

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

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

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

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

پروکسی اندپوینت

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

/apiproxy/proxies/default.xml

پیکربندی ProxyEndpoint رابط ورودی (رو به کلاینت) را برای یک پروکسی API تعریف می‌کند. وقتی یک ProxyEndpoint را پیکربندی می‌کنید، در واقع پیکربندی شبکه‌ای را تنظیم می‌کنید که نحوه فراخوانی API پروکسی شده توسط برنامه‌های کلاینت ('apps') را تعریف می‌کند.

پیکربندی نمونه 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 را برای پشتیبانی از مسیریابی پویا در زمان اجرا، به صورت زنجیره‌ای تنظیم کرد. درخواست‌های ورودی را می‌توان بر اساس هدرهای HTTP، محتوای پیام، پارامترهای پرس‌وجو یا اطلاعات زمینه‌ای مانند زمان روز، منطقه و غیره، به پیکربندی‌های TargetEndpoint نامگذاری شده، مستقیماً به URLها یا به ترکیبی از این دو هدایت کرد.

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 با مقدار null تعریف کرد تا از سناریوهایی پشتیبانی کند که در آن‌ها نیازی به ارسال پیام درخواست به TargetEndpoint نباشد. این مورد زمانی مفید است که ProxyEndpoint تمام پردازش‌های لازم را انجام دهد، برای مثال با استفاده از جاوا اسکریپت برای فراخوانی یک سرویس خارجی یا بازیابی داده‌ها از یک جستجو در مخزن کلید/مقدار سرویس‌های API.

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

<RouteRule name="GoNowhere"/>

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

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

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

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

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

نقطه پایانی هدف

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

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

پیکربندی 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 می‌تواند یک target را به یکی از روش‌های زیر فراخوانی کند:

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

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

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

نقاط هدف (TargetEndpoints) اغلب نیاز به مدیریت اتصالات HTTPS با زیرساخت‌های ناهمگن backend دارند. به همین دلیل، تعدادی از تنظیمات پیکربندی 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 به backend (Cloud و Private Cloud) مراجعه کنید.

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

همچنین می‌توانید جزئیات TLS/SSL را به صورت پویا تنظیم کنید تا از الزامات زمان اجرا انعطاف‌پذیر پشتیبانی کند. به عنوان مثال، اگر پروکسی شما به دو هدف بالقوه متفاوت (یک هدف آزمایشی و یک هدف عملیاتی) متصل شود، می‌توانید پروکسی API خود را به صورت برنامه‌نویسی شده تشخیص دهید که کدام محیط را فراخوانی می‌کند و به صورت پویا ارجاعات را به keystore و truststore مناسب تنظیم کند. مقاله انجمن Apigee زیر این سناریو را با جزئیات بیشتری توضیح می‌دهد و نمونه‌هایی از پروکسی API قابل استقرار را ارائه می‌دهد: SSLInfo پویا برای TargetEndpoint با استفاده از مرجع متغیر .

در مثال زیر که نحوه تنظیم برچسب <SSLInfo> در پیکربندی TargetEndpoint را نشان می‌دهد، مقادیر می‌توانند در زمان اجرا، مثلاً توسط یک Java Callout، یک JavaScript policy یا یک Assign Message policy، ارائه شوند. از هر متغیر 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 برای Private Cloud، هنگام پیکربندی TLS/SSL با استفاده از مقادیر استاتیک یا با استفاده از متغیرهای جریان، این احتمال وجود دارد که مجبور شوید پردازنده‌های پیام را مجدداً راه‌اندازی کنید.

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

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

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

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

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

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) را مشخص می‌کند.

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

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 با متعادل‌سازی بار هدف

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

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

سیاست‌ها

دایرکتوری /policies ‎ در یک پروکسی API شامل تمام سیاست‌های موجود برای اتصال به Flows در پروکسی API است.

عناصر پیکربندی سیاست

پیوست سیاست

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

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

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

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

سیاست‌ها به ترتیبی که به یک جریان متصل می‌شوند، اجرا می‌شوند. برای مثال:

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

عناصر پیکربندی پیوست سیاست

جریان‌ها

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

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

علاوه بر این، می‌توانید یک PostClientFlow به ProxyEndpoint اضافه کنید که پس از بازگشت پاسخ به برنامه کلاینت درخواست‌کننده اجرا می‌شود. فقط سیاست MessageLogging و افزونه Google Stackdriver Logging می‌توانند به این جریان متصل شوند. 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، جریان‌ها را به ترتیب زیر اجرا می‌کند:

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

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

خط لوله پاسخ:

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

Only those Flows with policy attachments need to be configured in ProxyEndpoint or TargetEndpoint configurations. PreFlow and PostFlow need only be specified in a ProxyEndpoint or TargetEndpoint configuration when a policy needs to be enforced during PreFlow or PostFlow processing.

In contrast to conditional flows, the ordering of PreFlow and PostFlow elements is not important--the API proxy will always execute each at the appropriate point in the pipeline, regardless of where they appear in the Endpoint configuration.

Conditional Flows

ProxyEndpoints and TargetEndpoints support an unlimited number of conditional flows (also known as 'named flows').

The API proxy tests for the condition specified in the conditional flow and, if the condition is met, the processing steps in the conditional flow are executed by the API proxy. If the condition is not met, then the processing steps in the conditional flow are bypassed. Conditional flows are evaluated in the order defined in the API proxy and the first one whose condition is met is executed.

By defining conditional flows, you gain the ability to apply processing steps in an API proxy based on:

• درخواست آدرس اینترنتی
• HTTP verb (GET/PUT/POST/DELETE)
• Value of a query param, header, and form param
• Many other types of conditions

For example, the following conditional flow specifies that it is executed only when the request resource path is /accesstoken . Any inbound request with the path /accesstoken causes this flow to be executed, along with any policies that are attached to the flow. If the request path does not include the suffix /accesstoken , then the flow does not execute (although another conditional flow might).

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

Flow Configuration Elements

Step processing

The sequential ordering of conditional Flows is enforced by Apigee Edge. Conditional Flows execute from top to bottom. The first conditional Flow whose condition evaluates to true is executed, and only one conditional Flow is executed.

For example, in the following Flow configuration, any inbound request that does not include the path suffix /first or /second will cause the ThirdFlow to execute, enforcing the policy called 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>

منابع

"Resources" (resource files for use in API proxies) are scripts, code, and XSL transformations that can be attached to Flows using policies. These appear in the "Scripts" section of the API proxy editor in the management UI.

See Resource files for the supported resource types.

Resources can be stored in an API proxy, an environment, or an organization. In each case, a resource is referenced by name in a Policy. API Services resolves the name by moving from the API proxy, to environment, to organization level.

A resource stored at the organization level can be referenced by Policies in any environment. A resource stored at the environment level can be referenced by Policies in that environment. A resource stored at the API proxy level can be referenced only by Policies in that API proxy.