Kebijakan ResponseCache

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

Lihat dokumentasi Apigee Edge.

ikon kebijakan

Menyimpan data dalam cache dari resource backend, sehingga mengurangi jumlah permintaan ke resource. Saat aplikasi membuat permintaan ke URI yang sama, Anda dapat menggunakan kebijakan ini untuk menampilkan respons yang di-cache, bukan meneruskan permintaan tersebut ke server backend. Kebijakan ResponseCache dapat meningkatkan performa API Anda melalui pengurangan latensi dan traffic jaringan.

Kebijakan ini adalah Kebijakan yang dapat diperluas dan penggunaan kebijakan ini mungkin memiliki implikasi biaya atau penggunaan, bergantung pada lisensi Apigee Anda. Untuk informasi tentang jenis kebijakan dan implikasi penggunaan, lihat Jenis kebijakan.

Anda mungkin akan menemukan ResponseCache paling berguna saat data backend yang digunakan oleh API Anda hanya diperbarui secara berkala. Misalnya, bayangkan Anda memiliki API yang menampilkan data laporan cuaca yang hanya diperbarui setiap sepuluh menit. Dengan menggunakan ResponseCache untuk menampilkan respons yang di-cache di antara refresh, Anda dapat mengurangi jumlah permintaan yang mencapai backend. Hal ini juga mengurangi jumlah hop jaringan.

Untuk penyimpanan dalam cache jangka pendek tujuan umum, pertimbangkan untuk menggunakan kebijakan PopulateCache. Kebijakan tersebut digunakan bersama dengan kebijakan LookupCache (untuk membaca entri cache) dan kebijakan InvalidateCache (untuk membatalkan validasi entri).

Tonton video berikut untuk mengetahui pengantar kebijakan Cache Respons.

Sampel

Cache 10 menit

Contoh ini menunjukkan cara menyimpan respons yang di-cache selama 10 menit.

Misalkan Anda memiliki API di URL berikut:

http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778

Anda menggunakan parameter kueri w sebagai kunci cache. Apigee memeriksa nilai parameter kueri w setiap kali permintaan diterima. Jika respons yang valid (yaitu, tidak habis masa berlakunya) ada dalam cache, pesan respons yang di-cache akan ditampilkan ke klien yang meminta.

Sekarang bayangkan Anda memiliki kebijakan ResponseCache yang dikonfigurasi sebagai berikut.

<ResponseCache name="ResponseCache">
    <CacheKey>
        <KeyFragment ref="request.queryparam.w" />
    </CacheKey>
    <ExpirySettings>
        <TimeoutInSeconds>600</TimeoutInSeconds>
    </ExpirySettings>
</ResponseCache>

Saat pertama kali proxy API menerima pesan permintaan untuk URL berikut, respons akan di-cache. Pada permintaan kedua dalam waktu 10 menit, pencarian cache akan terjadi -- respons yang di-cache akan ditampilkan ke aplikasi tanpa permintaan yang diteruskan ke layanan backend.

http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778

Melewati pencarian cache

Contoh berikut menunjukkan cara melewati pencarian cache dan memuat ulang cache. Lihat juga video ini tentang penggunaan SkipCacheLookup.

Kondisi SkipCacheLookup opsional (jika dikonfigurasi) dievaluasi di jalur permintaan. Jika kondisi bernilai benar, pencarian cache akan dilewati dan cache akan dimuat ulang.

Penggunaan umum pembaruan cache bersyarat adalah kondisi yang menentukan header HTTP tertentu yang menyebabkan kondisi dievaluasi menjadi benar. Aplikasi klien dengan skrip dapat dikonfigurasi untuk mengirimkan permintaan secara berkala dengan header HTTP yang sesuai, yang secara eksplisit menyebabkan cache respons dimuat ulang.

Misalnya, bayangkan panggilan ke API di URL berikut:

'http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778' -H "bypass-cache:true"

Sekarang, bayangkan kebijakan ResponseCache berikut yang dikonfigurasi di proxy tersebut. Perhatikan bahwa kondisi bypass-cache disetel ke true.

<ResponseCache name="ResponseCache">
    <CacheKey>
        <KeyFragment ref="request.queryparam.w" />
    </CacheKey>
    <!-- Explicitly refresh the cached response -->
    <SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup>
    <ExpirySettings>
        <TimeoutInSeconds>600</TimeoutInSeconds>
    </ExpirySettings>
