Kebijakan kuota

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

Lihat Dokumentasi Apigee Edge.

Ringkasan

Kuota adalah alokasi pesan permintaan yang dapat ditangani oleh proxy API selama jangka waktu tertentu, seperti menit, jam, hari, minggu, atau bulan. Kebijakan Kuota mempertahankan penghitung yang menghitung jumlah permintaan yang diterima oleh proxy API. Kemampuan ini memungkinkan penyedia API menerapkan batasan jumlah panggilan API yang dilakukan oleh aplikasi selama interval waktu tertentu. Dengan menggunakan kebijakan Kuota, Anda dapat, misalnya, batasi aplikasi hingga 1 permintaan per menit, atau hingga 10.000 permintaan per bulan.

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

Catatan: Saat proxy API mencapai batas kuota, panggilan API berikutnya ditolak; Apigee menampilkan pesan error untuk setiap permintaan yang melebihi kuota. Tujuan Kebijakan kuota memberikan kemampuan untuk mereset kuota dengan cepat, setelah aplikasi melampaui batas batas performa.

Misalnya, jika Kuota ditetapkan sebagai 10.000 pesan per bulan, pembatasan kapasitas dimulai setelah pesan yang ke-10.000. Tidak masalah apakah 10.000 pesan dihitung pada hari atau hari terakhir menstruasi tersebut; tidak ada permintaan tambahan yang diizinkan hingga penghitung Kuota otomatis direset pada akhir interval waktu yang ditentukan, atau hingga Kuota secara eksplisit direset menggunakan kebijakan ResetQuota.

Variasi pada kebijakan Kuota, kebijakan SpikeArrest, mencegah lonjakan traffic (atau burst) yang dapat disebabkan oleh peningkatan penggunaan yang mendadak, klien yang memiliki bug, atau serangan berbahaya.

Gunakan kebijakan Kuota untuk mengonfigurasi jumlah pesan permintaan yang diizinkan oleh proxy API periode waktu, seperti menit, jam, hari, minggu, atau bulan. Anda dapat menetapkan kuota untuk sama untuk semua aplikasi yang mengakses proxy API, atau Anda dapat menyetel kuota berdasarkan:

• Produk yang berisi proxy API
• Aplikasi yang meminta API
• Developer aplikasi
• Banyak kriteria lain

Jangan gunakan kebijakan Kuota untuk melindungi dari lonjakan traffic secara keseluruhan. Untuk melakukannya, gunakan Kebijakan SpikeArrest.

Tips: Perlu bantuan dalam menentukan kebijakan pembatasan kapasitas yang akan digunakan? Lihat Membandingkan Kebijakan Kuota dan SpikeArrest.

Video

Catatan: Video berikut menampilkan Proxy Editor klasik di bagian UI Apigee. Apigee memperkenalkan Proxy versi baru Editor, yang memiliki desain berbeda dari versi klasik yang ditampilkan dalam video.

Video berikut memperkenalkan pengelolaan kuota dengan kebijakan Kuota:

Pengantar

Kuota Dinamis

Didistribusikan & Sinkron

Bobot Pesan

Kalender

Jendela Berkelanjutan

Flexi

Kuota Bersyarat

Variabel Alur

Penanganan Error

Jenis kebijakan kuota

Kebijakan Kuota mendukung beberapa cara berbeda untuk memulai dan mereset penghitung kuota. Anda dapat menentukan elemen yang akan digunakan dengan atribut type di elemen <Quota>, seperti yang ditunjukkan contoh berikut:

<Quota name="QuotaPolicy" type="calendar">
  ...
</Quota>

Nilai type yang valid mencakup:

• calendar: Mengonfigurasi kuota berdasarkan waktu mulai eksplisit. Kuota untuk setiap aplikasi diperbarui berdasarkan <StartTime>, <Interval>, dan <TimeUnit> nilai yang Anda tetapkan.
• rollingwindow: Mengonfigurasi kuota yang menggunakan "periode bergulir" dapat menentukan penggunaan kuota. Dengan rollingwindow, Anda menentukan ukuran jendela dengan Elemen <Interval> dan <TimeUnit>; misalnya, 1 hari. Ketika permintaan masuk, Apigee melihat waktu persis permintaan tersebut (misalnya 17.01), menghitung jumlah permintaan yang masuk antara saat itu dan pukul 17.01 hari sebelumnya (1 hari), dan menentukan apakah kuota telah terlampaui atau belum periode tersebut.
• flexi: Mengonfigurasi kuota yang menyebabkan penghitung dimulai saat pesan permintaan pertama diterima dari aplikasi, dan diatur ulang berdasarkan nilai <Interval> dan <TimeUnit>.

Tabel berikut menjelaskan reset kuota untuk setiap jenis:

Unit Waktu	Jenis
	default (atau null)	calendar	flexi
menit	Awal menit berikutnya	Satu menit setelah <StartTime>	Satu menit setelah permintaan pertama
jam	Atas jam berikutnya	Satu jam setelah <StartTime>	Satu jam setelah permintaan pertama
hari	GMT tengah malam hari ini	24 jam setelah <StartTime>	24 jam setelah permintaan pertama
minggu	Tengah malam GMT pada akhir minggu	Satu minggu setelah <StartTime>	Satu minggu setelah permintaan pertama
bulan	Tengah malam GMT dari hari terakhir bulan ini	Satu bulan (28 hari) setelah <StartTime>	Satu bulan (28 hari) setelah permintaan pertama

Catatan: Kebijakan Kuota juga mendukung second sebagai satuan waktu. Namun, second hanya didukung untuk penghitung yang tidak terdistribusi, seperti yang ditetapkan oleh Distributed=false. Sebagai ganti menggunakan second, Google merekomendasikan agar Anda gunakan kebijakan SpikeArrest untuk membatasi lonjakan traffic permintaan di level kedua.

Untuk type="calendar", Anda harus menentukan nilai <StartTime>.

Tabel tidak mencantumkan nilai untuk jenis rollingwindow. Jendela Berkelanjutan kuota berfungsi dengan menetapkan ukuran periode kuota, misalnya periode satu jam atau satu hari. Ketika seorang permintaan baru masuk, kebijakan akan menentukan apakah kuota telah terlampaui sebelumnya periode waktu.

Misalnya, Anda menentukan periode dua jam yang mengizinkan 1.000 permintaan. Permintaan baru masuk pada pukul 16:45.Kebijakan itu menghitung jumlah kuota selama dua jam terakhir, yang berarti jumlah permintaan sejak pukul 14:45. Jika batas kuota belum terlampaui dua jam, maka permintaan akan diperbolehkan.

Satu menit kemudian, pada pukul 16.46, permintaan lain masuk. Sekarang kebijakan tersebut menghitung jumlah kuota sejak pukul 14.46 untuk menentukan apakah batas telah terlampaui.

Untuk jenis rollingwindow, penghitung tidak pernah direset, tetapi dihitung ulang pada setiap permintaan.

Memahami penghitung kuota

Saat kebijakan kuota dijalankan dalam alur proxy API, penghitung kuota akan berkurang. Jika mencapai batasnya, panggilan API lain yang terkait dengan penghitung tersebut tidak diizinkan. Tergantung pada konfigurasi Anda, kebijakan kuota dapat menggunakan satu penghitung atau lebih. Penting untuk dipahami ketika beberapa digunakan dan bagaimana perilakunya.

Cara kuota dihitung untuk produk API

Jika proxy API Anda disertakan dalam produk API, Anda dapat mengonfigurasi kebijakan kuota untuk menggunakan kuota aturan yang didefinisikan dalam produk tersebut. Produk API dapat menentukan aturan kuota di tingkat produk atau di tingkat operasi individual.

Penghitung kuota terpisah disimpan untuk setiap operasi yang ditentukan dalam produk API, dan aturan berikut dipatuhi:

