درک مسیرها

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

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

برای آشنایی با مسیرها و توصیف رابطه بین ProxyEndpoint و TargetEndpoint، این ویدیو را تماشا کنید.

تعیین URL مربوط به نقطه پایانی پروکسی API

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

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

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} نام محیط Edge است. به طور پیش‌فرض، تمام سازمان‌های Apigee که در فضای ابری ایجاد شده‌اند، با دو محیط تجهیز شده‌اند: ' test ' و ' prod '. هنگام استقرار یک پروکسی API، می‌توانید آن را در یک یا هر دو محیط مستقر کنید.
  • {base-path} و {resource-path} هنگام ایجاد پروکسی API تعریف می‌شوند.

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

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

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

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

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

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

تعیین URL نقطه پایانی هدف

تگ <RouteRule> در تعریف ProxyEndpoint، هدف پروکسی API را تعیین می‌کند و پس از پردازش تمام سیاست‌های موجود در PreFlow، Conditional Flows و PostFlow درخواست ProxyEndpoint ارزیابی می‌شود.

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

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

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

آدرس اینترنتی مستقیم

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

<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، مکان سرویس backend را تعیین می‌کند. در شکل بالا، URL هدف http://weather.yahooapis.com است.

اهداف مشروط

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

قانون مسیر زیر، یک هدر 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 از بالا به پایین ارزیابی می‌شوند.

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

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

مسیر تهی

یک مسیر null از سناریوهایی پشتیبانی می‌کند که در آن‌ها نیازی به ارسال پیام درخواست به TargetEndpoint نیست. این زمانی مفید است که ProxyEndpoint تمام پردازش‌های لازم را انجام دهد، به عنوان مثال با استفاده از جاوا اسکریپت برای فراخوانی یک سرویس خارجی.

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

<RouteRule name="GoNowhere"/>

بیشتر بدانید