این صفحه به‌وسیله ‏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` باشد و مشتری یک درخواست 1.0 ارسال کند، به هدف نیز درخواست 1.0 ارسال می شود. در غیر این صورت درخواست 1.1 به هدف ارسال می شود.
`supports.http11`	`true`	اگر این `true` باشد و مشتری یک درخواست 1.1 ارسال کند، هدف نیز درخواست 1.1 ارسال می شود، در غیر این صورت درخواست 1.0 به هدف ارسال می شود.
`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`	N/A	برای روش HTTP مشخص شده، یک هدر `X-HTTP-Method-Override` روی درخواست خروجی تنظیم می کند. برای مثال، `<Property name="GET.override.method">POST</Property>`
`request.streaming.enabled`	`false`	به‌طور پیش‌فرض ( `false` )، بارهای درخواستی HTTP در یک بافر خوانده می‌شوند، و خط‌مشی‌هایی که می‌توانند بر روی بارگذاری کار کنند، همانطور که انتظار می‌رود کار می‌کنند. در مواردی که محموله ها بزرگتر از اندازه بافر (10 مگابایت) هستند، می توانید این ویژگی را روی `true` تنظیم کنید. وقتی `true` ، بارهای درخواستی HTTP در بافر خوانده نمی‌شوند. آنها همانطور که هست به نقطه پایانی هدف پخش می شوند. در این حالت، هر خط مشی‌هایی که بر روی payload در جریان درخواست TargetEndpoint عمل می‌کنند دور زده می‌شوند. همچنین به جریان درخواست ها و پاسخ ها مراجعه کنید.
`response.streaming.enabled`	`false`	به‌طور پیش‌فرض ( `false` )، بارهای پاسخ HTTP در یک بافر خوانده می‌شوند و خط‌مشی‌هایی که می‌توانند بر روی بارگذاری کار کنند، همانطور که انتظار می‌رود کار می‌کنند. در مواردی که محموله ها بزرگتر از اندازه بافر (10 مگابایت) هستند، می توانید این ویژگی را روی `true` تنظیم کنید. وقتی `true` ، بارهای پاسخ HTTP در بافر خوانده نمی‌شوند. آنها همانطور که هست در جریان پاسخ ProxyEndpoint پخش می شوند. در این مورد، هر خط مشی‌هایی که بر روی payload در جریان پاسخ TargetEndpoint عمل می‌کنند دور زده می‌شوند. همچنین به جریان درخواست ها و پاسخ ها مراجعه کنید.
`success.codes`	N/A	به طور پیش فرض، Apigee Edge کد HTTP `4XX` یا `5XX` را به عنوان خطا در نظر می گیرد و کد HTTP `1XX` ، `2XX` ، `3XX` به عنوان موفقیت در نظر می گیرد. این ویژگی تعریف صریح کدهای موفقیت را فعال می کند، به عنوان مثال، `2XX, 1XX, 505` هر کد پاسخ HTTP `100` ، `200` و `505` را به عنوان موفقیت در نظر می گیرد. تنظیم این ویژگی مقادیر پیش فرض را بازنویسی می کند. بنابراین، اگر می خواهید کد HTTP `400` را به لیست کدهای موفقیت پیش فرض اضافه کنید، این ویژگی را به صورت زیر تنظیم کنید: <Property name="success.codes">1XX,2XX,3XX,400</Property> اگر می خواهید فقط کد HTTP `400` به عنوان کد موفقیت در نظر گرفته شود، ویژگی را به صورت زیر تنظیم کنید: <Property name="success.codes">400</Property> با تنظیم کد HTTP `400` به عنوان تنها کد موفقیت، کدهای `1XX` ، `2XX` و `3XX` به عنوان ناموفق تلقی می شوند.
`compression.algorithm`	N/A	به طور پیش فرض، 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`	N/A	هدرهای 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`	N/A	هدرهای 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`	N/A	پارامترهای پرس و جوی خاصی را برای تنظیم در درخواست خروجی تعریف می کند. به عنوان مثال، برای گنجاندن پارامتر query `apikey` از پیام درخواست، `retain.queryparams` روی `apikey` تنظیم کنید. چندین پارامتر پرس و جو به عنوان یک لیست جدا شده با کاما مشخص می شوند، به عنوان مثال، `apikey,environment` . این ویژگی `retain.queryparams.enabled` را لغو می کند.

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

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

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