</ResponseCache>

Untuk mengetahui informasi selengkapnya tentang kondisi, lihat Variabel dan kondisi alur.

Referensi elemen

Referensi elemen menjelaskan elemen dan atribut kebijakan.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1">
    <DisplayName>Response Cache 1</DisplayName>
    <Properties/>
    <CacheKey>
        <Prefix/>
        <KeyFragment ref="request.uri" />
    </CacheKey>
    <Scope>Exclusive</Scope>
    <ExpirySettings>
        <ExpiryDate/>
        <TimeOfDay/>
        <TimeoutInSeconds ref="flow.variable.here">300</TimeoutInSeconds>
    </ExpirySettings>
    <CacheResource>cache_to_use</CacheResource>
    <CacheLookupTimeoutInSeconds/>
    <ExcludeErrorResponse/>
    <SkipCacheLookup/>
    <SkipCachePopulation/>
    <UseAcceptHeader/>
    <UseResponseCacheHeaders/>
</ResponseCache>

Atribut <ResponseCache>

<ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1">

Tabel berikut menjelaskan atribut yang sama untuk semua elemen induk kebijakan:

Atribut Deskripsi Default Kehadiran
name

Nama internal kebijakan. Nilai atribut name dapat berisi huruf, angka, spasi, tanda hubung, garis bawah, dan titik. Nilai ini tidak boleh melebihi 255 karakter.

Atau, gunakan elemen <DisplayName> untuk memberi label kebijakan di editor proxy UI pengelolaan dengan nama natural-language yang berbeda.

T/A Diperlukan
continueOnError

Setel ke false untuk menampilkan error jika kebijakan gagal. Ini adalah perilaku yang wajar untuk sebagian besar kebijakan.

Setel ke true agar eksekusi alur tetap berlanjut bahkan setelah kebijakan gagal. Lihat juga:

false Opsional
enabled

Setel ke true untuk menerapkan kebijakan.

Setel ke false untuk menonaktifkan kebijakan. Kebijakan tidak akan diterapkan meskipun tetap melekat pada alur.

true Opsional
async

Atribut ini sudah tidak digunakan lagi.

false Tidak digunakan lagi

Elemen <DisplayName>

Gunakan selain atribut name untuk memberi label kebijakan di editor proxy UI pengelolaan dengan nama natural-language yang berbeda.

<DisplayName>Policy Display Name</DisplayName>
Default

T/A

Jika Anda menghapus elemen ini, nilai atribut name kebijakan akan digunakan.

Kehadiran Opsional
Jenis String

Elemen <CacheKey>

Mengonfigurasi pointer unik ke bagian data yang disimpan dalam cache.

Kunci cache dibatasi hingga ukuran 2 KB.

<CacheKey>
    <Prefix>string</Prefix>
    <KeyFragment ref="variable_name" />
    <KeyFragment>literal_string</KeyFragment>
</CacheKey>

Default:

T/A

Kehadiran:

Wajib

Jenis:

T/A

<CacheKey> membuat nama setiap bagian data yang disimpan dalam cache. Kunci sering ditetapkan menggunakan nilai dari header entity atau parameter kueri. Dalam kasus tersebut, Anda akan meminta atribut ref elemen menentukan variabel yang berisi nilai kunci.

Saat runtime, nilai <KeyFragment> ditambahkan dengan nilai elemen <Scope> atau nilai <Prefix>. Misalnya, hal berikut menghasilkan kunci cache UserToken__apiAccessToken__<value_of_client_id>:

<CacheKey>
    <Prefix>UserToken</Prefix>
    <KeyFragment>apiAccessToken</KeyFragment>
    <KeyFragment ref="request.queryparam.client_id" />
</CacheKey>

Anda menggunakan elemen <CacheKey> bersama dengan <Prefix> dan <Scope>. Untuk informasi selengkapnya, lihat Menggunakan kunci cache.

Elemen <CacheLookupTimeoutInSeconds>

Menentukan jumlah detik setelah pencarian cache yang tidak berhasil akan dianggap sebagai cache-miss. Jika hal ini terjadi, alur akan dilanjutkan di sepanjang jalur cache-miss.

<CacheLookupTimeoutInSeconds>30</CacheLookupTimeoutInSeconds>

Default:

30

Kehadiran:

Opsional

Jenis:

Bilangan bulat

Elemen <CacheResource>