• Jika sebuah operasi memiliki kuota yang telah ditetapkan untuknya, maka aturan kuota operasi didahulukan dari aturan kuota yang ditetapkan pada tingkat produk. J penghitung kuota terpisah dibuat untuk setiap operasi. Semua panggilan API ke jalur operasi menambah hitungannya.
• Jika operasi tidak memiliki kuota yang ditetapkan untuknya, aturan kuota tingkat produk diterapkan; tetapi, penghitung kuota terpisah tetap dipertahankan untuk operasi tersebut. Penting dalam kasus ini penting untuk dipahami bahwa meskipun aturan kuota diambil dari tingkat operasi masih mempertahankan penghitungnya sendiri.
• Jika produk API tidak menyertakan definisi kuota apa pun -- baik pada tingkat produk maupun tingkat operasi -- aturan kuota yang ditentukan dalam kebijakan berlaku; namun, dalam kasus ini juga, penghitung kuota terpisah dipertahankan untuk setiap operasi dalam produk API.

Bagian berikut menjelaskan opsi dan perilaku penghitung secara lebih mendetail.

Mengonfigurasi penghitung tingkat proxy API

Anda dapat mengonfigurasi produk API untuk mempertahankan jumlah kuota pada cakupan proxy API. Di beberapa dalam hal ini, konfigurasi kuota yang ditentukan di level produk API digunakan bersama oleh semua operasi yang tidak memiliki kuotanya sendiri. Efek dari konfigurasi ini adalah untuk membuat di proxy API level proxy untuk produk API ini.

Untuk mencapai konfigurasi ini, Anda harus menggunakan metode /apiproducts Apigee API untuk membuat atau memperbarui produk dan mengatur quotaCountScope ke PROXY dalam permintaan pembuatan atau update. Dengan konfigurasi PROXY, semua operasi yang ditentukan untuk produk API yang dikaitkan dengan {i>proxy<i} yang sama, dan tidak memiliki penghitungnya sendiri, akan penghitung kuota yang ditetapkan di level produk API.

Pada Gambar 1, Operasi 1 dan 2 terhubung dengan {i>Proxy1<i} dan Operasi 4 dan 5 terkait dengan {i>Proxy3<i}. Karena quotaCounterScope=PROXY ditetapkan dalam produk API, setiap operasi ini membagikan setelan kuota tingkat produk API. Perhatikan bahwa meskipun operasi ini memiliki kesamaan konfigurasi kuota, mereka menggunakan penghitung terpisah, berdasarkan pengaitan proxy-nya. Di sisi lain sendiri, Operasi 3 memiliki konfigurasi kuotanya sendiri, sehingga tidak terpengaruh oleh quotaCounterScope.

Gambar 1: Penggunaan tanda quotaCounterScope

Jika quotaCounterScope=PROXY, sebaiknya Anda tidak mengonfigurasi operasi ketika beberapa resource proxy memiliki set konfigurasi kuota dan yang lainnya sebaiknya tidak dilakukan. Misalnya, dalam Gambar 1, jika Operasi 4 memiliki konfigurasi kuota sendiri dan Operasi 5 tidak, konfigurasi tersebut dianggap sebagai anti-pola.

Secara default, jika suatu operasi tidak memiliki kuota yang ditetapkan untuknya, maka aturan kuota tingkat produk diterapkan; tetapi, penghitung kuota terpisah tetap dipertahankan untuk operasi tersebut.

Cara kuota dihitung jika tidak ada produk API yang digunakan

Jika tidak ada produk API yang terkait dengan proxy API, kebijakan kuota akan mempertahankan satu penghitung, terlepas dari berapa kali Anda merujuknya dalam proxy API. Nama penghitung kuota didasarkan pada atribut name kebijakan.

Misalnya, Anda membuat kebijakan Kuota bernama MyQuotaPolicy dengan batas 5 dan menempatkannya di beberapa flow (Alur A, B, dan C) di proxy API. Meskipun digunakan dalam beberapa alur, ia mempertahankan satu penghitung yang diperbarui oleh semua instance kebijakan:

• Alur A dieksekusi -> MyQuotaPolicy dijalankan dan penghitungnya = 1
• Alur B dieksekusi -> MyQuotaPolicy dijalankan dan penghitungnya = 2
• Alur A dieksekusi -> MyQuotaPolicy dijalankan dan penghitungnya = 3
• Alur C dieksekusi -> MyQuotaPolicy dijalankan dan penghitungnya = 4
• Alur A dieksekusi -> MyQuotaPolicy dijalankan dan penghitungnya = 5

Permintaan berikutnya ke salah satu dari ketiga alur ditolak karena penghitung kuota telah mencapai batasnya.

Menggunakan kebijakan Kuota yang sama di lebih dari satu tempat dalam alur proxy API, yang dapat secara tidak sengaja menyebabkan Kuota habis lebih cepat dari yang diperkirakan, adalah anti-pola yang dijelaskan di Pengantar anti-pola.

Atau, Anda dapat menetapkan beberapa kebijakan Quota di proxy API dan menggunakan kebijakan di setiap alur. Setiap kebijakan Kuota mempertahankan penghitungnya sendiri, berdasarkan atribut name kebijakan.

Membuat beberapa penghitung melalui konfigurasi kebijakan

Anda dapat menggunakan Elemen <Class> atau <Identifier> di kebijakan Quota untuk menentukan beberapa penghitung unik dalam satu kebijakan. Dengan menggunakan satu kebijakan dapat mempertahankan penghitung yang berbeda berdasarkan aplikasi yang membuat permintaan, pengembang aplikasi yang membuat permintaan, ID klien atau ID klien lainnya, dan banyak lagi. Lihat contoh di atas untuk informasi lebih lanjut tentang penggunaan Elemen <Class> atau <Identifier>.

Catatan: Penghitung kuota dibatasi oleh proxy API yang berisi Kebijakan kuota. Jika beberapa proxy API berisi kebijakan Quota dengan nama yang sama, penghitung akan dikelola secara terpisah.

Notasi waktu

Semua waktu Kuota ditetapkan ke aplikasi Universal Terkoordinasi Zona waktu (UTC).

Notasi waktu kuota mengikuti notasi tanggal standar internasional yang ditentukan dalam ISO 8601 standar.

Tanggal didefinisikan sebagai tahun, bulan, dan hari, dalam format berikut: YYYY-MM-DD. Misalnya, 2021-02-04 merepresentasikan 4 Februari 2021.

Waktu dalam sehari didefinisikan sebagai jam, menit, dan detik dalam format berikut: hours:minutes:seconds. Misalnya, 23:59:59 mewakili waktu detik sebelum tengah malam.

Perhatikan bahwa dua notasi, 00:00:00 dan 24:00:00, tersedia untuk membedakan dua tengah malam yang dapat dikaitkan dengan satu tanggal. Oleh karena itu, 2021-02-04 24:00:00 adalah tanggal dan waktu yang sama dengan 2021-02-05 00:00:00. Yang terakhir adalah biasanya notasi yang disukai.

Mendapatkan setelan kuota dari konfigurasi produk API

Anda dapat menetapkan batas kuota dalam konfigurasi produk API. Batasan tersebut tidak otomatis memberlakukan kuota. Sebagai gantinya, Anda dapat merujuk setelan kuota produk dalam kebijakan kuota. Berikut beberapa keuntungan penetapan kuota pada produk untuk referensi kebijakan kuota:

• Kebijakan kuota dapat menggunakan setelan seragam di semua proxy API di produk API.
• Anda dapat membuat perubahan runtime pada setelan kuota di produk API, dan kebijakan kuota yang mereferensikan nilai tersebut akan otomatis memiliki nilai kuota yang diperbarui.

Untuk informasi selengkapnya tentang cara menggunakan setelan kuota dari produk API, lihat "Kuota Dinamis" contoh di atas.

Untuk info tentang cara mengonfigurasi produk API dengan batas kuota, lihat Mengelola produk API.

Mengonfigurasi penghitung kuota bersama

Biasanya, kebijakan Kuota menghitung semua permintaan yang dikirim ke proxy API. Untuk beberapa kasus penggunaan, Anda mungkin ingin menerapkan jumlah kuota permintaan masuk, tetapi juga menambah jumlah kuota untuk menargetkan respons yang memenuhi kondisi tertentu. Tiga elemen kebijakan Kuota jika digunakan bersama-sama, <SharedName>, <CountOnly>, dan <EnforceOnly>, memungkinkan Anda untuk menyesuaikan kebijakan Kuota untuk menerapkan kuota permintaan masuk dan menghitung respons target berdasarkan syarat yang Anda tentukan.