<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 عمل می‌کنند دور زده می‌شوند. همچنین به جریان درخواست ها و پاسخ ها مراجعه کنید.
`response.streaming. enabled`	`false`	به‌طور پیش‌فرض ( `false` )، بارهای پاسخ HTTP در یک بافر خوانده می‌شوند و خط‌مشی‌هایی که می‌توانند بر روی بارگذاری کار کنند، همانطور که انتظار می‌رود کار می‌کنند. در مواردی که محموله ها بزرگتر از اندازه بافر (10 مگابایت) هستند، می توانید این ویژگی را روی `true` تنظیم کنید. وقتی `true` ، بارهای پاسخ HTTP در بافر خوانده نمی‌شوند. آنها همانطور که هست برای مشتری پخش می شوند. در این حالت، هر خط‌مشی که بر روی بار در جریان پاسخ ProxyEndpoint عمل می‌کند دور زده می‌شود. همچنین به جریان درخواست ها و پاسخ ها مراجعه کنید.
`compression.algorithm`	N/A	به‌طور پیش‌فرض، Apigee Edge نوع فشرده‌سازی را برای هر پیام دریافتی تعیین می‌کند. به عنوان مثال، جایی که یک کلاینت درخواستی را ارسال می کند که از فشرده سازی gzip استفاده می کند، Apigee Edge درخواست را با استفاده از فشرده سازی gzip به هدف قرار می دهد. می‌توانید با تنظیم این ویژگی در TargetEndpoint یا ProxyEndpoint، الگوریتم‌های فشرده‌سازی را طوری پیکربندی کنید که صریحاً اعمال شوند. مقادیر پشتیبانی شده عبارتند از: gzip: همیشه با استفاده از فشرده سازی gzip پیام ارسال کنید deflate: همیشه با استفاده از فشرده سازی deflate پیام ارسال کنید هیچ: همیشه بدون هیچ فشرده سازی پیام ارسال کنید همچنین ببینید: آیا Apigee از فشرده‌سازی/فشرده‌سازی با فشرده‌سازی GZIP/deflate پشتیبانی می‌کند؟
`api.timeout`	N/A	مهلت زمانی را برای تک تک پراکسی های API پیکربندی کنید می‌توانید پروکسی‌های API را پیکربندی کنید، حتی آن‌هایی که پخش جریانی را فعال کرده‌اند، تا پس از مدت زمان مشخصی با وضعیت `504 Gateway Timeout` تمام شوند. مورد استفاده اولیه برای مشتریانی است که پروکسی های API دارند که اجرای آنها بیشتر طول می کشد. به عنوان مثال، بگویید که برای 3 دقیقه به پراکسی های خاصی نیاز دارید. در زیر نحوه استفاده از `api.timeout` آورده شده است. ابتدا، مطمئن شوید که بار متعادل کننده، روتر و پردازشگر پیام را به گونه ای پیکربندی کنید که پس از سه دقیقه زمان آن تمام شود. سپس پراکسی‌های مربوطه را پیکربندی کنید تا در سه دقیقه زمان‌بندی شوند. مقدار را بر حسب میلی ثانیه مشخص کنید. به عنوان مثال: `<Property name="api.timeout">180000</Property>` با این حال، توجه داشته باشید که افزایش زمان‌های زمانی سیستم می‌تواند منجر به مشکلات عملکرد شود، زیرا همه پراکسی‌ها بدون تنظیم api.timeout از مهلت زمانی جدید، روتر و پردازشگر پیام استفاده می‌کنند. بنابراین سایر پراکسی‌های API را پیکربندی کنید که برای استفاده از تایم‌اوت‌های کمتر به زمان‌های زمانی طولانی‌تری نیاز ندارند. به عنوان مثال، موارد زیر یک پروکسی API را پس از 1 دقیقه تنظیم می‌کند که زمان آن تمام شود: `<Property name="api.timeout">60000</Property>` شما نمی توانید این ویژگی را با یک متغیر تنظیم کنید. مشتریانی که نمی‌توانند مهلت‌های زمانی Edge را تغییر دهند، می‌توانند یک مهلت زمانی پروکسی API را نیز پیکربندی کنند، البته تا زمانی که مهلت زمانی کوتاه‌تر از مهلت زمانی استاندارد پردازشگر پیام Edge 57 ثانیه باشد. برای اطلاعات بیشتر به تنظیمات io.timeout.millis و api.timeout برای Edge مراجعه کنید.

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

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

روتر مقدار زمان وقفه خود را به پردازشگر پیام ارسال می کند. مقدار تایم‌اوت روتر یا مقدار proxy_read_timeout است که توسط میزبان مجازی که درخواست را مدیریت می‌کند، تنظیم شده است، یا مقدار وقفه پیش‌فرض 57 ثانیه است.
سپس پردازشگر پیام api.timeout را تنظیم می کند:
1. اگر api.timeout در سطح پروکسی تنظیم نشده است، آن را روی مهلت روتر تنظیم کنید.
2. اگر api.timeout در سطح پراکسی تنظیم شده است، آن را روی Message Processor روی کمتر از زمان پایان مسیر یا مقدار 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 مستقر شده است به عنوان هدف خود استفاده کند. برای جزئیات، به نمای کلی اهداف میزبانی شده مراجعه کنید.