Menentukan cache tempat pesan akan disimpan. Hapus elemen ini untuk menggunakan cache bersama yang disertakan. Anda harus menentukan CacheResource menurut namanya jika ingin dapat menghapus entri yang terdapat dalam cache secara administratif. Untuk mengetahui informasi selengkapnya, lihat Caches API.

<CacheResource>cache_to_use</CacheResource>

Default:

T/A

Kehadiran:

Opsional

Jenis:

String

Elemen <CacheKey>/<KeyFragment>

Menentukan nilai yang harus disertakan dalam kunci cache, yang membuat namespace untuk mencocokkan permintaan dengan respons yang di-cache.

<KeyFragment ref="variable_name"/>
<KeyFragment>literal_string</KeyFragment>

Default:

T/A

Kehadiran:

Opsional

Jenis:

T/A

Ini dapat berupa kunci (nama statis yang Anda berikan) atau nilai (entri dinamis yang ditetapkan dengan mereferensikan variabel). Semua fragmen yang ditentukan digabungkan (ditambah awalan) akan digabungkan untuk membuat kunci cache.

<KeyFragment>apiAccessToken</KeyFragment>
<KeyFragment ref="request.queryparam.client_id" />

Anda menggunakan elemen <KeyFragment> bersama dengan <Prefix> dan <Scope>. Untuk informasi selengkapnya, lihat Menggunakan kunci cache.

Atribut

Atribut Jenis Default Wajib Deskripsi
ref string Tidak

Variabel tempat nilai akan diambil. Tidak boleh digunakan jika elemen ini berisi nilai literal.

Elemen <CacheKey>/<Prefix>

Menentukan nilai yang akan digunakan sebagai awalan kunci cache.

<Prefix>prefix_string</Prefix>

Default:

T/A

Kehadiran:

Opsional

Jenis:

String

Gunakan nilai ini, bukan <Scope>, jika Anda ingin menentukan nilai sendiri, bukan nilai yang dihitung <Scope>. Jika ditentukan, <Prefix> akan menambahkan nilai kunci cache di awal untuk entri yang ditulis ke cache. Nilai elemen <Prefix> akan menggantikan nilai elemen <Scope>.

Anda menggunakan elemen <Prefix> bersama dengan <CacheKey> dan <Scope>. Untuk informasi selengkapnya, lihat Menggunakan kunci cache.

Elemen <ExcludeErrorResponse>

Kebijakan ini dapat meng-cache respons HTTP dengan kode status apa pun. Artinya, respons berhasil dan error dapat di-cache, termasuk kode status 2xx dan 3xx.

Tetapkan elemen ini ke true (default) untuk mengecualikan respons error. Tetapkan ke false jika Anda tidak ingin mengecualikan respons target cache dengan kode status error HTTP.

Untuk diskusi tentang pola Cache Respons tempat elemen ini berguna, lihat Pengantar antipola.

<ExcludeErrorResponse>true</ExcludeErrorResponse>

Default:

benar

Kehadiran:

Opsional

Jenis:

Boolean

Elemen <ExpirySettings>

Menentukan kapan masa berlaku entri cache berakhir. Jika ada, <TimeoutInSeconds> akan menggantikan <TimeOfDay> dan <ExpiryDate>.

<ExpirySettings>
  <TimeOfDay ref="time_variable">expiration_time</TimeOfDay>
  <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds>
  <ExpiryDate ref="date_variable">expiration_date</ExpiryDate>
</ExpirySettings>

Default:

T/A

Kehadiran:

Wajib

Jenis:

T/A

Elemen <ExpirySettings>/<ExpiryDate>

Menentukan tanggal habis masa berlaku entri cache. Gunakan formulir mm-dd-yyyy. Jika ada, elemen saudara elemen ini, <TimeoutInSeconds>, akan mengganti <ExpiryDate>.

<ExpirySettings>
    <ExpiryDate ref="{date_variable}">expiration_date</ExpiryDate>
</ExpirySettings>

Default:

T/A

Kehadiran:

Opsional

Jenis:

String

Atribut

<ExpiryDate ref="" />
Atribut Deskripsi Default Kehadiran Jenis
ref

Variabel tempat nilai akan diambil. Tidak boleh digunakan jika elemen ini berisi nilai literal.

T/A Opsional String

Elemen <ExpirySettings>/<TimeOfDay>

