Anda sedang melihat dokumentasi Apigee Edge.
Buka
Dokumentasi Apigee X. info
Sebagai penyedia layanan, Anda mengembangkan API untuk digunakan oleh aplikasi klien. Untuk membuat, mengonfigurasi, dan memelihara proxy API dan produk API, Anda dapat menggunakan UI atau membuat permintaan HTTP ke API untuk mengakses layanan RESTful, seperti yang dijelaskan di bagian berikut.
Menggunakan UI Edge
UI Apigee Edge adalah alat berbasis browser yang dapat Anda gunakan untuk membuat, mengonfigurasi, dan mengelola Proxy API dan produk API. Sebagian tugas hanya dapat diselesaikan dengan API, berikutnya
Tabel berikut menjelaskan cara mengakses UI Edge:
| Produk | Nama UI | URL Akses |
|---|---|---|
| Edge | UI Edge | Untuk mengakses UI Edge, gunakan URL berikut: https://apigee.com/edge Untuk tutorial tentang penggunaan UI Edge, lihat Bangun proxy API pertama Anda. |
| Edge untuk Private Cloud | UI Edge Klasik | Guna mengakses UI Edge untuk Edge untuk Private Cloud, gunakan URL berikut: http://ms-ip:9000 Dengan ms-ip adalah alamat IP atau nama DNS node Server Pengelolaan. |
Dengan UI Edge, Anda dapat:
- Buat proxy API dengan mengedit kode dan melacak alur permintaan melalui proxy Anda.
- Membuat produk API yang memaketkan proxy untuk eksposur ke permintaan klien.
- Mengelola developer dan aplikasi developer.
- Konfigurasi lingkungan pengujian dan produksi Anda.
- Mengimplementasikan aplikasi JavaScript dan Node.js.
Gambar berikut menampilkan editor proxy API di UI yang dapat Anda gunakan untuk membuat dan mengonfigurasi Proxy API:
Menggunakan Edge API
Anda dapat menggunakan Edge API untuk mengelola resource API. API ini juga memberikan akses ke kemampuan tingkat rendah yang tidak diekspos oleh UI.
Endpoint API sering kali mengambil data yang berisi informasi konfigurasi dan mengharuskan Anda untuk
melewati informasi otentikasi, seperti
nama pengguna dan {i>password<i}, untuk mengaksesnya. Mengikuti RESTful
Anda dapat memanggil HTTP GET, POST, PUT, dan
Metode DELETE pada setiap resource API.
Untuk mengetahui daftar lengkap Apigee Edge API, lihat Referensi Apigee Edge API.
Memahami basis Edge API jalur
Jalur yang akan Anda gunakan dalam permintaan API menggabungkan hal berikut:
- Jalur dasar yang mencakup nama organisasi Anda. Contoh:
https://api.enterprise.apigee.com/v1/organizations/org_name - Endpoint yang mengarah ke resource Edge yang Anda akses.
Misalnya, jika nama organisasi Anda adalah apibuilders, maka setiap panggilan yang Anda lakukan ke
API akan menggunakan jalur dasar berikut:
https://api.enterprise.apigee.com/v1/organizations/apibuilders
Untuk mengambil daftar proxy API di organisasi, Anda dapat memanggil GET di:
https://api.enterprise.apigee.com/v1/organizations/apibuilders/apis
Banyak resource dicakup oleh lingkungan. Dua lingkungan disediakan secara {i>default<i}: {i>test<i} dan prod. Misalnya, cache dibatasi oleh lingkungan. Cache bersama bernama "mycache" disertakan secara {i>default<i} di setiap lingkungan.
Anda dapat mencantumkan cache dengan memanggil GET pada resource cache sebagai berikut:
https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/test/caches https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/prod/caches
Mengautentikasi akses
Anda harus mengautentikasi diri sendiri ke server API saat memanggil API. Anda dapat melakukan ini dengan salah satu cara berikut:
- OAuth2
- SAML
- Autentikasi Dasar (tidak direkomendasikan)
Selain itu, Apigee merekomendasikan agar Anda menggunakan autentikasi 2 langkah, seperti yang dijelaskan di Aktifkan autentikasi 2 langkah untuk akun Apigee Anda.
Batas Edge API
Setiap organisasi dibatasi oleh tarif panggilan Edge API berikut:
- 10.000 panggilan per menit untuk organisasi yang menggunakan paket berbayar
- 600 panggilan per menit untuk organisasi uji coba
Kode status HTTP 401 dan 403 tidak mengurangi batas ini. Setiap panggilan yang melebihi kuota ini
menampilkan kode status 429 Too Many Requests.
Tips untuk menggunakan Edge API
Bagian ini menjelaskan beberapa teknik yang dapat memanfaatkan Edge API semuanya.
Menyingkatkan URL permintaan
Saat membangun URL permintaan ke Edge API, Anda bisa menggunakan singkatan:
/e = /environments/o = /organizations/r = /revisions
Jika Anda menggunakan singkatan, Anda harus menggunakannya secara konsisten. Yaitu, menyingkat semua elemen dalam {i>path<i}, seperti yang disebutkan di atas dan diilustrasikan dalam contoh berikut, atau tidak sama sekali. Menggunakan elemen lengkap dan disingkat di jalur yang sama akan menyebabkan error.
Contoh:
THIS: https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/environments/prod/apis/helloworld/revisions/1/deployments CAN BE MUCH SHORTER: https://api.enterprise.apigee.com/v1/o/ahamilton-eval/e/prod/apis/helloworld/r/1/deployments
Menjalankan perintah curl
Menggunakan klien HTTP untuk membuat permintaan ke API. Banyak contoh dalam dokumentasi
menyediakan contoh permintaan API menggunakan curl, klien HTTP yang banyak digunakan. Jika Anda ingin
instal curl, Anda dapat mendownloadnya dari
http://curl.haxx.se.
Panggilan ke API mendukung kompresi gzip aktif
yang dihasilkan. Jika Anda menetapkan 'Accept-Encoding: gzip, deflate' dalam panggilan API, semua
dan respons yang lebih besar dari 1.024 byte akan
dikembalikan dalam format gzip.
Memformat permintaan dan respons XML dan JSON
Edge API menampilkan data sebagai JSON secara default. Untuk banyak permintaan, Anda bisa mendapatkan respons
dikirim kembali sebagai XML. Untuk melakukannya, setel header permintaan Accept ke
application/xml, seperti yang ditampilkan dalam contoh berikut:
curl -H "Authorization: Bearer `get_token`" \ -H "Accept: application/xml" \ https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \ | xmllint --format -
Responsnya akan terlihat seperti berikut:
<List> <Item>SOAP-Message-Validation-1</Item> <Item>Spike-Arrest-1</Item> <Item>XML-to-JSON-1</Item> </List>
Perhatikan bahwa contoh ini menggunakan prettyprint untuk menampilkan hasil dengan menyisipkan respons
xmllint.
Utilitas acurl tidak mendukung header Accept. Hasilnya, Anda dapat
hanya mendapatkan respons berformat JSON dengan acurl.
Agar dapat menggunakan prettyprint untuk respons JSON, Anda dapat menggunakan library Python json.tool:
curl https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \ -H "Accept: application/json" \ -H "Authorization: Bearer `get_token`" \ | python -m json.tool
Berikut ini contoh responsnya:
[ "SOAP-Message-Validation-1", "Spike-Arrest-1", "XML-to-JSON-1" ]
Untuk XML, Anda dapat menggunakan xmllint:
curl https://ahamilton-eval-test.apigee.net/getstarted -u email_address | xmllint --format -
Saat mem-POSTing atau PUT payload dalam XML, gunakan header HTTP Content-type:
acurl -H "Content-type:text/xml" -X POST -d \ '<XMLPayload> </XMLPayload> ' \ https://api.enterprise.apigee.com/v1/organizations/apifactory/apis -u email_address
Lingkungan deployment
Setiap organisasi yang menggunakan Apigee Edge secara default memiliki setidaknya dua lingkungan yang dapat mereka gunakan untuk mengembangkan, menguji, dan men-deploy API: "test" dan "prod". Menggunakan "pengujian" lingkungan untuk mengembangkan dan menguji API Anda sebelum menyediakannya untuk publik. Hanya developer internal Anda yang dapat mengakses API yang di-deploy ke lingkungan pengujian. Men-deploy API Anda ke "prod" untuk menjadikannya publik yang tersedia untuk developer aplikasi.
Proses debug dan pengujian
Apigee menyediakan alat rekaman aktivitas yang memungkinkan Anda melakukan debug permintaan dan respons end-to-end {i>flow<i} (alur). Hasil pelacakan menampilkan header dan payload permintaan dan respons, eksekusi kebijakan, nilai variabel, dan kesalahan apa pun yang mungkin terjadi selama alur.
Poin data utama untuk digunakan dalam pemecahan masalah:
- Stempel waktu: Gunakan stempel waktu untuk melihat berapa lama waktu yang dibutuhkan untuk mengeksekusi setiap langkah. Membandingkan stempel waktu membantu Anda mengisolasi kebijakan yang memerlukan waktu eksekusi paling lama memperlambat panggilan API Anda.
- Jalur dasar: Dengan memverifikasi jalur dasar, Anda dapat memastikan bahwa kebijakan mengarahkan pesan ke server yang benar.
- Hasil eksekusi kebijakan: Hasil ini memungkinkan Anda melihat apakah pesan diubah sesuai yang diharapkan, seperti jika pesan sedang diubah dari XML ke JSON, atau jika pesan di-cache.
Gambar berikut menunjukkan hasil rekaman aktivitas:
Setiap sesi Trace dibagi menjadi beberapa langkah utama berikut:
- Permintaan asli diterima dari klien: Menampilkan kata kerja dan jalur URI permintaan dari aplikasi klien, header, data isi, dan parameter kueri.
- Permintaan dikirim ke layanan backend Anda: Menampilkan pesan permintaan yang dikirim ke layanan backend oleh proxy API.
- Respons yang ditampilkan oleh layanan backend: Menampilkan header respons dan payload yang ditampilkan oleh layanan backend.
- Respons akhir dikirim ke klien: Pesan respons yang ditampilkan ke meminta aplikasi klien setelah alur respons dieksekusi.