Halaman ini diterjemahkan oleh Cloud Translation API.

Referensi konfigurasi proxy API

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

Sebagai developer yang bekerja dengan Apigee, aktivitas pengembangan utama Anda melibatkan mengonfigurasi proxy API yang berfungsi sebagai proxy untuk API atau layanan backend. Dokumen ini adalah yang merupakan referensi dari semua elemen konfigurasi yang tersedia untuk Anda saat membuat proxy API.

Jika Anda mempelajari cara membangun proxy API, sebaiknya Anda memulai dengan topik Membangun API sederhana proxy.

Edit konfigurasi proxy API Anda menggunakan salah satu metode berikut:

Gunakan UI Apigee atau API.
Download paket konfigurasi proxy API, edit secara manual, lalu upload konfigurasi baru ke Apigee, seperti yang dijelaskan di Mendownload dan mengupload paket konfigurasi proxy API.

Struktur direktori konfigurasi proxy API

Struktur direktori konfigurasi proxy API ditampilkan di bawah ini:

Menampilkan struktur direktori tempat apiproxy adalah root. Tepat di bawah
direktori apiproxy adalah direktori kebijakan, proxy, sumber daya, dan target, serta
{i>weatherapi.xml<i}.

Konfigurasi proxy API terdiri dari konten berikut:

Konfigurasi dasar	Setelan konfigurasi utama untuk proxy API.
ProxyEndpoint	Setelan untuk koneksi HTTP masuk (dari meminta aplikasi ke Apigee), meminta alur respons, dan lampiran kebijakan.
TargetEndpoint	Setelan untuk koneksi HTTP keluar (dari Apigee ke layanan backend), alur permintaan dan respons, serta lampiran kebijakan.
Alur	Pipeline permintaan dan respons ProxyEndpoint dan TargetEndpoint yang dapat menerapkan kebijakan terlampir.
Kebijakan	File konfigurasi berformat XML yang sesuai dengan skema kebijakan Apigee.
Resource	Skrip, file JAR, dan file XSLT yang dirujuk oleh kebijakan untuk menjalankan logika kustom.

Konfigurasi dasar

`/apiproxy/weatherapi.xml`

Konfigurasi dasar untuk proxy API, yang menentukan nama proxy API. Nama harus unik dalam suatu organisasi.

Contoh konfigurasi:

<APIProxy name="weatherapi">
</APIProxy>

Elemen konfigurasi dasar

Nama	Deskripsi	Default	Wajib?
`APIProxy`
`name`	Nama proxy API yang harus unik dalam suatu organisasi. Karakter ini yang boleh Anda gunakan dalam nama dibatasi untuk hal-hal berikut: `A-Za-z0-9_-`	T/A	Ya
`revision`	Nomor revisi konfigurasi proxy API. Anda tidak perlu secara eksplisit mengatur nomor revisi, karena Apigee secara otomatis melacak revisi API saat ini {i>proxy<i}.	T/A	Tidak
`ConfigurationVersion`	Versi skema konfigurasi proxy API yang sesuai dengan proxy API ini. Tujuan satu-satunya nilai yang didukung saat ini adalah mainVersion 4 dan minorVersion 0. Setelan ini mungkin yang digunakan di masa mendatang untuk memungkinkan evolusi format proxy API.	4.0	Tidak
`Description`	Deskripsi tekstual proxy API. Jika disediakan, deskripsi akan ditampilkan di UI Apigee.	T/A	Tidak
`DisplayName`	Nama yang mudah digunakan yang mungkin berbeda dari atribut `name` konfigurasi proxy API.	T/A	Tidak
`Policies`	Daftar kebijakan dalam direktori `/policies` proxy API ini. Anda akan biasanya hanya melihat elemen ini saat proxy API dibuat menggunakan UI Apigee. Ini hanyalah setelan manifes, yang dirancang untuk memberikan visibilitas ke isi proxy API.	T/A	Tidak
`ProxyEndpoints`	Daftar endpoint proxy dalam direktori `/proxies` proxy API ini. Anda biasanya hanya akan melihat elemen ini saat proxy API dibuat menggunakan Apigee UI. Ini hanyalah setelan manifes, yang dirancang untuk memberikan visibilitas ke isi proxy API.	T/A	Tidak
`Resources`	Daftar resource (JavaScript, Python, Java, XSLT) di `/resources` dari proxy API ini. Biasanya Anda hanya akan melihat elemen ini ketika proxy API yang dibuat menggunakan UI Apigee. Ini hanyalah setelan manifes, yang dirancang untuk memberikan visibilitas ke konten proxy API.	T/A	Tidak
`Spec`	Mengidentifikasi Spesifikasi OpenAPI yang terkait dengan proxy API. Nilainya ditetapkan ke URL atau jalur di penyimpanan spesifikasi.	T/A	Tidak
`TargetServers`	Daftar server target yang dirujuk di endpoint target mana pun dari proxy API ini. Anda akan biasanya hanya melihat elemen ini saat proxy API dibuat menggunakan Apigee. Ini hanyalah setelan manifes, yang dirancang untuk memberikan visibilitas ke isi proxy API.	T/A	Tidak
`TargetEndpoints`	Daftar endpoint target dalam direktori `/targets` proxy API ini. Anda biasanya hanya akan melihat elemen ini saat proxy API dibuat menggunakan UI Apigee. Ini hanyalah setelan manifes, yang dirancang untuk memberikan visibilitas ke isi proxy API.	T/A	Tidak

ProxyEndpoint

Gambar berikut menunjukkan alur permintaan/respons:

Menunjukkan klien yang memanggil HTTP
layanan. Permintaan melewati titik akhir {i>proxy<i}
dan kemudian titik akhir target sebelum
yang diproses oleh layanan HTTP. Respons melewati endpoint target dan kemudian
endpoint proxy sebelum dikembalikan ke klien.

`/apiproxy/proxies/default.xml`

Konfigurasi ProxyEndpoint menentukan antarmuka masuk (dihadap klien) untuk API {i>proxy<i}. Saat mengonfigurasi endpoint proxy, Anda sedang menyiapkan konfigurasi jaringan yang menentukan cara aplikasi klien (aplikasi) memanggil API melalui proxy.

Contoh konfigurasi ProxyEndpoint berikut akan disimpan di /apiproxy/proxies:

<ProxyEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
  </HTTPProxyConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

Elemen konfigurasi yang diperlukan di endpoint proxy dasar adalah:

Konfigurasi ProxyEndpoint elemen