Waktu saat masa berlaku entri cache berakhir. Gunakan formulir hh:mm:ss . Jika ada, elemen saudara elemen ini, <TimeoutInSeconds>, akan mengganti <TimeOfDay>.

Masukkan waktu dalam format HH:mm:ss, dengan HH mewakili jam pada jam 24 jam. Misalnya, 14.30.00 untuk pukul 14.30.

Untuk waktu, lokalitas dan zona waktu default akan bervariasi bergantung pada tempat kode berjalan (yang tidak dapat diketahui saat Anda mengonfigurasi kebijakan).

<ExpirySettings>
    <TimeOfDay ref="time_variable">expiration_time</TimeOfDay>
</ExpirySettings>

Default:

T/A

Kehadiran:

Opsional

Jenis:

String

Atribut

Atribut Deskripsi Default Kehadiran Jenis
ref Variabel dengan nilai waktu habis masa berlaku. T/A Opsional String

Elemen <ExpirySettings>/<TimeoutInSec>

Jumlah detik setelah masa berlaku entri cache berakhir.

Elemen <ExpirySettings>/<TimeoutInSeconds>

Jumlah detik setelah masa berlaku entri cache berakhir. Jika ada, elemen ini akan mengganti elemen lainnya, <TimeOfDay> dan <ExpiryDate>.

<ExpirySettings>
    <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds>
</ExpirySettings>

Default:

T/A

Kehadiran:

Opsional

Jenis:

String

Atribut

Atribut Deskripsi Default Kehadiran Jenis
ref Variabel dengan nilai waktu tunggu.
T/A
Opsional String

Elemen <Scope>

Enumerasi yang digunakan untuk membuat awalan untuk kunci cache saat elemen <Prefix> tidak disediakan dalam elemen <CacheKey>.

<Scope>scope_enumeration</Scope>

Default:

"Eksklusif"

Kehadiran:

Opsional

Jenis:

String

Setelan <Scope> menentukan kunci cache yang ditambahkan di awal sesuai dengan nilai <Scope>. Misalnya, kunci cache akan menggunakan bentuk berikut saat cakupan ditetapkan ke Exclusive: orgName__envName__apiProxyName__deployedRevisionNumber__proxy|TargetName__ [serializedCacheKey ].

Jika elemen <Prefix> ada di <CacheKey>, elemen tersebut akan menggantikan nilai elemen <Scope>. Nilai yang valid mencakup enumerasi di bawah.

Anda menggunakan elemen <Scope> bersama dengan <CacheKey> dan <Prefix>. Untuk informasi selengkapnya, lihat Menggunakan kunci cache.

Nilai yang dapat diterima

Nilai Cakupan Deskripsi
Global

Kunci cache dibagikan ke semua proxy API yang di-deploy di lingkungan. Kunci cache ditambahkan di awal dalam bentuk orgName __ envName __.

Jika Anda menentukan entri <CacheKey> dengan <KeyFragment> apiAccessToken dan cakupan <Global>, setiap entri akan disimpan sebagai orgName__envName__apiAccessToken, diikuti dengan nilai token akses yang diserialisasi. Untuk proxy API yang di-deploy di lingkungan yang disebut 'test' di organisasi yang disebut 'apifactory', token akses akan disimpan di bawah kunci cache berikut: apifactory__test__apiAccessToken.

Application

Nama proxy API digunakan sebagai awalan.

Kunci cache ditambahkan di awal dalam bentuk orgName__envName__apiProxyName.

Proxy

Konfigurasi ProxyEndpoint digunakan sebagai awalan.

Kunci cache ditambahkan di awal dalam bentuk orgName__envName__apiProxyName__deployedRevisionNumber__proxyEndpointName .

Target

Konfigurasi TargetEndpoint digunakan sebagai awalan.

Kunci cache ditambahkan di awal dalam bentuk orgName__envName__apiProxyName__deployedRevisionNumber__targetEndpointName .

Exclusive

Default. Ini adalah yang paling spesifik, sehingga menimbulkan risiko tabrakan namespace minimal dalam cache tertentu.

Awalan adalah salah satu dari dua bentuk berikut:

  • Jika kebijakan dilampirkan ke alur ProxyEndpoint, awalan memiliki bentuk ApiProxyName_ProxyEndpointName.
  • Jika kebijakan dilampirkan di TargetEndpoint, awalan memiliki bentuk ApiProxyName_TargetName.

Kunci cache ditambahkan di awal dalam bentuk orgName__envName__apiProxyName__deployedRevisionNumber__proxyNameITargetName

