Anda sedang melihat dokumentasi Apigee Edge.
Buka
dokumentasi Apigee X. info
Saat membuat permintaan ke proxy API, Anda dapat meneruskan salah satu atau semua informasi berikut, bergantung pada cara proxy API dikonfigurasi:
- Header permintaan
- Parameter kueri
- Data formulir
- Payload XML atau JSON
- URI Resource
Secara default, semua data dalam permintaan diteruskan tanpa perubahan dari ProxyEndpoint ke TargetEndpoint. Oleh karena itu, ketika TargetEndpoint membuat permintaan ke server backend, semua informasi dalam permintaan asli akan diteruskan ke layanan backend.
Hal yang sama berlaku untuk respons yang diterima Edge dari layanan backend. Secara default, semua data yang diterima dalam respons diteruskan tanpa perubahan ke aplikasi yang menghasilkan permintaan.
Bagaimana data permintaan diteruskan ke server backend?
Gambar berikut menunjukkan definisi proxy API:
Untuk proxy API ini:
- Host virtual proxy API: "default"
- Domain yang ditentukan oleh host virtual: "http://myOrg-prod.apigee.net"
- Jalur dasar proxy: "/v1/weather"
- TargetEndpoint yang ditentukan oleh aturan rute: "default"
- URL target: "http://weather.yahooapis.com"
Aplikasi klien membuat permintaan GET
ke proxy API dengan menggunakan perintah curl
berikut:
curl -X GET http://myOrg-prod.apigee.net/v1/weather/forecastrss?w=12797282
Perhatikan bahwa permintaan ini berisi resource "forecastrss" dan satu parameter kueri,
w
. Edge mengurai permintaan seperti
yang ditunjukkan di bawah ini dan menetapkan bagian-bagian permintaan ke variabel flow:
{request.verb} {proxy.basepath}/{proxy.pathsuffix}?{request.querystring}
Variabel flow ditetapkan dengan nilai berikut:
request.verb
: "DAPATKAN"proxy.basepath
: "/v1/cuaca"proxy.pathsuffix
: "perkiraan"request.querystring
: "w=12797282"
TargetEndpoint kemudian membuat permintaan ke layanan backend menggunakan informasi dari permintaan tersebut:
{request.verb} {target.basepath}/{proxy.pathsuffix}?{request.querystring}
Perhatikan bagaimana parameter resource dan kueri yang ditentukan dalam permintaan secara otomatis disertakan dalam permintaan ke server backend. Dari definisi TargetEndpoint, permintaan tersebut kemudian memiliki bentuk:
curl -X GET http://weather.yahooapis.com/forecastrss?w=12797282
Seperti parameter kueri, header atau parameter bentuk apa pun yang Anda sertakan dalam permintaan ke proxy API akan diteruskan ke server backend. Misalnya, Anda membuat permintaan di bawah ini yang menyertakan header:
curl -X GET -H 'Content-type:application/xml' http://myOrg-prod.apigee.net/v1/weather/forecastrss?w=12797282
Atau permintaan dalam formulir di bawah ini untuk menyertakan data formulir dan header:
curl -X POST -H "Content-type:application/json" -d \ '{"email" : "janetutorialxml@example.com", "firstName" : "Jane", "lastName" : "Tutorial", "userName" : "jtutorialxml" }' \ http://myOrg-prod.apigee.net/v1/register/user
Dalam kedua contoh tersebut, header dan data formulir diteruskan tanpa perubahan ke layanan backend. Header
ditampilkan oleh variabel flow seperti request.headers.count
dan
request.headers.names
. Data formulir direpresentasikan oleh variabel flow seperti
request.formparam.count
dan request.formparam.names
.
Bagaimana data respons ditampilkan?
Secara default, semua data yang diterima oleh Edge dari layanan backend dalam respons akan diteruskan tanpa perubahan ke aplikasi yang menghasilkan permintaan. Seperti yang dijelaskan di atas untuk permintaan, data yang ditampilkan dalam respons dapat diakses melalui variabel alur di Edge. Untuk mengetahui informasi selengkapnya, lihat Referensi variabel flow.
Mengakses data permintaan dan respons di proxy API
Sering kali Anda ingin mengubah data permintaan sebelum mengirimkannya ke server backend. Contoh:
- Untuk menghapus informasi keamanan yang digunakan oleh Edge untuk memvalidasi permintaan. Informasi tersebut tidak diperlukan oleh layanan backend.
- Untuk menambahkan data yang dikirimkan ke layanan backend, misalnya untuk melacak pengguna atau untuk mengumpulkan analisis.
- Untuk memproses permintaan secara bersyarat berdasarkan data permintaan. Misalnya, proxy API dapat memiliki beberapa TargetEndpoints. TargetEndpoint yang digunakan oleh permintaan ditentukan oleh data permintaan. Kemudian, Anda perlu menghapus data tersebut dari permintaan sebelum mengirimkannya ke layanan backend.
Hal yang sama berlaku untuk data dalam respons. Sebagai bagian dari pemrosesan respons, proxy API mungkin ingin mengubah data sebelum menampilkannya ke aplikasi yang meminta.
Pesan permintaan akses
Anda dapat menggunakan kebijakan untuk mengakses dan mengubah bagian pesan permintaan. Bagian ini mencakup:
- Header
- Parameter kueri
- Parameter formulir
- Alamat IP Sumber
- Isi pesan HTTP
Dalam alur normal, setelah permintaan diproses, proxy kemudian akan mengirimkan permintaan yang ditransformasi ke target.
Kebijakan dapat memeriksa variabel permintaan, lalu mengubah atau menolak permintaan berdasarkan isi variabel tersebut. Kebijakan mengubah permintaan dengan menetapkan variabel yang sesuai, misalnya variabel yang sesuai dengan header permintaan.
Mengakses pesan respons
Dengan menggunakan variabel yang berlaku untuk pesan respons, kebijakan dapat mengakses komponen pesan, termasuk header, parameter kueri, parameter formulir, alamat IP sumber, isi pesan HTTP, dan sebagainya.
Proxy menerima pesan respons, kemudian menerapkan serangkaian kebijakan ke sana, berdasarkan kondisi yang dievaluasi pada respons, yang dapat memodifikasi atau mentransformasi respons.
Kebijakan dapat memeriksa variabel respons, lalu mengubah atau menolak permintaan berdasarkan isi variabel tersebut. Kebijakan mengubah respons dengan menetapkan variabel yang sesuai, misalnya variabel yang sesuai dengan header respons.
Kebijakan umum untuk mengakses variabel alur
Edge menentukan beberapa kebijakan yang dapat Anda gunakan untuk memproses data permintaan dan respons. Kebijakan ini mencakup:
- KebijakanAssignMessage: Membuat atau mengubah permintaan HTTP atau pesan respons selama alur proxy API. Juga membuat dan mengisi variabel flow baru.
- Kebijakan ExtractVariables: Mengekstrak konten dari pesan, termasuk header, jalur URI, payload, dan parameter kueri, untuk digunakan dalam pernyataan kondisi. Selanjutnya, kebijakan tersebut akan menerapkan pola teks ke konten pesan dan, setelah menemukan kecocokan, akan menetapkan variabel yang ditetapkan.
- Kebijakan JSONtoXML dan kebijakan XMLtoJSON: Mengonversi pesan dari JavaScript Object Notation (JSON) menjadi format extensible markup language (XML), atau sebaliknya.
- Kebijakan JavaCallout, kebijakan JavaScript, kebijakan PythonScript, dan kebijakan RegularExpressionProtection: Kebijakan ini memungkinkan Anda menulis skrip untuk mengakses variabel alur yang berisi data permintaan dan respons.