آشنایی با مسیرها

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

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

این ویدیو را برای آشنایی با مسیرها تماشا کنید، که رابطه بین ProxyEndpoint و TargetEndpoint را توضیح می‌دهد.

درحال تعیین نشانی وب نقطه پایان پراکسی API

تصویر زیر درخواستی را نشان می‌دهد که از یک برنامه به ProxyEndpoint می‌رسد و آن درخواست به سرویس زیرینه هدایت می‌شود:

پس‌از ایجاد پراکسی میانای برنامه‌سازی کاربردی در Edge، نشانی وب پیش‌فرضی که برنامه برای دسترسی به پراکسی استفاده می‌کند به این شکل است:

http://{org-name}-{env-name}.apigee.net/{base-path}/{resource-path}

https://{org-name}-{env-name}.apigee.net/{base-path}/{resource-path}

کجا:

  • {org-name} نام سازمان شما است. این نام هنگام ایجاد حساب در Edge ایجاد می‌شود.
  • {env-name} نام محیط «لبه» است. به‌طور پیش‌فرض، همه سازمان‌های Apigee که در فضای ابری ایجاد می‌شوند با دو محیط آماده می‌شوند: «test» و «prod». هنگام استقرار یک پراکسی API، می‌توانید انتخاب کنید که آن را در یک یا هر دو محیط مستقر کنید.
  • {base-path} و {resource-path} زمانی تعریف می‌شوند که کارگزار میانای برنامه‌سازی کاربردی را ایجاد می‌کنید.

وقتی درخواستی به Edge می‌رسد، Edge نشانی وب را تجزیه می‌کند تا درخواست را به ProxyEndpoint صحیح هدایت کند. برای مثال، از نشانی وب زیر برای دسترسی به پراکسی API در Edge استفاده می‌شود:

http://myOrg-prod.apigee.net/v1/weather/forecastrss

اگر تعریف ProxyEndpoint را برای پراکسی API در شکل بالا بررسی کنید، می‌توانید ببینید که چگونه این نشانی وب توسط Edge تجزیه می‌شود:

  1. بخش دامنه نشانی وب، http://myOrg-prod.apigee.net، با میزبان مجازی در Edge مطابقت دارد. در تعریف ProxyEndpoint در بالا، پراکسی API از برچسب <VirtualHost> برای ارجاع دادن به میزبان مجازی به‌نام default استفاده می‌کند. می‌توانید چندین میزبان مجازی در محیط خود تعریف کنید.

    میزبان مجازی دامنه‌ها و درگاه‌هایی را که کارگزار پراکسی API در آن‌ها نمایان می‌شود تعریف می‌کند. میزبان مجازی همچنین مشخص می‌کند که آیا ازطریق پروتکل HTTP یا ازطریق پروتکل رمزگذاری‌شده HTTPS به پراکسی API دسترسی پیدا می‌شود. برای اطلاعات دقیق درباره میزبان‌های مجازی، به درباره میزبان‌های مجازی (نسخه بتا) مراجعه کنید.
  2. بخش دوم نشانی وب، /v1/weather، توسط عنصر <BasePath> در ProxyEndpoint تعیین می‌شود. مسیر پایه باید برای پراکسی API در محیط منحصربه‌فرد باشد تا دو پراکسی API مسیر پایه یکسانی نداشته باشند.
  3. بخش سوم نشانی وب، /forecastrss، منبعی است که توسط پراکسی API با «جریان شرطی» مربوطه که توسط برچسب <Flows> تعریف شده است تعریف می‌شود.

ویدیو: برای کسب اطلاعات بیشتر درباره نقاط پایانی پراکسی API، ویدیو کوتاهی را تماشا کنید.

درحال تعیین نشانی وب نقطه پایان هدف

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

‫ProxyEndpoint می‌تواند هدف را به‌صورت زیر تعریف کند:

  • نشانی وب مستقیم به سرویس زیرینه.
  • یک تعریف TargetEndpoint واحد.
  • چندین «نقطه پایان هدف» که در آن کارگزار API درخواست را براساس شرطی به نقطه پایان هدف واگذار می‌کند.
  • مسیر یا هدف تهی، یعنی درخواست به هدفی بازارسال نمی‌شود. درعوض، همه پردازش درخواست و تولید پاسخ در Edge انجام می‌شود.

ویدیو: برای کسب اطلاعات بیشتر درباره نقاط پایانی هدف، ویدیو کوتاهی را تماشا کنید.

نشانی وب مستقیم

‫ProxyEndpoint می‌تواند مستقیماً سرویس زیرینه را فراخوانی کند و از پیکربندی TargetEndpoint نام‌گذاری‌شده صرف‌نظر کند. برای مثال، <RouteRule> زیر همیشه با http://api.mycompany.com/myAPI: تماس HTTP برقرار می‌کند:

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

بااین‌حال، چون TargetEndpoint وجود ندارد، فقط می‌توانید به جاری‌سازی‌های تعریف‌شده توسط ProxyEndpoint خط‌مشی اضافه کنید.

هدف تکی

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

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

همه درخواست‌های این پراکسی API به تعریف TargetEndpoint یکسانی هدایت می‌شوند. برچسب <URL> در TargetEndpoint مکان سرویس زیرینه را تعیین می‌کند. در شکل بالا، نشانی وب هدف http://weather.yahooapis.com است.

هدف‌های شرطی

برچسب <RouteRule> به شما امکان می‌دهد درخواستی را براساس شرطی به هدفی هدایت کنید. می‌توانید از متغیرهای جریان، پارامترهای پُرسمان، سرایندهای HTTP، محتوای پیام، یا اطلاعات زمینه‌ای مثل زمان روز و زبان و منطقه برای تعیین نقطه پایانی هدف استفاده کنید. برای مثال، می‌توانید یک منطقه جغرافیایی، مانند ایالات متحده و پادشاهی متحد، را در نشانی وب درخواست بگنجانید. سپس می‌توانید براساس منطقه، درخواست را به نقطه پایانی هدف هدایت کنید.

قانون مسیر زیر سرصفحه HTTP را در درخواست ارزیابی می‌کند. اگر سرصفحه HTTP routeTo مقدار TargetEndpoint1 را داشته باشد، درخواست به TargetEndpoint با نام TargetEndpoint1 بازارسال می‌شود. اگر این‌طور نباشد، درخواست به TargetEndpoint2 بازارسال می‌شود.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
 <TargetEndpoint>TargetEndpoint2</TargetEndpoint>
</RouteRule>

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

همچنین مسیرهای شرطی و مرجع شرایط را ببینید.

ویدیو: ویدیو کوتاهی را تماشا کنید تا با نحوه مسیریابی به نقطه پایانی هدف بااستفاده از هدف‌های شرطی آشنا شوید.

مسیر تهی

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

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

<RouteRule name="GoNowhere"/>

بیشتر بدانید