Misalnya, string lengkap mungkin terlihat seperti ini:

apifactory__test__weatherapi__16__default__apiAccessToken
.

Elemen <SkipCacheLookup>

Menentukan ekspresi yang, jika dievaluasi ke benar saat runtime, menentukan bahwa pencarian cache harus dilewati dan cache harus dimuat ulang. Lihat juga video Menggunakan kebijakan ResponseCache tentang penggunaan SkipCacheLookup.

<SkipCacheLookup>variable_condition_expression</SkipCacheLookup>

Default:

T/A

Kehadiran:

Opsional

Jenis:

String

Dari contoh berikut, jika variabel bypass-cache ditetapkan ke true di header masuk, pencarian cache akan dilewati dan cache akan dimuat ulang.

<SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup>

Elemen <SkipCachePopulation>

Menentukan ekspresi yang, jika dievaluasi ke true (benar) saat runtime, menentukan bahwa penulisan ke cache harus dilewati. Lihat juga video ini tentang penggunaan SkipCachePopulation.

<SkipCachePopulation>variable_condition_expression</SkipCachePopulation>

Default:

T/A

Kehadiran:

Opsional

Jenis:

String

Misalnya, kode berikut akan melewati penulisan cache jika kode status respons adalah 400 atau lebih tinggi:

<SkipCachePopulation>response.status.code >= 400</SkipCachePopulation>

Elemen <UseAcceptHeader>

Tetapkan ke true agar kunci cache entri cache respons ditambahkan dengan nilai dari header Accept respons.

Apigee menggunakan header permintaan Accept, Accept-Encoding, Accept-Language, dan Accept-Charset saat menghitung kunci cache. Pendekatan ini mencegah klien mendapatkan jenis media yang tidak mereka minta.

Misalnya, pertimbangkan jika dua permintaan masuk dari URL yang sama, dengan permintaan pertama menerima gzip dan permintaan kedua tidak. Permintaan pertama akan di-cache, dan entri yang di-cache akan (mungkin) berupa respons yang di-gzip. Permintaan kedua akan membaca nilai yang di-cache, lalu dapat menampilkan entri yang di-gzip ke klien yang tidak dapat membaca gzip.

Lihat Mengonfigurasi kunci cache untuk mengetahui informasi selengkapnya.

<UseAcceptHeader>false</UseAcceptHeader>

Default:

false

Kehadiran:

Opsional

Jenis:

Boolean

Elemen <UseResponseCacheHeaders>

Tetapkan ke true agar header respons HTTP dipertimbangkan saat menetapkan "time to live" (TTL) respons di cache. Jika hal ini benar, Apigee akan mempertimbangkan nilai header respons berikut, yang membandingkan nilai dengan nilai yang ditetapkan oleh <ExpirySettings> saat menetapkan waktu habis masa berlaku:

  • Cache-Control s-maxage
  • Cache-Control max-age
  • Expires

Lihat Menetapkan masa berlaku entri cache untuk detail selengkapnya.

<UseResponseCacheHeaders>false</UseResponseCacheHeaders>

Default:

false

Kehadiran:

Opsional

Jenis:

Boolean

Catatan penggunaan

Ukuran maksimum untuk setiap objek yang di-cache adalah 256 KB. (Untuk informasi mendetail tentang cara Apigee memproses cache, lihat Internal cache.)

Melalui konfigurasi dalam kebijakan ResponseCache, Anda dapat meminta Apigee menyertakan header respons HTTP dalam menetapkan masa berlaku entri cache dan kunci cache. Bagian ini menjelaskan bahwa Anda dapat menggunakan kebijakan dengan header untuk mengelola masa berlaku cache dan kunci cache.

Untuk mengetahui informasi selengkapnya tentang cara Apigee menangani header respons dengan kebijakan ResponseCache, lihat Dukungan untuk header respons HTTP.

Menetapkan masa berlaku entri cache

Seperti halnya kebijakan PopulateCache, Anda dapat menetapkan masa berlaku entri cache respons (time to live) menggunakan elemen <ExpirySettings>. Dalam kebijakan ResponseCache, Anda juga dapat meminta Apigee mempertimbangkan header respons jika ada.