Misalnya, Anda ingin menambah penghitung kuota untuk proxy API tempat respons dari target backend memiliki kode status HTTP 200. Untuk mencapai misi khusus ini penghitungan, lakukan langkah berikut:

• Menambahkan kebijakan Kuota ke alur Permintaan ProxyEndpoint dengan <SharedName> yang ditetapkan dengan nilai nama dan <EnforceOnly> ditetapkan ke true.
• Tambahkan kebijakan Quota lain ke alur Respons ProxyEndpoint dengan <SharedName> ditetapkan ke nilai nama yang sama dengan kebijakan pertama dan <CountOnly> ditetapkan ke true.
• Tempatkan kebijakan Kuota kedua (yang dengan <CountOnly>) dalam kondisional yang menetapkan ketentuan untuk menambah penghitung kuota.

Untuk contoh yang menunjukkan cara menggunakan penghitung bersama, lihat Penghitung bersama di bagian Contoh.

Sampel

Contoh kode kebijakan ini menggambarkan cara memulai dan mengakhiri periode kuota dengan:

Kuota Dinamis Lainnya

<Quota name="CheckQuota">
  <Interval ref="verifyapikey.verify-api-key.apiproduct.developer.quota.interval">1</Interval>
  <TimeUnit ref="verifyapikey.verify-api-key.apiproduct.developer.quota.timeunit">hour</TimeUnit>
  <Allow count="200" countRef="verifyapikey.verify-api-key.apiproduct.developer.quota.limit"/>
</Quota>

Kuota dinamis memungkinkan Anda mengonfigurasi satu kebijakan Kuota yang menerapkan kuota yang berbeda berdasarkan informasi yang diteruskan ke kebijakan Kuota. Istilah lain untuk setelan Kuota di konteks ini adalah paket layanan. Kuota dinamis memeriksa aplikasi paket layanan dan kemudian memberlakukan setelan tersebut.

Catatan: Jika Anda menentukan nilai dan referensi untuk elemen, maka referensi yang diprioritaskan akan diprioritaskan. Jika referensi tidak di-resolve saat runtime, nilainya adalah data.

Misalnya, ketika Anda membuat produk API, Anda bisa secara opsional menetapkan kuota yang diizinkan batas, satuan waktu, dan interval. Namun, menetapkan nilai ini pada produk API tidak menerapkan penggunaannya dalam proxy API. Anda juga harus menambahkan kebijakan Quota ke proxy API yang akan membaca nilai-nilai ini. Lihat Create API produk untuk mengetahui lebih banyak lagi.

Pada contoh di atas, proxy API yang berisi kebijakan Kuota menggunakan Kebijakan VerifyAPIKey, bernama verify-api-key, untuk memvalidasi kunci API yang diteruskan dalam permintaan. Tujuan Kemudian, kebijakan kuota mengakses variabel alur dari kebijakan VerifyAPIKey untuk membaca kuota yang ditetapkan pada produk API.

Pilihan lainnya adalah menyetel atribut khusus pada masing-masing developer atau aplikasi, lalu membaca nilai-nilai tersebut di kebijakan Quota. Misalnya, untuk menetapkan nilai kuota yang berbeda per developer. Anda menetapkan atribut khusus pada developer yang berisi batas, satuan waktu, dan interval. Kemudian, Anda akan mereferensikan nilai ini dalam kebijakan Quota seperti yang ditunjukkan di bawah ini:

<Quota name="DeveloperQuota">
  <Identifier ref="verifyapikey.verify-api-key.client_id"/>
  <Interval ref="verifyapikey.verify-api-key.developer.timeInterval"/>
  <TimeUnit ref="verifyapikey.verify-api-key.developer.timeUnit"/>
  <Allow countRef="verifyapikey.verify-api-key.developer.limit"/>
</Quota>

Contoh ini juga menggunakan variabel alur VerifyAPIKey untuk mereferensikan atribut khusus ditetapkan pada pengembang.

Anda dapat menggunakan variabel apa pun untuk menetapkan parameter kebijakan Quota. Variabel-variabel tersebut dapat berasal dari:

• Variabel flow
• Properti di produk, aplikasi, atau developer API
• Peta nilai kunci (KVM)
• Header, parameter kueri, parameter formulir, dan lainnya

Untuk setiap proxy API, Anda dapat menambahkan kebijakan Kuota, baik yang merujuk ke variabel yang sama seperti semua kebijakan Kuota lainnya di semua proxy lainnya, atau kebijakan Kuota dapat variabel yang unik untuk kebijakan dan {i>proxy<i} tersebut.

Waktu mulai

<Quota name="QuotaPolicy" type="calendar">
  <StartTime>2021-02-18 10:30:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

Untuk Kuota dengan type yang ditetapkan ke calendar, Anda harus menentukan nilai <StartTime> eksplisit. Nilai waktu adalah waktu GMT, bukan waktu lokal baik. Jika Anda tidak memberikan nilai <StartTime> untuk jenis kebijakan calendar, Apigee mengeluarkan error.

Penghitung Kuota untuk setiap aplikasi dimuat ulang berdasarkan <StartTime>, Nilai <Interval>, dan <TimeUnit>. Untuk ini misalnya, Kuota mulai dihitung pada tanggal 18 Februari 2021 pukul 10.30 GMT, dan diperbarui setiap 5 jam. Oleh karena itu, pembaruan berikutnya adalah pukul 15.30 GMT pada 18 Februari 2021.

Penghitung Akses

<Quota name="QuotaPolicy">
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

Proxy API memiliki akses ke variabel alur yang ditetapkan oleh kebijakan Kuota. Anda dapat mengakses variabel alur ini di proxy API untuk melakukan pemrosesan bersyarat, memantau kebijakan karena mendekati batas kuota, mengembalikan penghitung kuota saat ini ke aplikasi, atau alasan.

Karena akses variabel alur untuk kebijakan didasarkan pada kebijakan Atribut name, untuk kebijakan di atas yang bernama <Quota> Anda mengakses variabel alurnya dalam bentuk:

• ratelimit.QuotaPolicy.allowed.count: Jumlah yang diizinkan.
• ratelimit.QuotaPolicy.used.count: Nilai penghitung saat ini.
• ratelimit.QuotaPolicy.expiry.time: Waktu UTC saat penghitung direset.

Ada banyak variabel alur lain yang dapat Anda akses, seperti yang dijelaskan di bawah ini.

Misalnya, Anda dapat menggunakan kebijakan TetapkanMessage berikut untuk menampilkan nilai Variabel aliran kuota sebagai header respons:

<AssignMessage continueOnError="false" enabled="true" name="ReturnQuotaVars">
  <AssignTo createNew="false" type="response"/>
  <Set>
    <Headers>
      <Header name="QuotaLimit">{ratelimit.QuotaPolicy.allowed.count}</Header>
      <Header name="QuotaUsed">{ratelimit.QuotaPolicy.used.count}</Header>
      <Header name="QuotaResetUTC">{ratelimit.QuotaPolicy.expiry.time}</Header>
    </Headers>
  </Set>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</AssignMessage>

Penghitung bersama

Contoh berikut mengilustrasikan cara mengonfigurasi penghitung bersama untuk proxy API, dengan penghitung kuota juga bertambah ketika respons target adalah status HTTP 200. Karena kedua kebijakan Kuota menggunakan nilai <SharedName> yang sama, Kebijakan kuota akan memiliki penghitung kuota yang sama. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi penghitung kuota bersama.

Contoh konfigurasi ProxyEndpoint:

<ProxyEndpoint name="default">
    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>Enforce-Only</Name>  <!--First quota policy enforces quota count -->
            </Step>
        </Request>
        <Response>
            <Step>
                <Name>Count-Only</Name>   <!-- Second quota policy counts quota if call is successful -->
                <Condition>response.status.code = 200</Condition>
            </Step>
        </Response>
        <Response/>
    </PreFlow>
    <Flows/>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <HTTPProxyConnection>
        <BasePath>/quota-shared-name</BasePath>
    </HTTPProxyConnection>
    <RouteRule name="noroute"/>
