Anda sedang melihat dokumentasi Apigee Edge.
Lihat dokumentasi Apigee X.
Sebagai penyedia layanan, Anda mengembangkan API untuk digunakan oleh aplikasi klien. Untuk membuat, mengonfigurasi, dan mengelola 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. Subset tugas juga hanya dapat diselesaikan menggunakan API.
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 Mem-build proxy API pertama Anda. |
Edge untuk Private Cloud | UI Tepi Klasik | Untuk 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:
- Membuat 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.
- Mengonfigurasi 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 juga menyediakan akses ke kemampuan level rendah yang tidak diekspos oleh UI.
Endpoint API sering kali mengambil data yang berisi informasi konfigurasi dan mengharuskan Anda untuk
meneruskan informasi autentikasi, seperti nama pengguna dan sandi, agar dapat mengaksesnya. Dengan mengikuti prinsip RESTful, Anda dapat memanggil metode HTTP GET
, POST
, PUT
, dan DELETE
pada resource API mana pun.
Untuk mengetahui daftar lengkap Apigee Edge API, lihat Referensi API Apigee Edge.
Memahami jalur dasar Edge API
Jalur yang akan Anda gunakan dalam permintaan API akan menggabungkan hal-hal berikut:
- Jalur dasar yang menyertakan 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, panggil GET di:
https://api.enterprise.apigee.com/v1/organizations/apibuilders/apis
Banyak resource yang tercakup oleh lingkungan. Dua lingkungan disediakan secara default: pengujian dan produksi. Misalnya, cache dicakup oleh lingkungan. Cache bersama yang disebut "mycache" disertakan secara default di setiap lingkungan.
Anda dapat mencantumkan cache dengan memanggil GET di 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 melakukannya dengan salah satu cara berikut:
- OAuth2
- SAML
- Auth Dasar (tidak direkomendasikan)
Selain itu, Apigee merekomendasikan agar Anda menggunakan autentikasi 2 langkah, seperti yang dijelaskan dalam Mengaktifkan autentikasi 2 langkah untuk akun Apigee Anda.
Batas Edge API
Setiap organisasi dibatasi pada 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 batas ini akan menampilkan kode status 429 Too Many Requests
.
Tips untuk menggunakan Edge API
Bagian ini menjelaskan beberapa teknik yang mempermudah penggunaan Edge API.
Menyingkat URL permintaan
Saat membuat URL permintaan ke Edge API, Anda dapat menggunakan singkatan berikut:
/e = /environments
/o = /organizations
/r = /revisions
Jika Anda menggunakan singkatan, Anda harus menggunakannya secara konsisten. Artinya, menyingkat semua elemen di jalur, seperti disebutkan di atas dan diilustrasikan dalam contoh berikut, atau tidak sama sekali. Penggunaan elemen yang disingkat dan lengkap 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
memberikan contoh permintaan API menggunakan curl
, klien HTTP yang banyak digunakan. Jika perlu menginstal curl
, Anda dapat mendownloadnya dari http://curl.haxx.se.
Panggilan ke API mendukung kompresi gzip pada
respons. Jika Anda menyetel 'Accept-Encoding: gzip, deflate'
dalam panggilan API, respons
apa pun yang lebih besar dari 1.024 byte akan ditampilkan 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 yang dikirim kembali sebagai XML. Untuk melakukannya, setel header permintaan Accept
ke application/xml
, seperti yang ditunjukkan 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 melalui
xmllint
.
Utilitas acurl
tidak mendukung header Accept
. Akibatnya, Anda hanya bisa mendapatkan respons berformat JSON dengan acurl
.
Untuk menggunakan prettyprint
sebagai 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 adalah contoh respons:
[ "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 payload POSTING atau PUTING 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". Gunakan lingkungan "pengujian" untuk mengembangkan dan menguji API Anda sebelum menyediakannya untuk publik. Hanya developer internal yang dapat mengakses API yang di-deploy ke lingkungan pengujian. Deploy API Anda ke lingkungan "prod" untuk menyediakannya secara publik bagi developer aplikasi.
Proses debug dan pengujian
Apigee memberikan alat perekaman aktivitas yang memungkinkan Anda men-debug alur respons dan permintaan menyeluruh. Hasil trace menampilkan header dan payload permintaan dan respons, eksekusi kebijakan, nilai variabel, dan error yang mungkin terjadi selama alur.
Poin data penting untuk digunakan dalam pemecahan masalah:
- Stempel waktu: Gunakan stempel waktu untuk melihat berapa lama waktu yang dibutuhkan untuk menjalankan setiap langkah. Membandingkan stempel waktu akan membantu Anda mengisolasi kebijakan yang memerlukan waktu terlama untuk dijalankan, sehingga memperlambat panggilan API.
- Jalur dasar: Dengan memverifikasi jalur dasar, Anda dapat memastikan bahwa kebijakan merutekan pesan ke server yang benar.
- Hasil eksekusi kebijakan: Hasil ini memungkinkan Anda melihat apakah pesan diubah seperti yang diharapkan, seperti apakah pesan diubah dari XML ke JSON, atau apakah pesan di-cache.
Gambar berikut menampilkan hasil rekaman aktivitas:
Setiap sesi Trace dibagi menjadi beberapa langkah utama berikut:
- Permintaan asli yang diterima dari klien: Menampilkan jalur kata kerja dan 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.
- Response 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 aplikasi klien yang meminta setelah alur respons dieksekusi.