Untuk menggunakan header respons, Anda menetapkan nilai elemen <UseResponseCacheHeaders> ke benar. Setelan tersebut menyebabkan Apigee mempertimbangkan header respons, membandingkannya dengan nilai yang ditetapkan oleh <ExpirySettings>, lalu menggunakan nilai terendah di antara keduanya. Saat mempertimbangkan header respons, Apigee memilih nilai yang tersedia seperti yang dijelaskan dalam hal berikut:

Diagram yang menunjukkan hal yang terjadi saat Anda menetapkan UseResponseCacheHeaders ke benar (true).

Misalnya, bayangkan respons di-cache dengan nilai berikut:

  • Tidak ada nilai Cache-Control s-maxage
  • Nilai Cache-Control max-age sebesar 300
  • Tanggal Expires dalam tiga hari
  • Nilai <ExpirySettings> TimeoutInSeconds sebesar 600.

Dalam hal ini, nilai Cache-Control max-age akan digunakan untuk TTL karena lebih rendah dari nilai <ExpirySettings> dan karena tidak ada nilai Cache-Control s-maxage (yang lebih diutamakan daripada max-age).

Mengonfigurasi kunci cache

Seperti halnya kebijakan cache tujuan umum seperti kebijakan PopulateCache, dengan ResponseCache, Anda menggunakan elemen <CacheKey> dan <Scope> untuk mengonfigurasi pembuatan kunci cache untuk entri cache. Dengan ResponseCache, Anda juga dapat membuat kunci cache lebih bermakna dengan menambahkan header Accept respons ke nilai kunci.

Untuk informasi umum tentang cara mengonfigurasi kunci cache, lihat Menggunakan kunci cache. Untuk informasi tentang penggunaan header Accept, lihat <UseAcceptHeader>.

Tentang enkripsi cache

Apigee dan Apigee hybrid (versi 1.4 dan yang lebih baru): Data cache dan KVM selalu dienkripsi.

Variabel alur

Variabel Flow standar berikut diisi saat kebijakan ResponseCache dijalankan. Untuk informasi selengkapnya tentang variabel Flow, lihat Referensi variabel Flow.

Variabel Jenis Izin Deskripsi
responsecache.{policy_name}.cachename String Hanya Baca Menampilkan cache yang digunakan dalam kebijakan
responsecache.{policy_name}.cachekey String Hanya Baca Menampilkan kunci yang digunakan
responsecache.{policy_name}.cachehit Boolean Hanya Baca Benar jika eksekusi kebijakan berhasil
responsecache.{policy_name}.invalidentry Boolean Hanya Baca True jika entri cache tidak valid

Kode error

Bagian ini menjelaskan pesan error dan variabel alur yang ditetapkan saat kebijakan ini memicu error. Informasi ini penting untuk diketahui jika Anda mengembangkan aturan error untuk proxy. Untuk mempelajari lebih lanjut, lihat Yang perlu Anda ketahui tentang error kebijakan dan Menangani error.

Awalan kode error

T/A

Error runtime

Kebijakan ini tidak menampilkan error runtime.

Error saat deployment

Error ini dapat terjadi saat Anda men-deploy proxy yang berisi kebijakan ini.

Nama error Penyebab Perbaiki
InvalidTimeout Jika elemen <CacheLookupTimeoutInSeconds> kebijakan ResponseCache ditetapkan ke bilangan negatif, deployment proxy API akan gagal.
InvalidCacheResourceReference Error ini terjadi jika elemen <CacheResource> dalam kebijakan ResponseCache ditetapkan ke nama yang tidak ada di lingkungan tempat proxy API di-deploy.
ResponseCacheStepAttachmentNotAllowedReq Error ini terjadi jika kebijakan ResponseCache yang sama dilampirkan ke beberapa jalur permintaan dalam alur proxy API.
ResponseCacheStepAttachmentNotAllowedResp Error ini terjadi jika kebijakan ResponseCache yang sama dilampirkan ke beberapa jalur respons dalam alur proxy API.
InvalidMessagePatternForErrorCode Error ini terjadi jika elemen <SkipCacheLookup> atau <SkipCachePopulation> dalam kebijakan ResponseCache berisi kondisi yang tidak valid.
CacheNotFound Error ini terjadi jika cache tertentu yang disebutkan dalam pesan error belum dibuat di komponen Message Processor tertentu.

Variabel error

T/A

Contoh respons error

T/A

Skema

Setiap jenis kebijakan ditentukan oleh skema XML (.xsd). Sebagai referensi, skema kebijakan tersedia di GitHub.