</ProxyEndpoint>

Contoh kebijakan kuota pertama:

<Quota continueOnError="false" enabled="true" name="Enforce-Only" type="rollingwindow">
    <DisplayName>Enforce-Only</DisplayName>
    <Properties/>
    <Allow count="5"/>
    <Interval>2</Interval>
    <TimeUnit>minute</TimeUnit>
    <Distributed>true</Distributed>
    <Synchronous>true</Synchronous>
    <EnforceOnly>true</EnforceOnly>
    <SharedName>common-proxy</SharedName>  <!-- Notice that SharedName value is the same for both Quota policies -->
</Quota>

Contoh kebijakan Kuota Kedua:

<Quota continueOnError="false" enabled="true" name="Count-Only" type="rollingwindow">
    <DisplayName>Count-Only</DisplayName>
    <Properties/>
    <Allow count="5"/>
    <Interval>2</Interval>
    <TimeUnit>minute</TimeUnit>
    <Distributed>true</Distributed>
    <Synchronous>true</Synchronous>
    <CountOnly>true</CountOnly>
    <SharedName>common-proxy</SharedName>  <!-- Same name as the first policy -->
</Quota>

Catatan: Anda tidak dapat menggunakan <Class> dan <Identifier> elemen dalam kebijakan Kuota yang sama.

Permintaan Pertama

<Quota name="MyQuota">
  <Interval>1</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="10000"/>
</Quota>

Gunakan kode contoh ini untuk menerapkan kuota 10.000 panggilan per satu jam. Kebijakan akan direset penghitung kuota di bagian atas setiap jam. Jika penghitung mencapai kuota 10.000 panggilan sebelum akhir jam tersebut, panggilan yang melebihi 10.000 akan ditolak.

Misalnya, jika penghitung dimulai pada 2021-07-08 07:00:00, penghitung akan direset ke 0 pukul 2021-07-08 08:00:00 (1 jam dari waktu mulai). Jika pesan pertama adalah diterima di 2021-07-08 07:35:28 dan jumlah pesan mencapai 10.000 sebelum 2021-07-08 08:00:00, panggilan yang melebihi jumlah tersebut akan ditolak hingga hitungan ulang akan diatur ulang di bagian atas jam.

Waktu reset penghitung didasarkan pada kombinasi <Interval> dan <TimeUnit> Misalnya, jika Anda menetapkan <Interval> ke 12 selama <TimeUnit> jam, lalu penghitung direset setiap dua belas jam. Anda dapat menyetel <TimeUnit> ke menit, jam, hari, minggu, atau bulan.

Anda dapat merujuk kebijakan ini di beberapa tempat di proxy API. Misalnya, Anda dapat menempatkannya di Proxy PreFlow sehingga dieksekusi pada setiap permintaan. Atau, Anda bisa menempatkan di beberapa alur di proxy API. Jika Anda menggunakan kebijakan ini di beberapa tempat di proxy, ia mengelola satu penghitung yang diperbarui oleh semua instance kebijakan.

Atau, Anda dapat menentukan beberapa kebijakan Quota di proxy API Anda. Setiap kebijakan Kuota mempertahankan penghitungnya sendiri, berdasarkan atribut name kebijakan.

Tetapkan ID

<Quota name="QuotaPolicy" type="calendar">
  <Identifier ref="request.header.clientId"/>
  <StartTime>2021-02-18 10:00:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

Secara default, kebijakan Kuota menentukan satu penghitung untuk proxy API, terlepas dari asal permintaan. Atau, Anda dapat menggunakan atribut <Identifier> dengan kebijakan Kuota untuk mempertahankan penghitung terpisah berdasarkan nilai Atribut <Identifier>.

Misalnya, gunakan tag <Identifier> untuk menentukan penghitung terpisah untuk setiap client ID. Berdasarkan permintaan ke proxy Anda, aplikasi klien kemudian meneruskan header yang berisi clientID, seperti yang ditunjukkan dalam contoh di atas.

Anda dapat menentukan variabel alur apa pun ke atribut <Identifier>. Sebagai sebagai contoh, Anda dapat menentukan bahwa parameter kueri bernama id berisi ID:

<Identifier ref="request.queryparam.id"/>

Jika Anda menggunakan kebijakan VerifyAPIKey untuk memvalidasi kunci API, atau kebijakan OAuthV2 token OAuth, Anda dapat menggunakan informasi dalam token atau kunci API untuk menentukan untuk kebijakan Kuota yang sama. Misalnya, Elemen <Identifier> menggunakan variabel alur client_id dari Kebijakan VerifyAPIKey bernama verify-api-key:

<Identifier ref="verifyapikey.verify-api-key.client_id"></Identifier>

Setiap nilai client_id unik kini menentukan penghitungnya sendiri di Kuota lebih lanjut.

Class

<Quota name="QuotaPolicy">
  <Interval>1</Interval>
  <TimeUnit>day</TimeUnit>
  <Allow>
    <Class ref="request.header.developer_segment">
      <Allow class="platinum" count="10000"/>
      <Allow class="silver" count="1000" />
    </Class>
  </Allow>
</Quota>

Anda dapat menetapkan batas Kuota secara dinamis menggunakan jumlah Kuota berbasis class. Dalam contoh ini, batas kuota ditentukan oleh nilai developer_segment header yang diteruskan dengan setiap permintaan. Variabel tersebut dapat memiliki nilai platinum atau silver. Jika header memiliki nilai yang tidak valid, kebijakan akan menampilkan kuota kesalahan pelanggaran.

Catatan: Anda tidak dapat menggunakan <Class> dan sekaligus Elemen <Identifier> dalam kebijakan Kuota yang sama.

---

Elemen <Quota>

Berikut adalah atribut dan elemen turunan <Quota>. Perhatikan bahwa beberapa elemen kombinasi keduanya bersifat eksklusif atau tidak wajib. Lihat contoh untuk penggunaan tertentu.

Tujuan verifyapikey.my-verify-key-policy.apiproduct.* variabel di bawah tersedia secara default jika kebijakan VerifyAPIKey yang disebut my-verify-key-policy digunakan untuk memeriksa kunci API aplikasi dalam permintaan. Nilai variabel berasal dari setelan kuota pada produk API yang dikaitkan dengan kunci seperti yang dijelaskan dalam Mendapatkan setelan kuota dari produk API konfigurasi.

<Quota continueOnError="false" enabled="true" name="Quota-3" type="calendar">
   <DisplayName>Quota 3</DisplayName>
   <Allow count="UPPER_REQUEST_LIMIT" countRef="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.limit"/>
   <Allow>
      <Class ref="request.queryparam.time_variable">
        <Allow class="peak_time" count="UPPER_LIMIT_DURING_PEAK"/>
        <Allow class="off_peak_time" count="UPPER_LIMIT_DURING_OFFPEAK"/>
      </Class>
   </Allow>
   <Interval ref="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.interval">1</Interval>
   <TimeUnit ref="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.timeunit">month</TimeUnit>
   <StartTime>2021-7-16 12:00:00</StartTime>
   <Distributed>false</Distributed>
   <Synchronous>false</Synchronous>
   <AsynchronousConfiguration>
      <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
      <SyncMessageCount>5</SyncMessageCount>
   </AsynchronousConfiguration>
   <Identifier/>
   <MessageWeight/>
   <UseQuotaConfigInAPIProduct>
     <DefaultConfig>
       <Allow>
          <Class ref="request.queryparam.time_variable">
            <Allow class="peak_time" count="5000"/>
            <Allow class="off_peak_time" count="1000"/>
          </Class>
       </Allow>
       <Interval ref="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.interval">1</Interval>
       <TimeUnit ref="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.timeunit">month</TimeUnit>
     </DefaultConfig>
   </UseQuotaConfigInAPIProduct>
   </SharedName>
   </CountOnly>
   </EnforceOnly>
</Quota>

Atribut berikut khusus untuk kebijakan ini:

