این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

مرجع خواص نقطه پایانی

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

این مبحث، ویژگی‌های انتقالی را شرح می‌دهد که می‌توانند در پیکربندی‌های TargetEndpoint و ProxyEndpoint برای کنترل رفتار پیام‌رسانی و اتصال تنظیم شوند. برای پوشش کامل پیکربندی TargetEndpoint و ProxyEndpoint، به مرجع پیکربندی پروکسی API مراجعه کنید.

ویژگی‌های انتقال TargetEndpoint

عنصر HTTPTargetConnection در پیکربندی‌های TargetEndpoint مجموعه‌ای از ویژگی‌های انتقال HTTP را تعریف می‌کند. می‌توانید از این ویژگی‌ها برای تنظیم پیکربندی‌های سطح انتقال استفاده کنید.

ویژگی‌ها روی عناصر TargetEndpoint HTTPTargetConnection مطابق شکل زیر تنظیم می‌شوند:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <Properties>
      <Property name="supports.http10">true</Property>
      <Property name="request.retain.headers">User-Agent,Referer,Accept-Language</Property>
      <Property name="retain.queryparams">apikey</Property>
    </Properties>
    <CommonName>COMMON_NAME_HERE</CommonName>
  </HTTPTargetConnection>
</TargetEndpoint>

مشخصات ویژگی انتقال TargetEndpoint

