درک مسیرها

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

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

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

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

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

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

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

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

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

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

URL مستقیم

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

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

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

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

مسیر پوچ

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

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

<RouteRule name="GoNowhere"/>

بیشتر بدانید

• درباره هاست های مجازی
• مرجع پیکربندی پروکسی API
• مرجع خواص نقطه پایانی
• تعادل بار در سرورهای باطن