Atribut	Deskripsi	Default	Kehadiran
jenis	Menetapkan Jenis kebijakan kuota, yang menentukan kapan dan bagaimana penghitung kuota memeriksa penggunaan kuota serta cara mengatur ulang. Jika Anda tidak menetapkan type, penghitung akan dimulai dari awal dalam menit/jam/hari/minggu/bulan. Nilai yang valid mencakup: calendar rollingwindow flexi Untuk mengetahui deskripsi lengkap setiap jenis, lihat Kebijakan kuota jenis data.	T/A	Opsional

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: Aturan error HANYA dipicu dalam status error (tentang continueOnError) Menangani kesalahan dalam alur saat ini	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

<Allow>

Menentukan batas jumlah untuk kuota. Jika penghitung untuk kebijakan mencapai batas ini , panggilan berikutnya akan ditolak hingga penghitung direset.

Dapat juga berisi elemen <Class> yang mengkondisikan <Allow> berdasarkan variabel flow.

Nilai Default	t/a
Wajib?	Opsional
Jenis	Jenis bilangan bulat atau Kompleks
Elemen Induk	<Quota>
Elemen Turunan	<Class>

Berikut adalah tiga cara untuk menetapkan elemen <Allow>:

<Allow count="2000"/>

<Allow countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>

<Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/> 

Jika Anda menentukan count dan countRef, maka countRef yang mendapatkan prioritas. Jika countRef tidak di-resolve saat runtime, nilai count digunakan.

Anda juga dapat menentukan elemen <Class> sebagai turunan dari <Allow> untuk menentukan elemen yang diizinkan jumlah kebijakan berdasarkan variabel alur. Apigee mencocokkan nilai variabel flow dengan class dari elemen <Allow>, seperti yang ditunjukkan di bawah ini:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

Tabel berikut mencantumkan atribut <Allow>:

Atribut	Deskripsi	Default	Kehadiran
count	Gunakan untuk menentukan jumlah pesan untuk kuota. Misalnya, nilai atribut count 100, Interval 1, dan TimeUnit bulan menentukan kuota 100 pesan per bulan.	2000	Opsional
countRef	Gunakan untuk menentukan variabel alur yang berisi jumlah pesan untuk kuota. countRef lebih diprioritaskan daripada atribut count.	tidak ada	Opsional

<Class>

Memungkinkan Anda menyesuaikan nilai dari elemen <Allow> berdasarkan nilai variabel flow. Sebagai setiap tag turunan <Allow> yang berbeda dari <Class>, kebijakan tersebut mempertahankan penghitungan yang berbeda.

Nilai Default	t/a
Wajib?	Opsional
Jenis	Jenis kompleks
Elemen Induk	<Allow>
Elemen Turunan	<Allow> (turunan dari <Class>)

Untuk menggunakan elemen <Class>, tentukan variabel alur menggunakan elemen ref ke elemen <Class>. Apigee kemudian menggunakan nilai variabel alur untuk memilih salah satu elemen turunan <Allow> guna menentukan elemen yang diizinkan penghitungan kebijakan. Apigee mencocokkan nilai variabel flow dengan class dari elemen <Allow>, seperti yang ditunjukkan di bawah ini:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

Dalam contoh ini, penghitung kuota saat ini ditentukan oleh nilai Parameter kueri time_variable diteruskan dengan setiap permintaan. Variabel itu dapat memiliki nilai dari peak_time atau off_peak_time. Jika parameter kueri berisi nilai yang tidak valid kebijakan akan menampilkan error pelanggaran kuota.

Catatan: Anda tidak dapat menggunakan <Class> dan sekaligus <Identifier> elemen dalam kebijakan Kuota yang sama.

Tabel berikut mencantumkan atribut <Class>:

Atribut	Deskripsi	Default	Kehadiran
referensi	Gunakan untuk menentukan variabel flow yang berisi class kuota untuk kuota.	tidak ada	Wajib

<Allow> (turunan dari <Class>)

Menentukan batas untuk penghitung kuota ditentukan oleh elemen <Class>. Untuk setiap tag turunan <Allow> yang berbeda dari <Class>, tetapi menghasilkan penghitung yang berbeda.

Nilai Default	t/a
Wajib?	Opsional
Jenis	Jenis kompleks
Elemen Induk	<Class>
Elemen Turunan	Tidak ada

Contoh:

    <Allow>
      <Class ref="request.queryparam.time_variable">
        <Allow count="5000"/>
        <Allow count="1000"/>
      </Class>
    </Allow>

Dalam contoh ini, kebijakan Kuota menyimpan dua penghitung kuota yang bernama peak_time dan off_peak_time. Yang digunakan tergantung pada parameter kueri yang diteruskan, seperti yang ditunjukkan dalam contoh <Class>.

Tabel berikut mencantumkan atribut <Allow>:

Atribut	Deskripsi	Default	Kehadiran
class	Menentukan nama penghitung kuota.	tidak ada	Wajib
count	Menentukan batas kuota untuk penghitung.	tidak ada	Wajib

<Interval>

Menentukan jumlah jangka waktu penghitungan kuota.

Nilai Default	t/a
Wajib?	Wajib
Jenis	Bilangan bulat
Elemen Induk	<Quota>
Elemen Turunan	Tidak ada

Gunakan untuk menentukan bilangan bulat (misalnya, 1, 2, 5, 60, dan seterusnya) yang akan dipasangkan dengan Elemen <TimeUnit> yang Anda tentukan (menit, jam, hari, minggu, atau bulan) untuk menentukan waktu selama periode saat Apigee menghitung penggunaan kuota.

Misalnya, interval 24 dengan <TimeUnit> dari hour berarti kuota akan dihitung selama 24 jam.

<Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>

Tabel berikut mencantumkan atribut <Interval>:

Atribut	Deskripsi	Default	Kehadiran
referensi	Gunakan untuk menentukan variabel alur yang berisi interval untuk kuota tambahan. ref lebih diprioritaskan daripada interval eksplisit dengan sejumlah nilai. Jika referensi dan nilai ditetapkan, maka referensi akan mendapatkan prioritas. Jika ref tidak di-resolve saat runtime, nilai tersebut akan digunakan.	tidak ada	Opsional

<TimeUnit>

Menentukan unit waktu yang berlaku untuk kuota.

Nilai Default	t/a
Wajib?	Wajib
Jenis	String
Elemen Induk	<Quota>
Elemen Turunan	Tidak ada

Pilih dari minute, hour, day, week, month, atau year.

Catatan: Kebijakan Kuota juga mendukung second sebagai satuan waktu. Namun, second hanya didukung untuk penghitung yang tidak terdistribusi (saat <Distributed> ditetapkan ke false). Google merekomendasikan agar Anda gunakan kebijakan SpikeArrest untuk membatasi lonjakan traffic permintaan di tingkat kedua, bukan gunakan nilai second di sini.

Misalnya, Interval dari 24 dengan TimeUnit dari hour berarti kuota akan dihitung selama 24 jam.

<TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>

Default:	tidak ada
Kehadiran:	Wajib
Jenis:	String

Tabel berikut mencantumkan atribut <TimeUnit>:

Atribut	Deskripsi	Default	Kehadiran
referensi	Menentukan variabel alur yang berisi unit waktu untuk kuota. ref lebih diprioritaskan daripada nilai interval eksplisit. Jika ref melakukannya tidak di-resolve saat runtime, maka nilai interval yang akan digunakan.	tidak ada	Opsional

<StartTime>

Jika type ditetapkan ke calendar, tentukan tanggal dan waktu saat penghitung kuota mulai menghitung, terlepas dari apakah ada permintaan diterima dari aplikasi apa pun.

Nilai Default	t/a
Wajib?	Opsional (Wajib jika type ditetapkan ke calendar)
Jenis	String dalam ISO 8601 format tanggal dan waktu
Elemen Induk	<Quota>
Elemen Turunan	Tidak ada

Anda harus memberikan <StartTime> eksplisit saat type ditetapkan ke calendar; Anda tidak dapat menggunakan referensi ke variabel alur. Jika Anda menentukan nilai <StartTime> jika tidak ada nilai type yang ditetapkan, Apigee akan menampilkan {i>error<i}.

Contoh:

<StartTime>2021-7-16 12:00:00</StartTime>

<Distributed>