نام ملک	مقدار پیش‌فرض	توضیحات
`keepalive.timeout.millis`	`60000`	زمان انتظار برای غیرفعال بودن اتصال برای اتصال هدف در مخزن اتصال. اگر اتصال در مخزن اتصال بیش از حد مشخص شده غیرفعال باشد، اتصال بسته می‌شود.
`connect.timeout.millis`	`3000`	پایان زمان اتصال هدف. در صورت وقوع پایان زمان اتصال، Edge یک کد وضعیت HTTP `503` را برمی‌گرداند. در برخی موارد، ممکن است هنگام استفاده `LoadBalancer` در تعریف TargetServer و وقوع پایان زمان، یک کد وضعیت HTTP 504 برگردانده شود. توجه: در برخی موارد، Apigee به طور خودکار اتصال را تا سه بار دوباره امتحان می‌کند. در نتیجه، کل زمان تلاش مجدد ممکن است از آنچه برای `connect.timeout.millis` پیکربندی شده است، بیشتر شود.
`io.timeout.millis`	`55000`	اگر برای تعداد میلی‌ثانیه مشخص‌شده، داده‌ای برای خواندن وجود نداشته باشد، یا اگر سوکت برای تعداد میلی‌ثانیه مشخص‌شده آماده نوشتن داده نباشد، آنگاه تراکنش به عنوان یک وقفه زمانی در نظر گرفته می‌شود. اگر هنگام نوشتن درخواست HTTP، وقفه‌ای رخ دهد، `408, Request Timeout` بازگردانده می‌شود. اگر هنگام خواندن پاسخ HTTP، وقفه‌ای رخ دهد، `504, Gateway Timeout` بازگردانده می‌شود. این مقدار همیشه باید کوچکتر از مقدار ویژگی proxy_read_timeout میزبان مجازی باشد. این مقدار باید کمتر از زمان وقفه‌ای باشد که روتر برای ارتباط با پردازنده پیام استفاده می‌کند. برای اطلاعات بیشتر به پیکربندی زمان وقفه روتر مراجعه کنید. برای اطلاعات بیشتر به تنظیمات io.timeout.millis و api.timeout برای Edge مراجعه کنید.
`supports.http10`	`true`	اگر این `true` باشد و کلاینت یک درخواست ۱.۰ ارسال کند، به مقصد نیز یک درخواست ۱.۰ ارسال می‌شود. در غیر این صورت، درخواست ۱.۱ به مقصد ارسال می‌شود.
`supports.http11`	`true`	اگر این `true` باشد و کلاینت یک درخواست ۱.۱ ارسال کند، به هدف نیز یک درخواست ۱.۱ ارسال می‌شود، در غیر این صورت درخواست ۱.۰ به هدف ارسال می‌شود.
`use.proxy`	`true`	اگر روی `true` تنظیم شود، و پیکربندی‌های پروکسی در `http.properties` (فقط برای استقرارهای داخلی) مشخص شده باشند، آنگاه اتصالات هدف برای استفاده از پروکسی مشخص شده تنظیم می‌شوند.
`use.proxy.tunneling`	`true`	اگر این مقدار روی `true` تنظیم شده باشد و پیکربندی‌های پروکسی در `http.properties` (فقط برای استقرارهای داخلی) مشخص شده باشند، اتصالات هدف طوری تنظیم می‌شوند که از تونل مشخص شده استفاده کنند. اگر هدف از TLS/SSL استفاده کند، این ویژگی نادیده گرفته می‌شود و پیام همیشه از طریق یک تونل ارسال می‌شود.
`enable.method.override`	`false`	برای متد HTTP مشخص شده، یک هدر `X-HTTP-Method-Override` روی درخواست خروجی به سرویس هدف تنظیم کنید. برای مثال، `<Property name="GET.override.method">POST</Property>`
`*.override.method`	ناموجود	برای متد HTTP مشخص شده، یک هدر `X-HTTP-Method-Override` روی درخواست خروجی تنظیم کنید. برای مثال، `<Property name="GET.override.method">POST</Property>`
`request.streaming.enabled`	`false`	به طور پیش‌فرض ( `false` )، بارهای داده درخواست HTTP در یک بافر خوانده می‌شوند و سیاست‌هایی که می‌توانند روی این بار داده عمل کنند، همانطور که انتظار می‌رود، کار می‌کنند. در مواردی که بارهای داده بزرگتر از اندازه بافر (10 مگابایت) باشند، می‌توانید این ویژگی را روی `true` تنظیم کنید. وقتی `true` ، بارهای داده درخواست HTTP در یک بافر خوانده نمی‌شوند؛ آنها به همان صورت به نقطه انتهایی هدف ارسال می‌شوند. در این حالت، هر سیاستی که روی بار داده در جریان درخواست TargetEndpoint عمل کند، نادیده گرفته می‌شود. همچنین به Streaming request and responses مراجعه کنید.
`response.streaming.enabled`	`false`	به طور پیش‌فرض ( `false` )، بارهای داده پاسخ HTTP در یک بافر خوانده می‌شوند و سیاست‌هایی که می‌توانند روی این بار داده عمل کنند، همانطور که انتظار می‌رود، کار می‌کنند. در مواردی که بارهای داده بزرگتر از اندازه بافر (10 مگابایت) باشند، می‌توانید این ویژگی را روی `true` تنظیم کنید. وقتی `true` ، بارهای داده پاسخ HTTP در یک بافر خوانده نمی‌شوند؛ آنها به همان صورت در جریان پاسخ ProxyEndpoint پخش می‌شوند. در این حالت، هر سیاستی که روی بار داده در جریان پاسخ TargetEndpoint عمل کند، نادیده گرفته می‌شود. همچنین به Streaming request and response مراجعه کنید.
`success.codes`	ناموجود	به طور پیش‌فرض، Apigee Edge کد HTTP `4XX` یا `5XX` را به عنوان خطا و کد HTTP `1XX` ، `2XX` ، `3XX` به عنوان موفقیت در نظر می‌گیرد. این ویژگی امکان تعریف صریح کدهای موفقیت را فراهم می‌کند، به عنوان مثال، `2XX, 1XX, 505` هر کد پاسخ HTTP `100` ، `200` و `505` را به عنوان موفقیت در نظر می‌گیرد. تنظیم این ویژگی، مقادیر پیش‌فرض را بازنویسی می‌کند. بنابراین، اگر می‌خواهید کد HTTP `400` را به لیست کدهای موفقیت پیش‌فرض اضافه کنید، این ویژگی را به صورت زیر تنظیم کنید: <نام ملک="success.codes">1XX، 2XX، 3XX، 400</ملک> اگر می‌خواهید فقط کد HTTP `400` به عنوان کد موفقیت در نظر گرفته شود، ویژگی را به صورت زیر تنظیم کنید: <نام ویژگی="success.codes">400</ویژگی> با تنظیم کد HTTP `400` به عنوان تنها کد موفقیت، کدهای `1XX` ، `2XX` و `3XX` به عنوان شکست در نظر گرفته می‌شوند.
`compression.algorithm`	ناموجود	به طور پیش‌فرض، Apigee Edge درخواست‌ها را با استفاده از همان نوع فشرده‌سازی که درخواست کلاینت استفاده می‌کند، به مقصد ارسال می‌کند. اگر درخواست از کلاینت با استفاده از، به عنوان مثال، فشرده‌سازی gzip دریافت شود، Apigee Edge درخواست را با استفاده از فشرده‌سازی gzip به مقصد ارسال می‌کند. اگر پاسخ دریافتی از مقصد با استفاده از deflate باشد، Apigee Edge پاسخ را با استفاده از deflate به کلاینت ارسال می‌کند. مقادیر پشتیبانی شده عبارتند از: gzip: همیشه پیام را با استفاده از فشرده‌سازی gzip ارسال کنید deflate: همیشه پیام را با استفاده از فشرده‌سازی deflate ارسال کنید هیچکدام: همیشه پیام را بدون هیچ فشرده‌سازی ارسال کنید همچنین ببینید: آیا Apigee از فشرده‌سازی/رفع فشرده‌سازی با فشرده‌سازی GZIP/deflate پشتیبانی می‌کند؟
`request.retain.headers. enabled`	`true`	به طور پیش‌فرض، Apigee Edge همیشه تمام هدرهای HTTP را در پیام‌های خروجی نگه می‌دارد. وقتی روی `true` تنظیم شود، تمام هدرهای HTTP موجود در درخواست ورودی، روی درخواست خروجی تنظیم می‌شوند.
`request.retain.headers`	ناموجود	هدرهای HTTP خاصی را از درخواست تعریف می‌کند که باید روی درخواست خروجی به سرویس هدف تنظیم شوند. به عنوان مثال، برای عبور از هدر `User-Agent` ، مقدار `request.retain.headers` را روی `User-Agent` تنظیم کنید. چندین هدر HTTP به صورت لیستی که با کاما از هم جدا شده‌اند، مشخص می‌شوند، به عنوان مثال، `User-Agent,Referer,Accept-Language` . این ویژگی `request.retain.headers.enabled` را لغو می‌کند. اگر `request.retain.headers.enabled` روی `false` تنظیم شود، هر هدری که در ویژگی `request.retain.headers` مشخص شده باشد، همچنان روی پیام خروجی تنظیم می‌شود.
`response.retain.headers. enabled`	`true`	به طور پیش‌فرض، Apigee Edge همیشه تمام هدرهای HTTP را در پیام‌های خروجی نگه می‌دارد. وقتی روی `true` تنظیم شود، تمام هدرهای HTTP موجود در پاسخ ورودی از سرویس هدف، قبل از ارسال به ProxyEndpoint، روی پاسخ خروجی تنظیم می‌شوند.
`response.retain.headers`	ناموجود	هدرهای HTTP خاصی را از پاسخ تعریف می‌کند که باید قبل از ارسال به ProxyEndpoint، روی پاسخ خروجی تنظیم شوند. به عنوان مثال، برای عبور از هدر `Expires` ، مقدار `response.retain.headers` را روی `Expires` تنظیم کنید. چندین هدر HTTP به صورت یک لیست جدا شده با کاما مشخص می‌شوند، به عنوان مثال، `Expires,Set-Cookie` . این ویژگی `response.retain.headers.enabled` را لغو می‌کند. اگر `response.retain.headers.enabled` روی `false` تنظیم شود، هر هدری که در ویژگی `response.retain.headers` مشخص شده باشد، همچنان روی پیام خروجی تنظیم می‌شود.
`retain.queryparams. enabled`	`true`	به طور پیش‌فرض، Apigee Edge همیشه تمام پارامترهای پرس‌وجو را در درخواست‌های خروجی حفظ می‌کند. وقتی روی `true` تنظیم شود، تمام پارامترهای پرس‌وجوی موجود در درخواست ورودی، روی درخواست خروجی به سرویس هدف تنظیم می‌شوند.
`retain.queryparams`	ناموجود	پارامترهای پرس‌وجوی خاصی را برای تنظیم در درخواست خروجی تعریف می‌کند. برای مثال، برای گنجاندن پارامتر پرس‌وجوی `apikey` از پیام درخواست، `retain.queryparams` را روی `apikey` تنظیم کنید. پارامترهای پرس‌وجوی چندگانه به صورت یک لیست جدا شده با کاما مشخص می‌شوند، به عنوان مثال، `apikey,environment` . این ویژگی `retain.queryparams.enabled` را لغو می‌کند.

