Anda sedang melihat dokumentasi Apigee Edge.
Buka
dokumentasi Apigee X. info
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 disimpan dalam cache, bukan meneruskan permintaan tersebut ke server backend. Kebijakan ResponseCache dapat meningkatkan performa API Anda melalui pengurangan latensi dan traffic jaringan.
Anda mungkin akan mendapati ResponseCache paling berguna jika data backend yang digunakan oleh API Anda hanya diperbarui secara berkala. Misalnya, bayangkan Anda memiliki API yang mengekspos 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 cache jangka pendek tujuan umum, pertimbangkan untuk menggunakan kebijakan Isi Cache. Kebijakan tersebut digunakan bersamaan dengan kebijakan Cache Pencarian (untuk membaca entri cache) dan kebijakan Cache Tidak Valid (untuk membatalkan validasi entri).
Tonton video ini untuk mengetahui pengantar kebijakan Cache Respons.
Contoh
Cache 10 menit
Contoh ini menunjukkan cara menyimpan respons yang di-cache selama 10 menit.
Bayangkan 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 Edge memeriksa nilai parameter kueri w
setiap kali permintaan diterima. Jika terdapat respons yang valid (yaitu, belum habis masa berlakunya) di 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 ditampilkan ke aplikasi tanpa permintaan yang diteruskan ke layanan backend.
http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778
Lewati pencarian cache
Contoh berikut menunjukkan cara membuat pencarian cache dilewati dan cache diperbarui. Lihat juga video ini tentang penggunaan SkipCacheLookup.
Kondisi SkipCacheLookup opsional (jika dikonfigurasi) dievaluasi di jalur permintaan. Jika kondisi bernilai true (benar), pencarian cache akan dilewati dan cache di-refresh.
Penggunaan umum refresh cache bersyarat adalah kondisi yang menentukan header HTTP tertentu yang menyebabkan kondisi dievaluasi ke benar (true). Aplikasi klien dengan skrip dapat dikonfigurasi untuk mengirimkan permintaan secara berkala dengan header HTTP yang sesuai, secara eksplisit menyebabkan cache respons di-refresh.
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 pada proxy tersebut. Perhatikan bahwa kondisi pengabaian cache ditetapkan ke benar (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 flow.
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 | Ketersediaan |
---|---|---|---|
name |
Nama internal kebijakan. Nilai atribut Atau, gunakan elemen |
T/A | Wajib |
continueOnError |
Setel ke Setel ke |
false | Opsional |
enabled |
Setel ke Setel ke |
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 |
---|---|
Ketersediaan | Opsional |
Jenis | String |
Elemen <CacheKey>
Mengonfigurasi pointer unik ke bagian data yang disimpan dalam cache.
Ukuran kunci cache dibatasi hingga 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 kali ditetapkan menggunakan nilai dari header entity atau parameter kueri. Pada kasus tersebut, Anda akan menyetel atribut ref elemen untuk menentukan variabel yang berisi nilai kunci.
Saat runtime, nilai <KeyFragment>
diawali dengan nilai elemen
<Scope>
atau nilai <Prefix>
. Misalnya, kode 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 mengetahui informasi selengkapnya, lihat Bekerja dengan kunci cache.
Elemen <CacheLookupTimeoutInSeconds>
Menentukan jumlah detik setelah pencarian cache yang gagal akan dianggap cache tidak ditemukan. Jika ini terjadi, alur dilanjutkan di sepanjang jalur cache yang tidak ditemukan.
<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 berdasarkan nama jika ingin dapat menghapus entri yang ada dalam cache secara administratif. Untuk mengetahui informasi selengkapnya, lihat Cache.
<CacheResource>cache_to_use</CacheResource>
Default: |
T/A |
Kehadiran: |
Opsional |
Jenis: |
String |
Untuk informasi selengkapnya tentang cara mengonfigurasi cache, lihat Membuat dan mengedit cache lingkungan.
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) digabungkan untuk membuat kunci cache.
<KeyFragment>apiAccessToken</KeyFragment> <KeyFragment ref="request.queryparam.client_id" />
Anda menggunakan elemen <KeyFragment>
bersama dengan
<Prefix>
dan <Scope>
. Untuk mengetahui informasi selengkapnya, lihat Bekerja dengan kunci cache.
Atribut
Atribut | Jenis | Default | Wajib | Deskripsi |
---|---|---|---|---|
referensi | string | Tidak |
Variabel yang digunakan untuk mendapatkan nilai. 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 Anda sendiri,
bukan nilai yang dienumerasi <Scope>
. Jika ditentukan,
<Prefix>
akan menambahkan nilai kunci cache untuk entri yang ditulis ke cache. Nilai elemen
<Prefix>
menggantikan nilai elemen
<Scope>
.
Anda menggunakan elemen <Prefix>
bersama dengan
<CacheKey>
dan <Scope>
. Untuk mengetahui informasi selengkapnya, lihat Bekerja dengan kunci cache.
Elemen <ExcludeErrorResponse>
Saat ini, secara default, kebijakan ini menyimpan respons HTTP dalam cache dengan kode Status apa pun yang memungkinkan. Artinya, respons berhasil dan error akan di-cache. Misalnya, respons dengan kode status 2xx dan 3xx akan disimpan di cache secara default.
Setel elemen ini ke true
jika Anda tidak ingin menyimpan respons target
dengan kode status error HTTP dalam cache; hanya respons dengan kode status dari 200 hingga 205 yang akan
disimpan dalam cache jika elemen ini bernilai benar (true). Ini adalah satu-satunya kode status HTTP yang dihitung Edge sebagai
kode "berhasil", dan Anda tidak dapat mengubah pengaitan ini.
Untuk pembahasan pola Cache Respons yang menggunakan elemen ini, lihat postingan komunitas ini.
Catatan: Dalam rilis mendatang (akan ditentukan), setelan default elemen ini akan berubah ke benar (true). Lihat Catatan Rilis Apigee untuk mengetahui detailnya.
<ExcludeErrorResponse>true</ExcludeErrorResponse>
Default: |
false |
Kehadiran: |
Opsional |
Jenis: |
Boolean |
Elemen <ExpirySettings>
Menentukan kapan entri cache akan berakhir masa berlakunya. 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 berakhirnya entri cache. Gunakan formulir mm-dd-yyyy
.
Jika ada, pasangan elemen ini, <TimeoutInSeconds>
, akan menggantikan
<ExpiryDate>
.
<ExpirySettings> <ExpiryDate ref="{date_variable}">expiration_date</ExpiryDate> </ExpirySettings>
Default: |
T/A |
Kehadiran: |
Opsional |
Jenis: |
String |
Atribut
<ExpiryDate ref="" />
Atribut | Deskripsi | Default | Ketersediaan | Jenis |
---|---|---|---|---|
referensi |
Variabel yang digunakan untuk mendapatkan nilai. Tidak boleh digunakan jika elemen ini berisi nilai literal. |
T/A | Opsional | String |
Elemen <ExpirySettings>/<TimeOfDay>
Waktu saat entri cache akan berakhir masa berlakunya. Gunakan formulir hh:mm:ss
.
Jika ada, pasangan elemen ini, <TimeoutInSeconds>
, akan menggantikan
<TimeOfDay>
.
Masukkan waktu dalam format HH:mm:ss, dengan HH mewakili jam dalam format 24 jam. Misalnya, pukul 14.30.00 untuk pukul 2.30 siang.
Untuk waktu, lokalitas dan zona waktu default akan bervariasi bergantung pada tempat kode dijalankan (yang tidak dapat diketahui saat Anda mengonfigurasi kebijakan). Untuk informasi tentang cara mengonfigurasi lokalitas Anda, lihat Membuat dan mengedit cache lingkungan.
<ExpirySettings> <TimeOfDay ref="time_variable">expiration_time</TimeOfDay> </ExpirySettings>
Default: |
T/A |
Kehadiran: |
Opsional |
Jenis: |
String |
Atribut
Atribut | Deskripsi | Default | Ketersediaan | Jenis |
---|---|---|---|---|
referensi | Variabel dengan nilai waktu habis masa berlaku. | T/A | Opsional | String |
Elemen <ExpirySettings>/<TimeoutInSec>
Jumlah detik hingga masa berlaku entri cache akan berakhir.
Elemen <ExpirySettings>/<TimeoutInSeconds>
Jumlah detik hingga masa berlaku entri cache akan berakhir. Jika ada, elemen ini akan menggantikan elemen seinduknya, <TimeOfDay>
dan <ExpiryDate>
.
<ExpirySettings> <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds> </ExpirySettings>
Catatan: Berikan nilai waktu tunggu default untuk digunakan jika ref tidak menerima nilai dari duration_variable
.
Default: |
T/A |
Kehadiran: |
Opsional |
Jenis: |
String |
Atribut
Atribut | Deskripsi | Default | Ketersediaan | Jenis |
---|---|---|---|---|
referensi | Variabel dengan nilai waktu tunggu. |
T/A
|
Opsional | String |
Elemen <Scope>
Enumerasi yang digunakan untuk membuat awalan untuk kunci cache jika elemen <Prefix>
tidak disediakan dalam elemen <CacheKey>
.
<Scope>scope_enumeration</Scope>
Default: |
"Eksklusif" |
Kehadiran: |
Opsional |
Jenis: |
String |
Setelan <Scope>
menentukan kunci cache yang ditambahkan sesuai dengan nilai <Scope>
. Misalnya, kunci cache akan menggunakan format berikut jika
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 ini.
Anda menggunakan elemen <Scope>
bersama dengan
<CacheKey>
dan <Prefix>
. Untuk mengetahui informasi selengkapnya, lihat Bekerja dengan 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 dalam bentuk orgName __ envName __. Jika Anda menentukan entri |
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 depan dalam bentuk orgName__envName__apiProxyName__deployedRevisionNumber__proxyEndpointName . |
Target |
Konfigurasi TargetEndpoint digunakan sebagai awalan. Kunci cache ditambahkan di awal formulir orgName__envName__apiProxyName__deployedRevisionNumber__targetEndpointName . |
Exclusive |
Default. Ini adalah hal yang paling spesifik, sehingga meminimalkan risiko benturan namespace dalam cache tertentu. Awalan adalah salah satu dari dua bentuk:
Kunci cache ditambahkan di awal formulir 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 true (benar) pada runtime, menentukan bahwa pencarian cache harus dilewati dan cache harus di-refresh. Lihat juga video ini tentang penggunaan SkipCacheLookup.
<SkipCacheLookup>variable_condition_expression</SkipCacheLookup>
Default: |
T/A |
Kehadiran: |
Opsional |
Jenis: |
String |
Dari contoh berikut, jika variabel pengabaian-cache ditetapkan ke true di header masuk, pencarian cache akan dilewati dan cache akan di-refresh.
<SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup>
Elemen <SkipCachePopulation>
Menentukan ekspresi yang, jika dievaluasi ke true (benar) saat runtime, menetapkan 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, perintah berikut akan melewati penulisan cache jika kode status respons adalah 400 atau lebih tinggi:
<SkipCachePopulation>response.status.code >= 400</SkipCachePopulation>
Elemen <UseAcceptHeader>
Setel ke true
agar kunci cache entri cache respons ditambahkan dengan nilai dari
header response Accept.
Edge 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 berasal dari URL yang sama, dengan permintaan pertama menerima gzip dan yang kedua tidak. Permintaan pertama akan di-cache, dan entri yang di-cache akan (mungkin) menjadi respons dalam bentuk gzip. Permintaan kedua akan membaca nilai yang disimpan dalam cache, lalu dapat menampilkan entri yang di-gzip ke klien yang tidak mampu 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 menyetel "time to live" (TTL) respons dalam cache. Jika ini benar, Edge akan mempertimbangkan nilai
header respons berikut, yang membandingkan nilai dengan nilai yang ditetapkan oleh
<ExpirySettings>
saat menyetel waktu aktif:
Cache-Control s-maxage
Cache-Control max-age
Expires
Lihat Menetapkan masa berlaku entri cache untuk mengetahui 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 Edge memproses cache, lihat Internal cache.)
Melalui konfigurasi dalam kebijakan ResponseCache, Anda dapat membuat Edge menyertakan header respons HTTP dalam menyetel 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 informasi selengkapnya tentang cara Edge menangani header respons dengan kebijakan ResponseCache, lihat Dukungan untuk header respons HTTP.
Menyetel masa berlaku entri cache
Seperti pada Mengisi
kebijakan Cache, Anda dapat menetapkan masa berlaku entri cache respons (waktunya aktif) menggunakan elemen
<ExpirySettings>
. Dalam kebijakan ResponseCache, Anda juga dapat meminta Edge untuk mempertimbangkan header respons jika ada.
Untuk menggunakan header respons, tetapkan nilai elemen <UseResponseCacheHeaders>
ke
true. Setelan tersebut menyebabkan Edge mempertimbangkan header respons, membandingkannya dengan nilai yang ditetapkan
oleh <ExpirySettings>
, lalu menggunakan nilai terendah di antara keduanya. Saat
mempertimbangkan header respons, Edge memilih nilai yang tersedia seperti yang dijelaskan dalam
berikut:
Misalnya, bayangkan respons di-cache dengan nilai berikut:
- Tidak ada nilai
Cache-Control s-maxage
- Nilai
Cache-Control max-age
300 - Tanggal
Expires
dalam tiga hari - Nilai
<ExpirySettings>
TimeoutInSeconds
600.
Dalam hal ini, nilai Cache-Control
max-age
akan digunakan untuk TTL karena lebih rendah dari nilai <ExpirySettings>
dan tidak ada nilai Cache-Control s-maxage
(yang lebih diutamakan daripada max-age
).
Mengonfigurasi kunci cache
Seperti kebijakan cache tujuan umum seperti Kebijakan Isi Cache, dengan
ResponseCache, Anda menggunakan elemen <CacheKey>
dan <Scope>
untuk
mengonfigurasi pembuatan kunci cache bagi entri cache. Dengan ResponseCache, Anda juga dapat membuat kunci cache lebih bermakna dengan menambahkan header response Accept ke nilai kunci.
Untuk mengetahui informasi umum tentang cara mengonfigurasi kunci cache, lihat Bekerja dengan kunci cache. Untuk
informasi cara menggunakan header Accept, lihat <UseAcceptHeader>
.
Tentang enkripsi cache
Edge for Public Cloud: Cache hanya dienkripsi di organisasi yang mendukung PCI dan HIPAA. Enkripsi untuk organisasi tersebut dikonfigurasi selama penyediaan organisasi.
Variabel alur
Variabel Alur standar berikut diisi saat kebijakan ResponseCache dijalankan. Untuk informasi selengkapnya tentang variabel Alur, lihat Referensi variabel.
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 | True 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 apakah Anda sedang mengembangkan aturan fault untuk proxy. Untuk mempelajari lebih lanjut, lihat Yang perlu Anda ketahui tentang error kebijakan dan Menangani kesalahan.
Awalan kode error
T/A
Error runtime
Kebijakan ini tidak menampilkan error runtime apa pun.
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 angka negatif, deployment proxy API akan gagal. |
build |
InvalidCacheResourceReference |
Error ini terjadi jika elemen <CacheResource> dalam kebijakan ResponseCache ditetapkan ke nama yang tidak ada di lingkungan tempat proxy API di-deploy. |
build |
ResponseCacheStepAttachmentNotAllowedReq |
Error ini terjadi jika kebijakan ResponseCache yang sama dilampirkan ke beberapa jalur permintaan dalam setiap alur proxy API. | build |
ResponseCacheStepAttachmentNotAllowedResp |
Error ini terjadi jika kebijakan ResponseCache yang sama dilampirkan ke beberapa jalur respons dalam setiap alur proxy API. | build |
InvalidMessagePatternForErrorCode |
Error ini terjadi jika elemen <SkipCacheLookup> atau <SkipCachePopulation> dalam kebijakan ResponseCache berisi kondisi yang tidak valid. |
build |
CacheNotFound |
Error ini terjadi jika cache tertentu yang disebutkan dalam pesan error tidak dibuat pada komponen Pemroses Pesan tertentu. | build |
Variabel kesalahan
T/A
Contoh respons error
T/A
Skema
Setiap jenis kebijakan ditentukan oleh skema XML (.xsd
). Sebagai referensi, skema kebijakan tersedia di GitHub.