Menentukan apakah Apigee menggunakan satu atau beberapa node untuk memproses permintaan.

Nilai Default	salah
Wajib?	Opsional
Jenis	Boolean
Elemen Induk	<Quota>
Elemen Turunan	Tidak ada

Setel ke true untuk menetapkan bahwa kebijakan harus mempertahankan dan terus menyinkronkannya di semua node. Node dapat berada di seluruh zona ketersediaan dan/atau region.

Catatan: Jika memiliki akun Apigee berbayar, Anda biasanya memiliki beberapa Pemroses Pesan dalam penginstalan Anda, dan jumlahnya dapat bervariasi berdasarkan beban traffic Anda. Akun evaluasi biasanya memiliki dua Pemroses Pesan.

Jika menggunakan nilai default false, Anda mungkin akan melebihi kuota karena jumlah untuk setiap {i>node<i} tidak dibagikan:

<Distributed>false</Distributed>

Untuk menjamin bahwa penghitung disinkronkan, dan diperbarui pada setiap permintaan, atur <Distributed> dan <Synchronous> ke true:

<Distributed>true</Distributed>
<Synchronous>true</Synchronous>

<Synchronous>

Menentukan apakah akan memperbarui penghitung kuota terdistribusi secara sinkron.

Nilai Default	salah
Wajib?	Opsional
Jenis	Boolean
Elemen Induk	<Quota>
Elemen Turunan	Tidak ada

Tetapkan ke true untuk memperbarui penghitung kuota terdistribusi secara sinkron. Ini berarti bahwa pembaruan pada penghitung dilakukan pada saat yang sama kuota diperiksa pada permintaan ke API. Tetapkan ke true jika Anda tidak mengizinkan API apa pun panggilan melebihi kuota.

Catatan: Dengan menerapkan update sinkron ke penghitung, ada potensi dampak terhadap performa dan throughput yang lebih rendah. Dalam beberapa kasus, penggunaan <Synchronous>true</Synchronous> dapat menyebabkan kebijakan kuota gagal memproses beberapa transaksi.

Tetapkan ke false untuk memperbarui penghitung kuota secara asinkron. Artinya beberapa panggilan API yang melebihi kuota akan dapat dilakukan, tergantung pada penghitung kuota di repositori pusat diupdate secara asinkron. Namun, Anda tidak akan menghadapi dampak kinerja potensial yang terkait dengan pembaruan sinkron.

Interval update asinkron default adalah 10 detik. Gunakan <AsynchronousConfiguration> untuk mengonfigurasi perilaku asinkron ini.

<Synchronous>false</Synchronous>

<AsynchronousConfiguration>

Mengonfigurasi interval sinkronisasi di antara penghitung kuota terdistribusi saat kebijakan elemen konfigurasi <Synchronous> tidak ada atau tidak ada dan disetel ke false. Apigee mengabaikan elemen ini jika <Synchronous> ditetapkan ke true.

Nilai Default	t/a
Wajib?	Opsional
Jenis	Jenis kompleks
Elemen Induk	<Quota>
Elemen Turunan	<SyncIntervalInSeconds> <SyncMessageCount>

Anda dapat menentukan perilaku sinkronisasi menggunakan Elemen turunan <SyncIntervalInSeconds> atau <SyncMessageCount>. Gunakan salah satu atau kedua elemen. Misalnya,

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

atau

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

• Jika hanya ada <SyncIntervalInSeconds>, kuota akan disinkronkan setiap N detik, dengan N adalah nilai yang ditentukan dalam elemen, terlepas dari berapa banyak pesan yang telah ditangani.
• Jika hanya ada <SyncMessageCount>, kuota akan menyinkronkan setiap M pesan, di mana M adalah nilai yang ditentukan dalam elemen, atau setiap 10 detik, mana yang lebih dulu.
• Bila kedua elemen ada, kuota akan menyinkronkan setiap M pesan atau setiap N detik, mana saja yang lebih dulu.
• Jika <AsynchronousConfiguration> tidak ada atau tidak ada elemen turunan, kuota disinkronkan setiap 10 detik, terlepas dari berapa banyak pesan yang telah ditangani.

<SyncIntervalInSeconds>

Mengganti perilaku default yang digunakan untuk menjalankan pembaruan asinkron setelah dengan interval 10 detik.

Nilai Default	10 detik
Wajib?	Opsional
Jenis	Bilangan bulat
Elemen Induk	<AsynchronousConfiguration>
Elemen Turunan	Tidak ada

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

Interval sinkronisasi harus >= 10 detik, seperti yang dijelaskan di Batas.

<SyncMessageCount>

Menentukan jumlah permintaan yang akan diproses sebelum menyinkronkan penghitung kuota.

Nilai Default	t/a
Wajib?	Opsional
Jenis	Bilangan bulat
Elemen Induk	<AsynchronousConfiguration>
Elemen Turunan	Tidak ada

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

Dengan menggunakan konfigurasi dalam contoh ini, pada setiap node, jumlah kuota akan disinkronkan setelah setiap 5 permintaan, atau setiap 10 detik, mana saja yang lebih dulu.

<Identifier>

Mengonfigurasi kebijakan untuk membuat penghitung unik berdasarkan variabel alur.

Nilai Default	t/a
Wajib?	Opsional
Jenis	String
Elemen Induk	<Quota>
Elemen Turunan	Tidak ada

Melalui elemen Identifier, Anda dapat mengalokasikan jumlah panggilan ke bucket berbeda yang ditentukan oleh nilai dalam flow variabel. Misalnya, Anda dapat menggunakan variabel developer.id, yang diisi setelah Kebijakan VerifyAPIKey, untuk menerapkan satu batas kuota hingga semua instance dari semua aplikasi yang dibuat oleh setiap developer tertentu, atau Anda dapat menggunakan client_id untuk memberlakukan batas kuota untuk setiap aplikasi tertentu. Konfigurasi untuk yang terakhir terlihat seperti ini:

<Identifier ref="client_id"/>

Anda dapat merujuk ke variabel kustom yang mungkin ditetapkan dengan kebijakan Tugas Pesan atau kebijakan JavaScript, atau variabel yang ditetapkan secara implisit, seperti variabel ditetapkan oleh kebijakan VerifyAPIKey atau kebijakan VerifyJWT. Untuk mengetahui informasi selengkapnya tentang variabel, lihat Menggunakan Variabel Alur, dan untuk daftar variabel populer yang ditentukan oleh Apigee, baca Referensi variabel flow.

Jika Anda tidak menggunakan elemen ini, kebijakan akan mengalokasikan semua jumlah panggilan ke dalam satu penghitung untuk kebijakan Kuota tertentu.

Jika Anda merujuk ke developer.id atau developer.app.id untuk kuota <Identifier>, atau gunakan variabel tersebut sebagai satu elemen dalam konfigurasi variabel yang digunakan sebagai <Identifier>, perlu diketahui bahwa nilai variabel ini mungkin perubahan, selama beberapa periode pemeliharaan di masa mendatang. Hal ini jarang terjadi, bukan kejadian biasa. Namun, jika masalah itu terjadi, dan jika Anda memiliki kebijakan Kuota, <Identifier>, kuota tidak akan diterapkan secara ketat selama jangka waktu tersebut tempat perubahan terjadi.

Elemen ini juga dibahas di Bagaimana apakah kebijakan Kuota akan berfungsi jika tidak ada ID yang ditentukan?

Catatan: Anda tidak dapat menggunakan <Class> dan sekaligus <Identifier> dalam kebijakan Kuota yang sama.

Tabel berikut menjelaskan atribut <Identifier>:

Atribut	Deskripsi	Default	Kehadiran
referensi	Menentukan variabel alur yang mengidentifikasi penghitung yang akan digunakan untuk permintaan. Tujuan variabel dapat merujuk ke header HTTP, parameter kueri, parameter formulir, atau elemen isi pesan, atau beberapa nilai lain untuk mengidentifikasi cara mengalokasikan jumlah panggilan. client_id biasanya digunakan sebagai variabel. client_id juga dikenal sebagai kunci API atau kunci konsumen, dan dihasilkan untuk aplikasi saat yang terdaftar di organisasi di Apigee. Anda dapat menggunakan ID ini jika telah mengaktifkan kunci API atau kebijakan otorisasi OAuth untuk API Anda.	T/A	Opsional