ویژگی‌های انتقال ProxyEndpoint

عناصر ProxyEndpoint HTTPTargetConnection مجموعه‌ای از ویژگی‌های انتقال HTTP را تعریف می‌کنند. این ویژگی‌ها می‌توانند برای تنظیم پیکربندی‌های سطح انتقال استفاده شوند.

ویژگی‌ها روی عناصر ProxyEndpoint HTTPProxyConnection به شرح زیر تنظیم می‌شوند:

<ProxyEndpoint name="default">
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <Properties>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
    <VirtualHost>default</VirtualHost>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>

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

مشخصات ویژگی انتقال ProxyEndpoint

نام ملک	مقدار پیش‌فرض	توضیحات
`X-Forwarded-For`	`false`	وقتی روی `true` تنظیم شود، آدرس IP میزبان مجازی به عنوان مقدار هدر HTTP `X-Forwarded-For` به درخواست خروجی اضافه می‌شود.
`request.streaming. enabled`	`false`	به طور پیش‌فرض ( `false` )، بارهای داده درخواست HTTP در یک بافر خوانده می‌شوند و سیاست‌هایی که می‌توانند روی این بار داده عمل کنند، همانطور که انتظار می‌رود، کار می‌کنند. در مواردی که بارهای داده بزرگتر از اندازه بافر (10 مگابایت) باشند، می‌توانید این ویژگی را روی `true` تنظیم کنید. وقتی `true` ، بارهای داده درخواست HTTP در یک بافر خوانده نمی‌شوند؛ آنها به همان صورت در جریان درخواست TargetEndpoint پخش می‌شوند. در این حالت، هر سیاستی که روی بار داده در جریان درخواست ProxyEndpoint عمل کند، نادیده گرفته می‌شود. همچنین به Streaming request and responses مراجعه کنید.
`response.streaming. enabled`	`false`	به طور پیش‌فرض ( `false` )، بارهای داده پاسخ HTTP در یک بافر خوانده می‌شوند و سیاست‌هایی که می‌توانند روی این بار داده عمل کنند، همانطور که انتظار می‌رود، کار می‌کنند. در مواردی که بارهای داده بزرگتر از اندازه بافر (10 مگابایت) باشند، می‌توانید این ویژگی را روی `true` تنظیم کنید. وقتی `true` ، بارهای داده پاسخ HTTP در یک بافر خوانده نمی‌شوند؛ آنها به همان صورت برای کلاینت پخش می‌شوند. در این حالت، هر سیاستی که روی بار داده در جریان پاسخ ProxyEndpoint عمل کند، نادیده گرفته می‌شود. همچنین به Streaming requestها و responseها مراجعه کنید.
`compression.algorithm`	ناموجود	به طور پیش‌فرض، Apigee Edge نوع فشرده‌سازی تعیین‌شده برای هر پیام دریافتی را در نظر می‌گیرد. برای مثال، در جایی که یک کلاینت درخواستی را ارسال می‌کند که از فشرده‌سازی gzip استفاده می‌کند، Apigee Edge درخواست را با استفاده از فشرده‌سازی gzip به مقصد ارسال می‌کند. می‌توانید با تنظیم این ویژگی در TargetEndpoint یا ProxyEndpoint، الگوریتم‌های فشرده‌سازی را طوری پیکربندی کنید که به طور صریح اعمال شوند. مقادیر پشتیبانی‌شده عبارتند از: gzip: همیشه پیام را با استفاده از فشرده‌سازی gzip ارسال کنید deflate: همیشه پیام را با استفاده از فشرده‌سازی deflate ارسال کنید هیچکدام: همیشه پیام را بدون هیچ فشرده‌سازی ارسال کنید همچنین ببینید: آیا Apigee از فشرده‌سازی/رفع فشرده‌سازی با فشرده‌سازی GZIP/deflate پشتیبانی می‌کند؟
`api.timeout`	ناموجود	پیکربندی زمان انتظار برای پروکسی‌های API به صورت جداگانه شما می‌توانید پروکسی‌های API، حتی آنهایی که قابلیت پخش جریانی دارند، را طوری پیکربندی کنید که پس از مدت زمان مشخصی با وضعیت `504 Gateway Timeout` ، زمان انقضا داشته باشند. مورد استفاده اصلی برای مشتریانی است که پروکسی‌های API دارند که اجرای آنها زمان بیشتری طول می‌کشد. به عنوان مثال، فرض کنید به پروکسی‌های خاصی نیاز دارید که در 3 دقیقه زمان انقضا داشته باشند. در ادامه نحوه استفاده `api.timeout` آمده است. ابتدا، مطمئن شوید که متعادل‌کننده بار، روتر و پردازنده پیام را طوری پیکربندی کرده‌اید که پس از سه دقیقه، زمان انقضا داشته باشند. سپس پروکسی‌های مربوطه را طوری پیکربندی کنید که پس از سه دقیقه، زمان انقضا داشته باشند. مقدار را بر حسب میلی‌ثانیه مشخص کنید. برای مثال: `<Property name="api.timeout">180000</Property>` با این حال، توجه داشته باشید که افزایش زمان‌های انتظار سیستم می‌تواند منجر به مشکلات عملکردی شود، زیرا همه پروکسی‌هایی که تنظیم api.timeout ندارند، از زمان‌های انتظار جدید و بالاتر متعادل‌کننده بار، روتر و پردازنده پیام استفاده می‌کنند. بنابراین سایر پروکسی‌های API را که به زمان‌های انتظار طولانی‌تری نیاز ندارند، طوری پیکربندی کنید که از زمان‌های انتظار پایین‌تری استفاده کنند. به عنوان مثال، کد زیر یک پروکسی API را طوری تنظیم می‌کند که پس از ۱ دقیقه زمان انتظارش تمام شود: `<Property name="api.timeout">60000</Property>` شما نمی‌توانید این ویژگی را با یک متغیر مقداردهی کنید. مشتریانی که نمی‌توانند زمان‌های وقفه Edge را تغییر دهند، می‌توانند یک زمان وقفه پروکسی API را نیز پیکربندی کنند، البته تا زمانی که این زمان وقفه کوتاه‌تر از زمان وقفه استاندارد پردازنده پیام Edge که ۵۷ ثانیه است، باشد. برای اطلاعات بیشتر به تنظیمات io.timeout.millis و api.timeout برای Edge مراجعه کنید.