Nama Deskripsi Default Wajib?

ProxyEndpoint

name Nama endpoint proxy. Harus unik dalam konfigurasi proxy API, jika (dalam kasus yang jarang terjadi) beberapa endpoint proxy ditentukan. Karakter yang boleh Anda gunakan dalam namanya dibatasi untuk hal berikut: A-Za-z0-9._\-$ %. T/A Ya

PreFlow Menentukan kebijakan dalam alur PreFlow permintaan atau respons. T/A Ya

Flows

Menentukan kebijakan dalam alur bersyarat sebuah permintaan atau respons.

T/A

PostFlow

Menentukan kebijakan dalam alur PostFlow dari permintaan atau respons.

T/A

HTTPProxyConnection Menentukan alamat jaringan dan jalur URI yang terkait dengan proxy API.

BasePath

String wajib yang mengidentifikasi jalur URI secara unik yang digunakan oleh Apigee untuk merutekan pesan masuk ke proxy API yang tepat.

BasePath adalah fragmen URI (misalnya /weather) yang ditambahkan ke URL dasar proxy API (misalnya, http://apifactory-test.apigee.net). BasePath harus unik dalam lingkungan. Keunikan divalidasi ketika proxy API dibuat atau diimpor.

Menggunakan karakter pengganti di jalur dasar

Anda dapat menggunakan satu atau beberapa "*" karakter pengganti di jalur dasar proxy API. Misalnya, basis jalur /team/*/members memungkinkan klien untuk memanggil https://[host]/team/blue/members dan https://[host]/team/green/members tanpa perlu Anda membuat proxy API baru untuk mendukung tim baru. Perhatikan bahwa /**/ tidak didukung.

Penting: Apigee TIDAK mendukung penggunaan karakter pengganti "*" sebagai yang pertama elemen jalur dasar. Misalnya, ini TIDAK didukung: /*/search. Memulai jalur dasar dengan "*" dapat menyebabkan error tak terduga karena cara Apigee mengidentifikasi jalur yang valid.

Properties

Satu set pengaturan konfigurasi HTTP opsional dapat didefinisikan sebagai properti dari <ProxyEndpoint>.

Gunakan properti request.queryparams.ignore.content.type.charset untuk beri tahu proxy untuk mengabaikan parameter charset dari header Content-Type saat memproses URL permintaan. Sebagai contoh:

<Property name= \
"request.queryparams.ignore.content.type.charset">true</>

Tabel berikut menunjukkan contoh output, bergantung pada setelan charset dan keberadaan parameter charset header Content-Type.

Setelan properti	Nilai header	Contoh output
`charset=false`	Parameter `charset` tidak ditetapkan	john.doe+test@gmail.com
`charset=false`	`charset=utf-8`	john.doe tes@gmail.com
`charset=true` dan tidak ada parameter `charset` di header.	Parameter `charset` tidak ditetapkan	john.doe+test@gmail.com
`charset=true`	`charset=utf-8` kumpulan parameter	john.doe+test@gmail.com

T/A

Tidak

FaultRules

Menentukan cara endpoint proxy bereaksi terhadap error. Aturan kesalahan menentukan dua item:

Kondisi yang menentukan kesalahan yang akan ditangani berdasarkan kategori, subkategori, atau nama kesalahan
Satu atau beberapa kebijakan yang mendefinisikan perilaku aturan kesalahan untuk Kondisi yang sesuai

Lihat Menangani kesalahan.

T/A

Tidak

DefaultFaultRule

Menangani error (sistem, transport, pesan, atau kebijakan) yang tidak secara eksplisit ditangani oleh aturan kesalahan lain.

Lihat Menangani kesalahan.

T/A

Tidak

RouteRule Menentukan tujuan pesan permintaan masuk setelah diproses oleh Pipeline permintaan ProxyEndpoint. Biasanya, RouteRule menunjuk ke titik akhir target yang telah diberi nama, IntegrationEndpoint, atau URL.

Name Atribut wajib, yang memberikan nama untuk RouteRule. Karakter yang digunakan dalam nama dibatasi untuk hal berikut: A-Za-z0-9._\-$ %. Sebagai contoh, Cat2 %_ adalah nama resmi. T/A Ya

Condition Pernyataan kondisional opsional yang digunakan untuk perutean dinamis saat runtime. Bersyarat RouteRules berguna, misalnya, untuk mengaktifkan perutean berbasis konten guna mendukung backend pembuatan versi. T/A Tidak

TargetEndpoint

String opsional yang mengidentifikasi konfigurasi TargetEndpoint bernama. Nama endpoint target adalah endpoint target apa pun yang ditentukan dalam proxy API yang sama di direktori /targets).

Dengan menamai endpoint target, Anda menunjukkan tempat pesan permintaan harus diteruskan setelah diproses oleh pipeline permintaan ProxyEndpoint. Perhatikan bahwa ini adalah deskripsi tempat.

Endpoint proxy dapat memanggil URL secara langsung. Misalnya, resource JavaScript atau Java, berfungsi dalam peran klien HTTP, dapat melakukan tugas dasar dari endpoint target, yaitu meneruskan permintaan ke layanan backend.

T/A

Tidak

URL String opsional yang menentukan alamat jaringan keluar yang dipanggil oleh endpoint proxy, yang mengabaikan konfigurasi TargetEndpoint apa pun yang mungkin disimpan /targets T/A Tidak

Cara mengonfigurasi RouteRules

Endpoint target bernama merujuk pada file konfigurasi di /apiproxy/targets untuk yang merupakan {i> RouteRule <i}meneruskan permintaan setelah diproses oleh titik akhir {i>proxy<i}.

Misalnya, RouteRule berikut mengacu pada konfigurasi /apiproxy/targets/myTarget.xml:

<RouteRule name="default">
  <TargetEndpoint>myTarget</TargetEndpoint>
</RouteRule>

Pemanggilan URL langsung

Endpoint proxy juga dapat langsung memanggil layanan backend. Pemanggilan URL langsung mengabaikan bernama konfigurasi TargetEndpoint di bagian /apiproxy/targets). Karena alasan ini, TargetEndpoint adalah konfigurasi proxy API opsional, meskipun dalam praktiknya, pemanggilan langsung dari endpoint proxy tidak disarankan.

Misalnya, RouteRule berikut membuat panggilan HTTP ke http://api.mycompany.com/v2.

<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL> 
</RouteRule>

Rute bersyarat

RouteRules dapat dirantai untuk mendukung perutean dinamis saat runtime. Permintaan masuk dapat dirutekan ke konfigurasi TargetEndpoint bernama, langsung ke URL, atau ke kombinasi keduanya, berdasarkan header HTTP, isi pesan, parameter kueri, atau informasi kontekstual seperti hari, lokalitas, dll.

RouteRules berfungsi seperti pernyataan kondisional lainnya di Apigee. Lihat Referensi kondisi dan Referensi variabel flow.

Misalnya, kombinasi RouteRule berikut terlebih dahulu mengevaluasi permintaan masuk untuk diverifikasi nilai header HTTP. Jika header HTTP routeTo memiliki nilai TargetEndpoint1, lalu permintaan diteruskan ke endpoint target yang bernama TargetEndpoint1. Jika tidak, permintaan masuk akan diteruskan ke http://api.mycompany.com/v2.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

Rute null

RouteRule null dapat ditentukan untuk mendukung skenario jika pesan permintaan tidak harus diteruskan ke endpoint target. Ini berguna ketika titik akhir {i>proxy<i} menjalankan semua pemrosesan yang diperlukan, misalnya dengan menggunakan JavaScript untuk memanggil layanan eksternal atau mengambil data dari pencarian ke penyimpanan kunci/nilai Apigee.

Misalnya, hal berikut menentukan Rute null:

<RouteRule name="GoNowhere"/>

Rute null bersyarat dapat berguna. Pada contoh berikut, Rute {i>null<i} dikonfigurasi untuk dijalankan saat header HTTP request.header.X-DoNothing memiliki nilai selain null.

<RouteRule name="DoNothingOnDemand">
  <Condition>request.header.X-DoNothing != null</Condition>
</RouteRule>

Ingat, RouteRules dapat dirantai, sehingga Rute null kondisional biasanya adalah satu dari kumpulan RouteRules yang dirancang untuk mendukung perutean bersyarat.

Penggunaan praktis Rute null bersyarat akan mendukung caching. Dengan menggunakan nilai untuk variabel yang disetel oleh kebijakan Cache, Anda dapat mengonfigurasi proxy API untuk menjalankan Rute null saat entri disajikan dari cache.

<RouteRule name="DoNothingUnlessTheCacheIsStale">
  <Condition>lookupcache.LookupCache-1.cachehit is true</Condition>
</RouteRule>

TargetEndpoint

Endpoint target adalah endpoint yang setara dengan endpoint proxy. Endpoint target berfungsi sebagai klien ke layanan backend atau API—aplikasi ini mengirimkan permintaan dan menerima respons.

Proxy API tidak perlu memiliki endpoint target. Endpoint proxy dapat dikonfigurasi untuk memanggil URL secara langsung. Proxy API tanpa endpoint target biasanya berisi endpoint proxy yang layanan backend, atau yang dikonfigurasi untuk memanggil layanan menggunakan Java atau pada JavaScript.

Konfigurasi TargetEndpoint

`/targets/default.xml`

Endpoint target menentukan koneksi keluar dari Apigee ke layanan lain atau resource Anda

Berikut adalah contoh konfigurasi TargetEndpoint:

<TargetEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <SSLInfo/>
    <Authentication/>
  </HTTPTargetConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <ScriptTarget/>
  <LocalTargetConnection/>
</TargetEndpoint>

Konfigurasi TargetEndpoint elemen

Endpoint target dapat memanggil target dengan salah satu cara berikut:

HTTPTargetConnection untuk panggilan HTTP atau HTTPS
LocalTargetConnection untuk rantai proxy-ke-proxy lokal

Hanya konfigurasi salah satunya di endpoint target.

Nama	Deskripsi	Default	Wajib?
`TargetEndpoint`
`name`	Nama endpoint target, yang harus unik dalam proxy API konfigurasi Anda. Nama endpoint target digunakan dalam ProxyEndpoint RouteRule untuk permintaan langsung untuk pemrosesan keluar. Karakter yang boleh Anda gunakan dalam nama dibatasi untuk hal berikut: `A-Za-z0-9._\-$ %`.	T/A	Ya
`PreFlow`	Menentukan kebijakan dalam alur PreFlow permintaan atau respons.	T/A	Ya
`Flows`	Menentukan kebijakan dalam alur bersyarat sebuah permintaan atau respons.	T/A	Ya
`PostFlow`	Menentukan kebijakan dalam alur PostFlow dari permintaan atau respons.	T/A	Ya
`HTTPTargetConnection`	Dengan elemen turunannya, menentukan resource backend yang dijangkau melalui HTTP. Jika Anda menggunakan HTTPTargetConnection, jangan konfigurasi jenis koneksi target lainnya (ScriptTarget atau LocalTargetConnection). Catatan: Elemen `<LocalTargetConnection>` mendukung fitur substitusi string dinamis yang disebut penandaan pesan. Anda dapat menggunakan elemen turunan `<Authentication>` untuk melakukan panggilan terautentikasi ke layanan Google atau layanan khusus yang sedang berjalan pada produk Google Cloud tertentu, seperti Cloud Functions dan Cloud Run. Penggunaan elemen `<Authentication>` memerlukan langkah-langkah penyiapan dan deployment yang dijelaskan di Menggunakan autentikasi Google. Dengan penyiapan yang tepat, kebijakan tersebut akan membuat token autentikasi untuk Anda dan menambahkannya ke permintaan layanan. Lihat juga Penggunaan elemen `<Authentication>`.
`URL`	Menentukan alamat jaringan layanan backend yang menjadi tujuan penerusan endpoint target pesan permintaan.	T/A	Tidak
`LoadBalancer`	Menentukan satu atau beberapa konfigurasi TargetServer yang bernama. TargetServer Bernama konfigurasi dapat digunakan untuk load balancing yang menentukan 2 konfigurasi endpoint atau lebih koneksi jarak jauh. Anda juga bisa menggunakan server target untuk memisahkan konfigurasi proxy API dari konkret URL endpoint layanan backend.	T/A	Tidak
`Properties`	Satu set pengaturan konfigurasi HTTP opsional dapat didefinisikan sebagai properti dari `<TargetEndpoint>`.	T/A	Tidak
`SSLInfo`	(Opsional) Tentukan setelan TLS/SSL pada endpoint target untuk mengontrol TLS/SSL koneksi antara proxy API dan layanan target. Lihat Konfigurasi TargetEndpoint TLS/SSL. Catatan: Elemen `<SSLInfo>` mendukung fitur substitusi string dinamis yang disebut penandaan pesan.	T/A	Tidak
`LocalTargetConnection`	Dengan elemen turunannya, menentukan resource yang akan dijangkau secara lokal, melewati jaringan seperti load balancing dan pemroses pesan. Untuk menetapkan sumber daya target, sertakan salah satu elemen turunan APIProxy (dengan elemen ProxyEndpoint ) atau elemen turunan Path. Untuk informasi selengkapnya, lihat Proxy rantai API bersama-sama. Jika Anda menggunakan LocalTargetConnection, jangan konfigurasi jenis koneksi target lainnya (HTTPTargetConnection atau ScriptTarget).
`APIProxy`	Menentukan nama proxy API yang akan digunakan sebagai target permintaan. Proxy target harus berada dalam organisasi dan lingkungan yang sama dengan permintaan pengiriman proxy. Ini adalah alternatif untuk menggunakan elemen Path.	T/A	Tidak
`ProxyEndpoint`	Digunakan dengan APIProxy untuk menentukan nama endpoint proxy proxy target.	T/A	Tidak
`Path`	Menentukan jalur endpoint proxy API yang akan digunakan sebagai target untuk permintaan. Target proxy harus berada dalam organisasi dan lingkungan yang sama dengan permintaan pengiriman proxy. Ini adalah alternatif untuk menggunakan APIProxy.	T/A	Tidak
`FaultRules`	Menentukan bagaimana endpoint target bereaksi terhadap error. Aturan kesalahan menentukan dua item: Kondisi yang menentukan kesalahan yang akan ditangani berdasarkan kategori, subkategori, atau nama kesalahan Satu atau beberapa kebijakan yang mendefinisikan perilaku aturan kesalahan untuk Kondisi yang sesuai Lihat Menangani kesalahan.	T/A	Tidak
`DefaultFaultRule`	Menangani error (sistem, transport, pesan, atau kebijakan) yang tidak secara eksplisit ditangani oleh {i>FaultRule<i} lainnya. Lihat Menangani kesalahan.	T/A	Tidak

Penggunaan elemen `<Authentication>`

Penggunaan elemen <Authentication> di <TargetEndpoint> identik dengan penggunaan dari elemen <Authentication> dalam Kebijakan ServiceInfo. Di <TargetEndpoint> dan ServiceKeterangan, <Authentication> adalah subelemen dari <HttpTargetConnection>. Untuk mengetahui detailnya, lihat Elemen Authentication di referensi kebijakan ServiceInfo.

Referensi error elemen `<Authentication>`

Jika menggunakan elemen <Authentication>, Anda dapat menemukan kemungkinan pesan error dan pemecahan masalah tips untuk deployment dan error runtime di bagian Error dokumentasi kebijakan ServiceInfo.

Contoh elemen `<Authentication>`

Contoh berikut menunjukkan cara memanggil layanan yang di-deploy di Cloud Run sebagai target menggunakan elemen Authentication untuk menghasilkan token OpenID Connect yang diperlukan untuk mengautentikasi panggilan tersebut:

<TargetEndpoint name="TargetEndpoint-1">
  <HTTPTargetConnection>
      <Properties/>
      <URL>https://cloudrun-hostname.a.run.app/test</URL>
      <Authentication>
          <GoogleIDToken>
             <Audience>https://cloudrun-hostname.a.run.app/test</Audience>
          </GoogleIDToken>
     </Authentication>
  </HTTPTargetConnection>
</TargetEndpoint>

Contoh berikut menunjukkan cara memanggil TargetService yang mengarah ke Cloud Run menggunakan elemen Authentication untuk menghasilkan token OpenID Connect yang diperlukan untuk mengautentikasi melakukan panggilan. Elemen HeaderName menambahkan token pemilik yang dihasilkan ke header bernama X-Serverless-Authorization yang dikirim ke sistem target. Header Authorization, jika ada, tidak akan diubah dan juga dikirim dalam permintaan.

<TargetEndpoint name="TargetEndpoint-1">
   <HTTPTargetConnection>
     <Authentication>
        <HeaderName>X-Serverless-Authorization</HeaderName>
        <GoogleIDToken>
            <Audience ref="flow.variable.audience">https://cloudrun-hostname.a.run.app</Audience>
        </GoogleIDToken>
     </Authentication>
      <LoadBalancer>
         <Server name="cloud-run-target" />
      </LoadBalancer>
   </HTTPTargetConnection>
</TargetEndpoint>

Contoh berikut menunjukkan cara memanggil TargetService yang mengarah ke Secret Manager. Dalam contoh ini, elemen GoogleAccessToken dikonfigurasi untuk membuat Token Google Auth untuk mengautentikasi permintaan target:

<HTTPTargetConnection>
   <Authentication>
      <GoogleAccessToken>
        <Scopes>
          <Scope>https://www.googleapis.com/auth/cloud-platform</Scope>
        </Scopes>
      </GoogleAccessToken>
    </Authentication>
    <URL>
      https://secretmanager.googleapis.com/v1/projects/project-id/secrets/secret-id
    </URL>
</HTTPTargetConnection>

Contoh berikut menunjukkan cara menetapkan audiens GoogleIDToken secara otomatis. Kapan useTargetUrl adalah true dan variabel yang direferensikan tidak di-resolve menjadi variabel yang valid, URL target (tidak termasuk parameter kueri) akan digunakan sebagai audiens. Misalkan jalur permintaannya adalah /foobar dan URL server target adalah https://xyz.com, audiens GoogleIDToken akan otomatis disetel ke https://xyz.com/foobar.

Pengguna Apigee Hybrid: Jika Anda menggunakan Apigee Hybrid, perhatikan bahwa atribut useTargetUrl tersedia di Apigee hybrid versi 1.8 dan versi yang lebih baru.

<TargetEndpoint name="TargetEndpoint-1">
  <HTTPTargetConnection>
    <Authentication>
      <GoogleIDToken>
        <Audience ref='myvariable' useTargetUrl="true"/>
      </GoogleIDToken>
    </Authentication>
    <LoadBalancer>
      <Server name="TS" />
    </LoadBalancer>
  </HTTPTargetConnection>
</TargetEndpoint>

Konfigurasi TargetEndpoint TLS/SSL

Endpoint target sering kali harus mengelola koneksi HTTPS dengan backend yang heterogen infrastruktur IT. Karena alasan ini, sejumlah setelan konfigurasi TLS/SSL didukung.

TLS/SSL Elemen konfigurasi TargetEndpoint

Nama	Deskripsi	Default	Wajib?
`SSLInfo`	Blok `<SSLInfo>` dapat digunakan untuk TLS/SSL satu arah dan dua arah.
`Enabled`	Jika ditetapkan ke `true`, `<Enabled>` menentukan bahwa blok `<SSLInfo>` harus digunakan. Jika ditetapkan ke `false`, blok `<SSLInfo>` akan diabaikan. Nilai default `<Enabled>` adalah `true` jika `<URL>` menentukan protokol HTTPS, dan `false` jika `<URL>` menentukan HTTP.	benar (true) jika `<URL>` menentukan HTTPS	Tidak
`Enforce`	Menerapkan SSL ketat antara Apigee dan backend target. Jika disetel ke `true`, koneksi akan gagal untuk target dengan sertifikat tidak valid, sertifikat yang habis masa berlakunya, sertifikat yang ditandatangani sendiri, sertifikat dengan ketidakcocokan nama host, dan sertifikat dengan root yang tidak tepercaya. J kode kegagalan `4xx` atau `5xx` akan ditampilkan. Jika tidak disetel atau disetel ke `false`, hasil koneksi ke backend target dengan sertifikat yang bermasalah bergantung pada setelan `<IgnoreValidationErrors>` (lihat di bawah). Respons berhasil (`2xx`) dapat terjadi dalam kondisi tertentu, jika `<IgnoreValidationErrors>` disetel ke `true`.	`false`	Tidak
`TrustStore`	Keystore yang berisi sertifikat server root tepercaya. Apigee akan menangani remote peer sebagai tepercaya jika rantai sertifikat yang dikirimnya berakhir di sertifikat yang terdapat dalam keystore ini.	T/A	Tidak
`ClientAuthEnabled`	Jika disetel ke `true`, TLS dua arah akan diaktifkan (juga dikenal sebagai TLS atau mTLS bersama) antara Apigee dan peer jarak jauh - baik klien API maupun backend target. Mengaktifkan TLS dua arah biasanya mengharuskan Anda menyiapkan truststore dan keystore di Apigee.	`false`	Tidak
`KeyStore`	Keystore yang berisi kunci pribadi yang digunakan untuk autentikasi klien keluar	T/A	Ya (jika ClientAuthEnabled benar)
`KeyAlias`	Alias kunci dari kunci pribadi yang digunakan untuk autentikasi klien keluar	T/A	Ya (jika ClientAuthEnabled benar)
`IgnoreValidationErrors`	Menunjukkan apakah error validasi diabaikan. Jika sistem backend menggunakan SNI dan menampilkan sertifikat dengan Nama yang Dibedakan (DN) subjek yang tidak cocok dengan nama host, tidak ada cara untuk mengabaikan {i>error<i} dan koneksi gagal. Catatan: Jika `<Enforce>` disetel ke `true`, nilai `<IgnoreValidationErrors>` diabaikan.	`false`	Tidak
`Ciphers`	Cipher yang didukung untuk TLS/SSL keluar. Jika tidak ada penyandian yang ditentukan, maka semua penyandian yang tersedia untuk JVM akan diizinkan. Untuk membatasi cipher, tambahkan elemen berikut yang mencantumkan cipher yang didukung: <Ciphers> <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher> <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher> </Ciphers>	T/A	Tidak
`Protocols`	Protokol yang didukung untuk TLS/SSL keluar. Jika tidak ada protokol yang ditentukan, maka semua protokol yang tersedia untuk JVM akan diizinkan. Untuk membatasi protokol, tentukan secara eksplisit. Misalnya, untuk hanya mengizinkan TLS v1.2 atau TLS v1.3: <Protocols> <Protocol>TLSv1.2</Protocol> <Protocol>TLSv1.3</Protocol> </Protocols>	T/A	Tidak
`CommonName`	Apigee memeriksa nilai di sini berdasarkan CN (Nama Umum) atau SAN (Nama Alternatif Subjek) pada sertifikat peer jarak jauh.	T/A	Tidak

Contoh endpoint target dengan autentikasi klien keluar diaktifkan

<TargetEndpoint name="default">
  <HttpTargetConnection>
        <URL>https://myservice.com</URL>
    <SSLInfo>
      <Enabled>true</Enabled>
      <Enforce>true</Enforce>
      <ClientAuthEnabled>true</ClientAuthEnabled>
      <KeyStore>myKeystore</KeyStore>
      <KeyAlias>myKey</KeyAlias>
      <TrustStore>myTruststore</TrustStore>
    </SSLInfo>
  </HttpTargetConnection>
</TargetEndpoint>

Untuk petunjuk terperinci, lihat Opsi untuk mengonfigurasi TLS.

Menggunakan variabel flow untuk menetapkan nilai TLS/SSL secara dinamis

Anda juga dapat menetapkan detail TLS/SSL secara dinamis untuk mendukung persyaratan runtime yang fleksibel. Misalnya, jika proxy Anda terhubung ke dua target yang berpotensi berbeda (target pengujian dan target produksi), Anda bisa membuat proxy API secara terprogram mendeteksi lingkungan dan secara dinamis menetapkan referensi ke keystore dan truststore yang sesuai. Tujuan SSLInfo dinamis untuk TargetEndpoint menggunakan referensi variabel Artikel Komunitas Apigee menjelaskan skenario ini secara lebih mendetail dan menyediakan API yang dapat di-deploy contoh proxy.

Pada contoh berikut tentang cara tag <SSLInfo> akan ditetapkan dalam Dengan konfigurasi TargetEndpoint, nilai dapat diberikan saat runtime, misalnya, oleh aplikasi Info, kebijakan JavaScript, atau kebijakan MenetapkanMessage. Gunakan variabel pesan mana pun berisi nilai-nilai yang ingin Anda tetapkan.

Variabel hanya diizinkan pada elemen berikut.

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled>
    <KeyStore>{myvars.ssl.keystore}</KeyStore>
    <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias>
    <TrustStore>{myvars.ssl.trustStore}</TrustStore>
</SSLInfo>

Menggunakan referensi untuk menetapkan nilai TLS/SSL secara dinamis

Saat mengonfigurasi endpoint target yang menggunakan HTTPS, Anda harus mempertimbangkan kasus saat Masa berlaku sertifikat TLS/SSL telah berakhir, atau perubahan pada konfigurasi sistem mengharuskan Anda untuk memperbarui sertifikat.

Untuk informasi selengkapnya, lihat Menangani sertifikat yang sudah tidak berlaku.

Namun, Anda dapat mengonfigurasi endpoint target secara opsional untuk menggunakan referensi ke keystore atau truststore sebagai gantinya. Keuntungan menggunakan referensi adalah Anda dapat memperbarui referensi agar mengarah ke keystore atau truststore yang berbeda untuk memperbarui sertifikat TLS/SSL tanpa harus memulai ulang {i>Message Processor<i}.

Misalnya, ditunjukkan di bawah ini adalah endpoint target yang menggunakan referensi ke keystore:

<SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>false</ClientAuthEnabled>
  <KeyStore>ref://keystoreref</KeyStore>
  <KeyAlias>myKeyAlias</KeyAlias>
</SSLInfo>

Gunakan panggilan POST API berikut untuk membuat referensi bernama keystoreref:

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references" \
  -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>'

Jika $TOKEN ditetapkan ke token akses OAuth 2.0 Anda, seperti yang dijelaskan di Mendapatkan token akses OAuth 2.0. Untuk mengetahui informasi tentang opsi curl yang digunakan dalam contoh ini, lihat Menggunakan curl. Untuk deskripsi tentang variabel lingkungan yang digunakan, lihat Menetapkan variabel lingkungan untuk permintaan API Apigee.

Referensi menentukan nama keystore dan jenisnya.

Gunakan panggilan GET API berikut untuk melihat referensi:

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -H "Authorization: Bearer $TOKEN"

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -H "Authorization: Bearer $TOKEN"

Untuk mengubah referensi di lain waktu agar mengarah ke keystore yang berbeda, pastikan alias memiliki dengan nama yang sama, gunakan panggilan PUT berikut:

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -X PUT \
  -H "Authorization: Bearer $TOKEN" \
  -d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
  </ResourceReference>'

TargetEndpoint dengan load balancing target

Endpoint target mendukung load balancing di beberapa server target yang diberi nama menggunakan tiga beban algoritma balancing.

Untuk petunjuk terperinci, lihat Load balancing di seluruh server backend.

IntegrationEndpoint

IntegrationEndpoint adalah endpoint target yang secara khusus menjalankan integrasi Apigee. Jika Anda telah mengonfigurasi IntegrationEndpoint, Apigee mengirimkan objek request ke Platform Integrasi Apigee untuk dieksekusi. Untuk menjalankan integrasi Anda, selain mengonfigurasi IntegrationEndpoint, Anda juga harus menambahkan kebijakan SetIntegrationRequest di alur proxy Anda.

Anda dapat mengonfigurasi integrasi untuk dijalankan secara sinkron atau asinkron dengan menetapkan elemen <AsyncExecution> dalam konfigurasi IntegrationEndpoint. Untuk mengetahui informasi selengkapnya, lihat Eksekusi sinkron vs. Asinkron. Setelah menjalankan integrasi, Apigee menyimpan respons dalam pesan respons.

Catatan: Anda memerlukan token autentikasi untuk menjalankan IntegrationEndpoint. Namun, tidak ada elemen <Authentication> eksplisit di IntegrationEndpoint definisi. Apigee menambahkan token autentikasi ke permintaan di balik layar. Untuk IntegrationEndpoint agar berhasil mengautentikasi, Anda harus men-deploy proxy API dengan akun layanan yang memiliki peran IAM yang diperlukan untuk menjalankan integrasi. Untuk informasi terkait peran yang diperlukan, lihat Peran IAM untuk integrasi. Untuk mengetahui detail selengkapnya tentang men-deploy proxy API, lihat Men-deploy di Apigee.

Mengonfigurasi IntegrationEndpoint

Untuk mengonfigurasi endpoint integrasi sebagai endpoint target Anda, tambahkan IntegrationEndpoint ke konfigurasi ProxyEndpoint Anda. Berikut adalah contoh konfigurasi ProxyEndpoint:

<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>my-set-integration-request-policy</Name>
            </Step>
        </Request>
    </PreFlow>
    <Flows/>
    <PostFlow name="PostFlow"/>
    <HTTPProxyConnection>
        <BasePath>/integration-endpoint-test</BasePath>
        <Properties/>
    </HTTPProxyConnection>
    <RouteRule name="default">
        <IntegrationEndpoint>my-int-endpoint</IntegrationEndpoint>
    </RouteRule>
</ProxyEndpoint>

Dalam contoh konfigurasi ProxyEndpoint, Apigee melakukan tugas berikut:

Di PreFlow, jalankan kebijakan bernama my-set-integration-request-policy, yang menetapkan objek permintaan integrasi dan variabel alur integrasi.
Menggunakan my-int-endpoint sebagai endpoint target, seperti yang ditentukan dalam RouteRule.
Membaca objek permintaan integrasi yang dibuat oleh my-set-integration-request-policy.
Mengirim permintaan ke Integration Platform Apigee menggunakan objek permintaan dan variabel alur yang ditetapkan oleh kebijakan SetIntegrationRequest.
Menyimpan respons integrasi dalam pesan respons.

File XML yang berisi deklarasi <IntegrationEndpoint> akan tersedia di direktori APIGEE_BUNDLE_DIRECTORY/apiproxy/integration-endpoints/. Jika Anda membuat proxy API menggunakan opsi Develop > API Proxies > CREATE NEW > Integration target, Apigee menyimpan deklarasi dalam file /apiproxy/integration-endpoints/default.xml. Jika Anda Untuk membuat XML endpoint integrasi dari UI, Anda dapat memberikan nama kustom untuk file XML.

Contoh berikut menunjukkan deklarasi elemen <IntegrationEndpoint> dalam file XML:

<IntegrationEndpoint name="my-int-endpoint">
    <AsyncExecution>false</AsyncExecution>
</IntegrationEndpoint>

Elemen konfigurasi IntegrationEndpoint

Nama	Deskripsi	Default	Wajib?
`IntegrationEndpoint`
`name`	Nama IntegrationEndpoint. Karakter ini yang dapat Anda gunakan dalam nama dibatasi untuk: `A-Za-z0-9._\-$ %`	T/A	Ya
`AsyncExecution`	Nilai Boolean yang menentukan apakah integrasi harus dijalankan dalam mode sinkron atau asinkron. Untuk mengetahui informasi selengkapnya, lihat Eksekusi sinkron vs. Asinkron.	salah	Tidak

Eksekusi Sinkron vs Asinkron

Anda dapat mengonfigurasi integrasi untuk berjalan dalam mode sinkron atau asinkron. Untuk memahami perbedaan antara mode eksekusi sinkron dan asinkron, lihat <AsyncExecution>.

Gunakan elemen <AsyncExecution> dalam </IntegrationEndpoint> untuk menentukan eksekusi sinkron atau asinkron. Jika Anda menetapkan <AsyncExecution> ke true, integrasi akan berjalan secara asinkron. Dan jika Anda Tetapkan ke false, integrasi akan berjalan secara sinkron.

Contoh berikut menetapkan AsyncExecution ke true:

<IntegrationEndpoint name="my-int-endpoint">
    <AsyncExecution>true</AsyncExecution>
</IntegrationEndpoint>

Kebijakan

Direktori /policies dalam proxy API berisi semua kebijakan yang tersedia untuk yang dikaitkan dengan Flows di proxy API.

Elemen konfigurasi kebijakan

Nama	Deskripsi	Default	Wajib?
`Policy`
`name`	Nama internal kebijakan. Karakter yang dapat Anda gunakan dalam nama dibatasi menjadi: `A-Za-z0-9._\-$ %` Namun, UI Apigee memberlakukan tertentu, seperti menghapus karakter yang bukan alfanumerik secara otomatis. Atau, gunakan elemen `<DisplayName>` untuk memberi label pada kebijakan di editor proxy UI Apigee dengan nama natural language yang berbeda.	T/A	Ya
`enabled`	Setel ke `true` untuk menerapkan kebijakan. Setel ke `false` untuk menonaktifkan kebijakan. Kebijakan ini tidak akan ditegakkan meskipun tetap terikat pada alur.	`true`	Tidak
`continueOnError`	Tetapkan ke `false` untuk menampilkan error saat kebijakan gagal. Ini adalah perilaku yang diharapkan untuk sebagian besar kebijakan. Setel ke `true` agar eksekusi alur dapat dilanjutkan bahkan setelah kebijakan gagal.	`false`	Tidak
`async`	Catatan: Atribut ini tidak membuat kebijakan dijalankan secara asinkron. Biasanya, gunakan nilai default `false`. Jika disetel ke `true`, eksekusi kebijakan akan dialihkan ke eksekusi kebijakan yang berbeda sehingga thread utama bebas menangani permintaan tambahan. Saat offline selesai, thread utama kembali dan selesai menangani pesan alur kerja. Dalam beberapa kasus, menetapkan asinkron ke `true` akan meningkatkan proxy API tingkat tinggi. Namun, penggunaan asinkron yang berlebihan dapat mengganggu performa dengan terlalu banyak thread secara manual. Untuk menggunakan perilaku asinkron di proxy API, lihat model objek JavaScript.	`false`	Tidak

Lampiran kebijakan

Gambar berikut menunjukkan urutan eksekusi alur proxy API:

menunjukkan klien memanggil
layanan HTTP. Permintaan bertemu dengan
endpoint proxy dan endpoint target, yang masing-masing berisi langkah-langkah yang memicu kebijakan. Setelah
Layanan HTTP menampilkan respons, respons diproses oleh endpoint target, lalu metode
ProxyEndpoing sebelum dikembalikan ke klien. Sesuai dengan permintaan, respons akan diproses
oleh kebijakan dalam langkah-langkah.

Seperti yang ditunjukkan di atas:

Kebijakan dilampirkan sebagai langkah pemrosesan ke Flow. Nama kebijakan digunakan untuk merujuk ke kebijakan yang akan diterapkan sebagai Langkah pemrosesan. Format lampiran kebijakan adalah hal berikut:

<Step><Name>MyPolicy</Name></Step>

Kebijakan ditegakkan sesuai urutan penerapannya ke Flow. Contoh:

<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>

Konfigurasi lampiran kebijakan elemen

Nama	Deskripsi	Default	Wajib?
`Step`
`Name`	Nama kebijakan yang akan dijalankan oleh definisi Langkah ini.	T/A	Ya
`Condition`	Pernyataan kondisional yang menentukan apakah kebijakan diterapkan atau tidak. Jika kebijakan memiliki kondisi terkait, maka kebijakan hanya dijalankan jika bernilai benar (true).	T/A	Tidak

Alur

ProxyEndpoint dan TargetEndpoint menentukan pipeline untuk pesan permintaan dan respons diproses. Pipeline pemrosesan terdiri dari alur permintaan dan alur respons. Setiap permintaan alur dan alur respons dibagi lagi menjadi PreFlow, satu atau beberapa kondisional opsional atau bernama, dan PostFlow.

PreFlow: Selalu dijalankan. Dijalankan sebelum Flow kondisional.
PostFlow: Selalu dijalankan. Dieksekusi setelah Flow kondisional.

Selain itu, Anda dapat menambahkan PostClientFlow ke endpoint proxy, yang dieksekusi setelah ditampilkan ke aplikasi klien yang meminta. Hanya kebijakan MessageLogging yang dapat disertakan ke alur ini. PostClientFlow mengurangi latensi proxy API dan menyediakan informasi untuk yang tidak dihitung sampai respons dikembalikan ke klien, seperti client.sent.start.timestamp dan client.sent.end.timestamp.Flow digunakan terutama untuk mengukur interval waktu antara stempel waktu awal dan akhir untuk respons untuk membuat pesan email baru.

Berikut adalah contoh PostClientFlow dengan kebijakan logging pesan terlampir.

...
  <PostFlow name="PostFlow">
      <Request/>
      <Response/>
  </PostFlow>
  <PostClientFlow>
      <Request/>
      <Response>
          <Step>
              <Name>Message-Logging-1</Name>
          </Step>
      </Response>
  </PostClientFlow>
  ...

Pipeline pemrosesan proxy API mengeksekusi Flow dalam urutan berikut:

Pipeline Permintaan:

PreFlow Permintaan Proxy
Alur Bersyarat Permintaan Proxy (Opsional)
PostFlow Permintaan Proxy
PreFlow Permintaan Target
Alur Bersyarat Permintaan Target (Opsional)
PostFlow Permintaan Target

Pipeline Respons:

PreFlow Respons Target
Alur Bersyarat Respons Target (Opsional)
PostFlow Respons Target
PreFlow Respons Proxy
Alur Bersyarat Respons Proxy (Opsional)
PostFlow Respons Proxy
Respons PostClientFlow (Opsional)

Hanya Flow dengan lampiran kebijakan yang perlu dikonfigurasi di ProxyEndpoint atau Konfigurasi TargetEndpoint. PreFlow dan PostFlow hanya perlu ditentukan di ProxyEndpoint atau Konfigurasi TargetEndpoint saat kebijakan perlu diterapkan selama PreFlow atau PostFlow diproses.

Berbeda dengan alur bersyarat, urutan elemen PreFlow dan PostFlow tidak penting--proxy API akan selalu mengeksekusi masing-masing pada titik yang sesuai dalam pipeline, terlepas dari tempat munculnya konfigurasi Endpoint.

Alur bersyarat

Endpoint proxy dan endpoint target mendukung alur bersyarat dalam jumlah yang tidak terbatas (juga yang dikenal sebagai alur bernama).

Proxy API menguji kondisi yang ditetapkan dalam alur bersyarat dan, jika kondisi tersebut terpenuhi, langkah pemrosesan dalam alur bersyarat dijalankan oleh proxy API. Jika tidak terpenuhi, maka langkah pemrosesan dalam alur bersyarat akan diabaikan. Bersyarat alur dievaluasi dalam urutan yang ditentukan dalam proxy API dan alur pertama dengan kondisi terpenuhi akan dieksekusi.

Dengan menentukan alur bersyarat, Anda mendapatkan kemampuan untuk menerapkan langkah-langkah pemrosesan di proxy API berdasarkan:

URI Permintaan
Kata kerja HTTP (GET/PUT/POST/DELETE)
Nilai parameter kueri, header, dan parameter formulir
Banyak jenis kondisi lainnya

Misalnya, alur bersyarat berikut menetapkan bahwa itu hanya dieksekusi ketika jalur resource permintaan adalah /accesstoken. Setiap permintaan masuk dengan jalur /accesstoken menyebabkan flow ini dijalankan, bersama dengan semua kebijakan yang melekat pada alur. Jika jalur permintaan tidak menyertakan akhiran /accesstoken, flow tidak akan dieksekusi (meskipun alur bersyarat lainnya ).

<Flows>
  <Flow name="TokenEndpoint">
    <Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
    <Request>
      <Step>
        <Name>GenerateAccessToken</Name>
      </Step>
    </Request> 
  </Flow>
</Flows>

Elemen konfigurasi flow

Nama	Deskripsi	Default	Wajib?
`Flow`	Pipeline pemrosesan permintaan atau respons yang ditentukan oleh endpoint proxy atau endpoint target
`Name`	Nama unik Flow.	T/A	Ya
`Condition`	Pernyataan kondisional yang mengevaluasi satu atau lebih variabel untuk dievaluasi menjadi benar atau {i>false<i}. Semua Flow selain jenis PreFlow dan PostFlow yang telah ditentukan harus menentukan syarat untuk eksekusinya. Namun, jika Anda menyertakan satu alur tanpa kondisi di akhir urutan alur, maka akan bertindak sebagai "Else" di akhir urutan alur.	T/A	Ya
`Request`	Pipeline yang terkait dengan pemrosesan pesan Request	T/A	Tidak
`Response`	Pipeline yang terkait dengan pemrosesan pesan Response	T/A	Tidak

Pemrosesan langkah

Urutan Flow kondisional secara berurutan diterapkan oleh Apigee. Flow Bersyarat mengeksekusi dari atas ke bawah. Flow kondisional pertama yang kondisinya dievaluasi untuk true dieksekusi, dan hanya satu Flow kondisional yang dieksekusi.

Misalnya, dalam konfigurasi Flow berikut, setiap permintaan masuk yang tidak termasuk akhiran jalur /first atau /second akan menyebabkan ThirdFlow untuk dijalankan, dengan menerapkan kebijakan yang disebut Return404.

<Flows>
  <Flow name="FirstFlow">
    <Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="SecondFlow">
    <Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
      <Step><Name>SecondPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="ThirdFlow">
    <Request>
      <Step><Name>Return404</Name></Step>
    </Request>
  </Flow>
</Flows>

Referensi

"Sumber daya" (file resource untuk digunakan dalam proxy API) adalah skrip, kode, dan transformasi XSL yang dapat disertakan ke Flow menggunakan kebijakan. Skrip ini muncul di bagian Skrip pada API editor proxy di UI Apigee.

Lihat Mengelola resource untuk resource jenis resource.

Resource dapat disimpan di proxy API, lingkungan, atau organisasi. Dalam setiap kasus, resource yang direferensikan oleh nama dalam Kebijakan. Apigee me-resolve nama dengan berpindah dari API {i>proxy<i}, ke lingkungan, ke tingkat organisasi.

Resource yang disimpan di tingkat organisasi dapat dirujuk oleh Kebijakan di lingkungan apa pun. Resource yang disimpan pada tingkat lingkungan dapat direferensikan oleh Kebijakan di lingkungan tersebut. J resource yang disimpan di level proxy API hanya dapat direferensikan oleh Kebijakan di proxy API tersebut.

Referensi konfigurasi proxy API

Struktur direktori konfigurasi proxy API

Konfigurasi dasar

/apiproxy/weatherapi.xml

Elemen konfigurasi dasar

ProxyEndpoint

/apiproxy/proxies/default.xml

Konfigurasi ProxyEndpoint elemen

Cara mengonfigurasi RouteRules

Pemanggilan URL langsung

Rute bersyarat

Rute null

TargetEndpoint

Konfigurasi TargetEndpoint

/targets/default.xml

Konfigurasi TargetEndpoint elemen

Penggunaan elemen <Authentication>

Referensi error elemen <Authentication>

Contoh elemen <Authentication>

Konfigurasi TargetEndpoint TLS/SSL

TLS/SSL Elemen konfigurasi TargetEndpoint

Contoh endpoint target dengan autentikasi klien keluar diaktifkan

Menggunakan variabel flow untuk menetapkan nilai TLS/SSL secara dinamis

Menggunakan referensi untuk menetapkan nilai TLS/SSL secara dinamis

TargetEndpoint dengan load balancing target

IntegrationEndpoint

Mengonfigurasi IntegrationEndpoint

Elemen konfigurasi IntegrationEndpoint

Eksekusi Sinkron vs Asinkron

Kebijakan

Elemen konfigurasi kebijakan

Lampiran kebijakan

Konfigurasi lampiran kebijakan elemen

Alur

Alur bersyarat

Elemen konfigurasi flow

Pemrosesan langkah

Referensi

`/apiproxy/weatherapi.xml`

`/apiproxy/proxies/default.xml`

`/targets/default.xml`

Penggunaan elemen `<Authentication>`

Referensi error elemen `<Authentication>`

Contoh elemen `<Authentication>`