<MessageWeight>

Menentukan biaya yang ditetapkan ke setiap pesan untuk tujuan kuota. Gunakan elemen ini untuk meningkatkan dampak pesan yang, misalnya, memakai lebih banyak sumber daya komputasi dibandingkan yang lain.

Nilai Default	t/a
Wajib?	Opsional
Jenis	Bilangan bulat
Elemen Induk	<Quota>
Elemen Turunan	Tidak ada

Misalnya, Anda ingin menghitung POST pesan sebagai dua kali lebih banyak mahal seperti GET membuat pesan teks. Oleh karena itu, Anda menetapkan <MessageWeight> ke 2 untuk POST dan 1 untuk GET. Anda bahkan dapat menyetel <MessageWeight> ke 0 sehingga permintaan tidak akan memengaruhi penghitung.

Dalam contoh ini, jika kuotanya adalah 10 pesan per menit dan <MessageWeight> untuk permintaan POST adalah 2, maka kuota akan mengizinkan 5 permintaan POST dalam interval 10 menit apa pun. Setiap permintaan tambahan, POST atau GET, sebelum reset penghitung ditolak.

Nilai yang mewakili <MessageWeight> harus ditentukan oleh flow variabel, dan dapat diekstrak dari header HTTP, parameter kueri, permintaan XML atau JSON payload, atau variabel alur lainnya. Misalnya, Anda mengaturnya pada {i>header <i}bernama weight:

<MessageWeight ref="message_weight"/>

<UseQuotaConfigInAPIProduct>

Menentukan setelan kuota untuk produk API, seperti unit waktu, interval, dan setelan yang diizinkan maksimum.

Nilai Default	t/a
Wajib?	Opsional
Jenis	Jenis kompleks
Elemen Induk	<Quota>
Elemen Turunan	<DefaultConfig>

Jika Anda menambahkan elemen <UseQuotaConfigInAPIProduct> ke kebijakan Kuota, Apigee mengabaikan semua Elemen turunan <Allow>, <Interval>, dan <TimeUnit> dari <Quota>.

Elemen <UseQuotaConfigInAPIProduct> hanyalah penampung untuk setelan default yang Anda tentukan menggunakan elemen <DefaultConfig>, seperti yang ditunjukkan contoh berikut:

<UseQuotaConfigInAPIProduct stepName="POLICY_NAME">
  <DefaultConfig>...</DefaultConfig>
</UseQuotaConfigInAPIProduct>

Anda dapat menggunakan atribut stepName untuk mereferensikan kebijakan VerifyAPIKey atau pengoperasian kebijakan ValidateToken dari kebijakan OAuthv2 dalam alur.

Tabel berikut menjelaskan atribut <UseQuotaConfigInAPIProduct>:

Atribut	Deskripsi	Default	Kehadiran
stepName	Mengidentifikasi nama kebijakan autentikasi dalam alur. Target dapat berupa Kebijakan VerifyAPIKey atau kebijakan OAuthv2.	T/A	Wajib

Untuk informasi selengkapnya, lihat referensi berikut:

• <DefaultConfig>
• Apa yang dimaksud dengan produk API?
• Mengelola produk API

<DefaultConfig>

Berisi nilai default untuk kuota produk API. Saat Anda menentukan <DefaultConfig>, ketiga elemen turunan diperlukan.

Nilai Default	t/a
Wajib?	Opsional
Jenis	Jenis kompleks
Elemen Induk	<UseQuotaConfigInAPIProduct>
Elemen Turunan	<Allow> <Interval> <TimeUnit>