تنظیم io.timeout.millis و api.timeout برای Edge

در Edge، عملکرد io.timeout.millis و api.timeout به هم مرتبط هستند. در هر درخواست به یک پروکسی API:

روتر مقدار timeout خود را به پردازشگر پیام ارسال می‌کند. مقدار timeout روتر یا مقدار proxy_read_timeout است که توسط میزبان مجازی که درخواست را مدیریت می‌کند تنظیم شده است، یا مقدار timeout پیش‌فرض ۵۷ ثانیه است.
سپس پردازشگر پیام، api.timeout را تنظیم می‌کند:
1. اگر api.timeout در سطح پروکسی تنظیم نشده باشد، آن را روی زمان‌بندی روتر تنظیم کنید.
2. اگر api.timeout در سطح پروکسی تنظیم شده باشد، آن را در پردازنده پیام روی کمترین مقدار از زمان‌بندی روتر یا مقدار api.timeout تنظیم کنید.
مقدار api.timeout حداکثر مدت زمانی را که یک پروکسی API باید از درخواست API تا پاسخ اجرا کند، مشخص می‌کند.
پس از اجرای هر خط‌مشی در پروکسی API، یا قبل از اینکه پردازنده پیام، درخواست را به نقطه پایانی هدف ارسال کند، پردازنده پیام ( api.timeout - زمان سپری شده از شروع درخواست) را محاسبه می‌کند. اگر مقدار کمتر از صفر باشد، حداکثر زمان برای رسیدگی به درخواست منقضی شده است و پردازنده پیام 504 را برمی‌گرداند.
مقدار io.timeout.millis حداکثر زمانی را که نقطه پایانی هدف باید پاسخ دهد، مشخص می‌کند.
قبل از اتصال به یک نقطه پایانی هدف، پردازنده پیام کمترین مقدار از بین ( api.timeout - زمان سپری شده از شروع درخواست) و io.timeout.millis را تعیین می‌کند. سپس io.timeout.millis را روی آن مقدار تنظیم می‌کند.
- اگر هنگام نوشتن درخواست HTTP، وقفه‌ای رخ دهد، 408, Request Timeout بازگردانده می‌شود.
- اگر هنگام خواندن پاسخ HTTP، وقفه‌ای رخ دهد، 504, Gateway Timeout بازگردانده می‌شود.

درباره ScriptTarget برای برنامه‌های Node.js

عنصر ScriptTarget برای ادغام یک برنامه Node.js در پروکسی شما استفاده می‌شود. برای اطلاعات بیشتر در مورد استفاده از Node.js و ScriptTarget، به موارد زیر مراجعه کنید:

درباره نقاط پایانی HostedTarget

یک تگ خالی <HostedTarget/> به Edge می‌گوید که از یک برنامه Node.js که در محیط Hosted Targets مستقر شده است، به عنوان هدف خود استفاده کند. برای جزئیات بیشتر، به نمای کلی Hosted Targets مراجعه کنید.