Nilai ini dapat ditentukan pada operasi produk API (baik dengan UI maupun API produk API dan dalam kebijakan Kuota. Namun, jika Anda melakukannya, setelan pada produk API didahulukan dan setelan pada Kebijakan kuota akan diabaikan.

Sintaksis untuk elemen ini adalah sebagai berikut:

<UseQuotaConfigInAPIProduct stepName="POLICY_NAME">
  <DefaultConfig>
    <Allow>allow_count</Allow>
    <Interval>interval</Interval>
    <TimeUnit>[minute|hour|day|week|month]</TimeUnit>
  </DefaultConfig>
</UseQuotaConfigInAPIProduct>

Contoh berikut menetapkan kuota 10.000 setiap minggu:

<DefaultConfig>
  <Allow>10000</Allow>
  <Interval>1</Interval>
  <TimeUnit>week</TimeUnit>
</DefaultConfig>

Untuk informasi selengkapnya, lihat referensi berikut:

• Apa yang dimaksud dengan produk API?
• Mengelola produk API

<SharedName>

Mengidentifikasi kebijakan Kuota ini sebagai dibagikan. Semua Kebijakan kuota di proxy API dengan nilai <SharedName> yang sama memiliki penghitung kuota pokok yang sama. Jika elemen ini ada, <EnforceOnly> atau Elemen <CountOnly> juga harus ada.

Untuk informasi lebih lanjut dan contoh, lihat Mengonfigurasi penghitung kuota bersama.

Nilai Default	t/a
Wajib?	Opsional
Jenis	String
Elemen Induk	<Quota>
Elemen Turunan	Tidak ada

<CountOnly>

Menempatkan kebijakan Kuota dengan elemen ini yang ditetapkan ke true dalam langkah kondisional dalam alur respons ProxyEndpoint ke secara kondisional menambah penghitung kuota yang mendasarinya. Jika elemen ini ada, <SharedName> dan elemen <EnforceOnly> juga harus ada.

Untuk informasi lebih lanjut dan contoh, lihat Mengonfigurasi penghitung kuota bersama.

Nilai Default	salah
Wajib?	Opsional
Jenis	Boolean
Elemen Induk	<Quota>
Elemen Turunan	Tidak ada

<EnforceOnly>

Tempatkan kebijakan Kuota dengan elemen ini yang ditetapkan ke true dalam permintaan dari proxy API. Konfigurasi ini memungkinkan pembagian jumlah kuota untuk setiap Kuota kebijakan di proxy API dengan nilai <SharedName> yang sama. Jika elemen ini ada, <SharedName> dan elemen <CountOnly> juga harus ada.

Untuk informasi lebih lanjut dan contoh, lihat Mengonfigurasi penghitung kuota bersama.

Nilai Default	salah
Wajib?	Opsional
Jenis	Boolean
Elemen Induk	<Quota>
Elemen Turunan	Tidak ada

Variabel flow

Variabel Flow yang telah ditetapkan sebelumnya akan otomatis diisi saat kebijakan Kuota akan dijalankan. Untuk mengetahui informasi selengkapnya, lihat Referensi variabel flow.

Variabel	Jenis	Izin	Deskripsi
ratelimit.{policy_name}.allowed.count	Long	Hanya-Baca	Menampilkan jumlah kuota yang diizinkan.
ratelimit.{policy_name}.used.count	Long	Hanya-Baca	Menampilkan kuota saat ini yang digunakan dalam interval kuota.
ratelimit.{policy_name}.available.count	Long	Hanya-Baca	Menampilkan jumlah kuota yang tersedia dalam interval kuota.
ratelimit.{policy_name}.exceed.count	Long	Hanya-Baca	Menampilkan 1 setelah kuota terlampaui.
ratelimit.{policy_name}.total.exceed.count	Long	Hanya-Baca	Menampilkan 1 setelah kuota terlampaui.
ratelimit.{policy_name}.expiry.time	Long	Hanya-Baca	Menampilkan waktu UTC (dalam milidetik), yang menentukan kapan kuota berakhir dan saat interval kuota baru dimulai. Jika jenis kebijakan Kuota adalah rollingwindow, nilai ini tidak valid karena interval kuota tidak memiliki batas waktu.
batas kapasitas.{policy_name}.ID	String	Hanya-Baca	Menampilkan referensi ID (klien) yang dilampirkan ke kebijakan
kapasitas.{policy_name}.class	String	Hanya-Baca	Menampilkan class yang terkait dengan ID klien
ratelimit.{policy_name}.class.allowed.count	Long	Hanya-Baca	Menampilkan jumlah kuota yang diizinkan dan ditentukan di class
ratelimit.{policy_name}.class.used.count	Long	Hanya-Baca	Menampilkan kuota yang telah digunakan dalam class
ratelimit.{policy_name}.class.available.count	Long	Hanya-Baca	Menampilkan jumlah kuota yang tersedia di kelas
ratelimit.{policy_name}.class.exceed.count	Long	Hanya-Baca	Menampilkan jumlah permintaan yang melebihi batas di class dalam interval kuota saat ini
ratelimit.{policy_name}.class.total.exceed.count	Long	Hanya-Baca	Menampilkan jumlah total permintaan yang melebihi batas di class di semua interval kuota, jadi ini adalah jumlah dari class.exceed.count untuk semua interval kuota.
batas kapasitas.{policy_name}.failed	Boolean	Hanya-Baca	Menunjukkan apakah kebijakan gagal atau tidak (benar atau salah).

Referensi error

Bagian ini menjelaskan kode kesalahan dan pesan error yang ditampilkan dan variabel kesalahan yang disetel oleh Apigee saat kebijakan ini memicu error. Informasi ini penting untuk diketahui apakah Anda mengembangkan aturan kesalahan untuk menangani kesalahan. Untuk mempelajari lebih lanjut, lihat Yang perlu Anda ketahui tentang error kebijakan dan Menangani kesalahan.

Error runtime

Error ini dapat terjadi saat kebijakan dieksekusi.

Tips: Perlu bantuan untuk mengatasi error? Klik di kolom Perbaiki untuk mengetahui informasi pemecahan masalah selengkapnya.

Kode kesalahan	Status HTTP	Penyebab	Perbaikan
policies.ratelimit.FailedToResolveQuotaIntervalReference	500	Terjadi jika elemen <Interval> tidak ditentukan dalam kebijakan Quota. Elemen ini bersifat wajib dan digunakan untuk menentukan interval waktu yang berlaku untuk kuota. Interval waktu dapat berupa menit, jam, hari, minggu, atau bulan seperti yang ditentukan dengan elemen <TimeUnit>.
policies.ratelimit.FailedToResolveQuotaIntervalTimeUnitReference	500	Terjadi jika elemen <TimeUnit> tidak ditentukan dalam kebijakan Quota. Elemen ini bersifat wajib dan digunakan untuk menentukan satuan waktu yang berlaku untuk kuota. Interval waktunya dapat dalam menit, jam, hari, minggu, atau bulan.
policies.ratelimit.InvalidMessageWeight	500	Terjadi jika nilai elemen <MessageWeight> yang ditentukan melalui variabel flow tidak valid (nilai non-bilangan bulat).
policies.ratelimit.QuotaViolation	500	Batas kuota terlampaui.	T/A

Error saat deployment

Tips: Perlu bantuan untuk mengatasi error? Klik di kolom Perbaiki untuk mengetahui informasi pemecahan masalah selengkapnya.

Nama error	Penyebab	Perbaikan
InvalidQuotaInterval	Jika interval kuota yang ditentukan dalam elemen <Interval> bukan bilangan bulat, deployment proxy API akan gagal. Misalnya, jika interval kuota yang ditentukan adalah 0,1 dalam elemen <Interval>, deployment proxy API akan gagal.
InvalidQuotaTimeUnit	Jika unit waktu yang ditentukan dalam elemen <TimeUnit> tidak didukung, deployment proxy API akan gagal. Satuan waktu yang didukung adalah minute, hour, day, week, dan month.
InvalidQuotaType	Jika jenis kuota yang ditentukan oleh atribut type di elemen <Quota> tidak valid, deployment proxy API akan gagal. Jenis kuota yang didukung adalah default, calendar, flexi, dan rollingwindow.
InvalidStartTime	Jika format waktu yang ditentukan dalam elemen <StartTime> tidak valid, deployment proxy API akan gagal. Format yang valid adalah yyyy-MM-dd HH:mm:ss, yang merupakan format tanggal dan waktu ISO 8601. Misalnya, jika waktu yang ditetapkan dalam elemen <StartTime> adalah 7-16-2017 12:00:00, deployment proxy API akan gagal.
StartTimeNotSupported	Jika elemen <StartTime> ditentukan yang jenis kuotanya bukan jenis calendar, deployment proxy API akan gagal. Elemen <StartTime> hanya didukung untuk jenis kuota calendar. Misalnya, jika atribut type ditetapkan ke flexi atau rolling window dalam elemen <Quota>, deployment proxy API akan gagal.
InvalidTimeUnitForDistributedQuota	Jika elemen <Distributed> disetel ke true dan elemen <TimeUnit> disetel ke second, deployment proxy API akan gagal. Unit waktu second tidak valid untuk kuota yang didistribusikan.
InvalidSynchronizeIntervalForAsyncConfiguration	Jika nilai yang ditentukan untuk elemen <SyncIntervalInSeconds> dalam elemen <AsynchronousConfiguration> di kebijakan Quota kurang dari nol, maka deployment proxy API akan gagal.
InvalidAsynchronizeConfigurationForSynchronousQuota	Jika nilai elemen <AsynchronousConfiguration> disetel ke true dalam kebijakan Quota, yang juga memiliki konfigurasi asinkron yang ditetapkan menggunakan elemen <AsynchronousConfiguration>, deployment proxy API akan gagal.

Variabel kesalahan

Variabel ini ditetapkan saat kebijakan ini memicu error. Untuk informasi selengkapnya, lihat Yang perlu Anda ketahui tentang error kebijakan.

Variabel	Dari mana	Contoh
fault.name="fault_name"	fault_name adalah nama kesalahan, seperti yang tercantum dalam tabel Error runtime di atas. Nama kesalahan adalah bagian terakhir dari kode kesalahan.	fault.name Matches "QuotaViolation"
ratelimit.policy_name.failed	policy_name adalah nama kebijakan yang ditentukan pengguna yang menampilkan kesalahan.	ratelimit.QT-QuotaPolicy.failed = true

Contoh respons error

Catatan: Untuk penanganan error, praktik terbaiknya adalah menjebak bagian errorcode dari respons error. Jangan mengandalkan teks di faultstring, karena bisa berubah.

{  
   "fault":{  
      "detail":{  
         "errorcode":"policies.ratelimit.QuotaViolation"
      },
      "faultstring":"Rate limit quota violation. Quota limit  exceeded. Identifier : _default"
   }
}

Contoh aturan kesalahan

<FaultRules>
    <FaultRule name="Quota Errors">
        <Step>
            <Name>JavaScript-1</Name>
            <Condition>(fault.name Matches "QuotaViolation") </Condition>
        </Step>
        <Condition>ratelimit.Quota-1.failed=true</Condition>
    </FaultRule>
</FaultRules>

Catatan: Saat ini, kebijakan Kuota menampilkan kode status 500 jika menerapkan batas kapasitas. Jika Anda menggunakan layanan yang dikelola Apigee, dan Anda ingin Pengembalian kebijakan Kuota Anda 429, hubungi Google Cloud Customer Care. agar properti features.isHTTPStatusTooManyRequestEnabled diaktifkan. Lihat HTTP 429 sebagai kode status default untuk pelanggaran kebijakan Kuota untuk mengetahui detail tambahan.

Catatan: Saat memperbarui properti, Anda harus meneruskan semua properti yang ada ke API, bahkan jika mereka tidak diubah. Jika Anda menghilangkan properti dalam payload, properti akan dihapus.

curl -u email:password -X POST -H "Content-type:application/xml" \
  http://LOAD_BALANCER_IP:8080/v1/o/myorg \
  -d '<Organization type="trial" name="MyOrganization">
    <DisplayName>MyOrganization</DisplayName>
    <Environments/>
    <Properties>
        <Property name="features.isHTTPStatusTooManyRequestEnabled">true</Property>
    </Properties>
  </Organization>'

Skema

Contoh: Lihat GitHub repositori untuk skema terbaru.

Topik terkait

Kebijakan ResetQuota

Kebijakan SpikeArrest

Membandingkan Kebijakan Pembatasan Kuota dan Lonjakan