Pengantar

Anda sedang melihat dokumentasi Apigee Edge.
Buka Dokumentasi Apigee X.
info

Bagian berikut memperkenalkan Anda pada produk API dan konsep utama terkait.

Apa yang dimaksud dengan produk API?

Sebagai penyedia API, Anda membuat produk API untuk memaketkan dan menyediakan API bagi pengembang aplikasi untuk dikonsumsi. Anda dapat menganggap produk API sebagai lini produk Anda.

Secara khusus, produk API menggabungkan hal-hal berikut:

  • Kumpulan resource API (URI)
  • Paket layanan
  • Metadata khusus untuk bisnis Anda untuk pemantauan atau analisis (opsional)

Resource API yang dipaketkan dalam produk API bisa berasal dari satu atau beberapa API, sehingga Anda dapat memadupadankan untuk membuat set fitur khusus, seperti yang ditunjukkan dalam gambar berikut.

Anda dapat membuat beberapa produk API untuk menangani kasus penggunaan yang memenuhi kebutuhan tertentu. Misalnya, Anda dapat membuat produk API yang memaketkan sejumlah resource pemetaan ke memungkinkan pengembang untuk mengintegrasikan peta dengan mudah ke dalam aplikasi mereka. Selain itu, Anda dapat menetapkan properti berbeda pada setiap produk API, seperti harga yang berbeda level organisasi. Misalnya, Anda dapat menawarkan kombinasi produk API berikut:

  • Produk API yang menawarkan batas akses rendah, seperti 1.000 permintaan per hari, dengan harga murah. Produk API kedua yang memberikan akses ke resource yang sama, tetapi dengan batas akses yang lebih tinggi dan harga yang lebih tinggi.
  • Produk API gratis yang menawarkan akses hanya baca ke resource. Produk API kedua yang menyediakan akses baca/tulis ke resource yang sama dengan biaya rendah.

Selain itu, Anda dapat mengontrol akses ke resource API di produk API. Misalnya, Anda dapat memaketkan resource yang hanya dapat diakses oleh developer internal atau dengan pelanggan berbayar saja.

Produk API merupakan mekanisme utama untuk otorisasi dan kontrol akses ke API Anda. Di Apigee, kunci API disediakan, bukan untuk API itu sendiri, tetapi untuk produk API. Dengan kata lain, API kunci disediakan untuk paket resource yang disertai dengan paket layanan.

Developer aplikasi mengakses produk API Anda dengan mendaftarkan aplikasi mereka, seperti yang dijelaskan dalam Mendaftarkan aplikasi. Saat aplikasi mencoba mengakses produk API, otorisasi diberlakukan oleh Apigee saat runtime untuk memastikan bahwa:

  • Aplikasi yang meminta diizinkan untuk mengakses resource API tertentu.
  • Aplikasi yang meminta belum melebihi kuota yang diizinkan.
  • Jika ditetapkan, cakupan OAuth yang ditetapkan dalam produk API akan cocok dengan cakupan yang terkait dengan akses token yang disajikan aplikasi.

Memahami konsep utama

Tinjau konsep utama berikut sebelum Anda membuat produk API.

Kunci API

Saat mendaftarkan aplikasi developer di organisasi Anda, aplikasi tersebut harus dikaitkan dengan setidaknya satu produk API. Sebagai hasil penyambungan aplikasi dengan satu atau beberapa produk API, Edge menetapkan kunci konsumen unik ke aplikasi.

Kunci konsumen atau token akses berfungsi sebagai kredensial permintaan. Developer aplikasi menyematkan kunci konsumen ke dalam aplikasi, sehingga saat aplikasi membuat permintaan ke API yang dihosting oleh Edge, aplikasi meneruskan kunci konsumen dalam permintaan dengan salah satu cara berikut:

  • Saat API menggunakan verifikasi kunci API, aplikasi harus meneruskan kunci konsumen secara langsung.
  • Saat API menggunakan verifikasi Token OAuth, aplikasi harus meneruskan token yang telah berasal dari kunci konsumen.

Penerapan kunci API tidak terjadi secara otomatis. Apakah menggunakan kunci konsumen atau token OAuth sebagai kredensial permintaan, Proxy API memvalidasi kredensial permintaan Proxy API dengan menyertakan kebijakan VerifyAPIKey atau kebijakan OAuth/VerifyAccessToken, dalam alur yang sesuai. Jika Anda tidak menyertakan kebijakan penerapan kredensial di Proxy API, setiap pemanggil dapat memanggil API Anda. Untuk informasi selengkapnya, lihat Memverifikasi kebijakan Kunci API.

Untuk memverifikasi kredensial yang diteruskan dalam permintaan, Edge melakukan langkah-langkah berikut:

  • Dapatkan kredensial yang diteruskan dengan permintaan. Dalam kasus OAuth verifikasi token, Edge memverifikasi bahwa masa berlaku token belum berakhir, lalu mencari konsumen yang digunakan untuk membuat token.
  • Ambil daftar produk API yang telah dikaitkan dengan kunci konsumen.
  • Pastikan bahwa Proxy API saat ini disertakan dalam Produk API, dan apakah jalur resource (jalur URL) diaktifkan pada Produk API.
  • Verifikasi bahwa kunci konsumen tidak kedaluwarsa atau dicabut, periksa apakah aplikasi tidak dicabut, dan memeriksa apakah developer aplikasi aktif.

Jika semua pemeriksaan di atas lulus, verifikasi kredensial akan berhasil.

Intinya, Edge secara otomatis membuat kunci konsumen, tetapi penerbit API harus melakukannya menerapkan pemeriksaan kunci di proxy API dengan menggunakan kebijakan yang sesuai.

Otomatis versus manual persetujuan

Secara default, semua permintaan guna mendapatkan kunci untuk mengakses produk API dari aplikasi akan otomatis disetujui. Atau, Anda dapat mengonfigurasi produk API untuk menyetujui kunci secara manual. Dalam hal ini, Anda harus menyetujui permintaan kunci dari aplikasi apa pun yang menambahkan produk API. Untuk informasi selengkapnya, lihat Mendaftarkan aplikasi dan mengelola API .

Kuota

Kuota dapat melindungi server backend Anda dari traffic tinggi, dan membedakan lini produk Anda. Misalnya, Anda mungkin ingin memaketkan resource dengan kuota tinggi sebagai produk premium dan menggunakan paket yang sama, dengan kuota lebih rendah sebagai produk dasar. Kuota dapat membantu melindungi server Anda dari kewalahan jika suatu produk populer dan menerima banyak permintaan.

Untuk mengetahui informasi tentang cara mengonfigurasi kuota, lihat Kebijakan kuota. Untuk mengetahui informasi tentang menggunakan setelan kuota produk dalam kebijakan kuota, lihat artikel komunitas berikut Bagaimana cara setelan kuota pada produk API berinteraksi dengan kebijakan kuota di proxy API?.

Cakupan OAuth

Sebagai tingkat keamanan tambahan, Anda dapat menentukan cakupan OAuth, sebagai daftar yang dipisahkan koma, yang harus ada dalam token akses yang dikirim melalui produk. Saat membuat produk, Anda harus mengetahui semua ruang lingkup yang digunakan organisasi Anda. Cakupan yang Anda tambahkan ke produk harus cocok dengan cakupan yang ada atau produk tidak aman.

Untuk informasi selengkapnya tentang penggunaan cakupan dengan kebijakan OAuth Edge, lihat Menangani cakupan OAuth2.

Tingkat akses

Saat menentukan produk API, Anda dapat menetapkan tingkat akses berikut.

Tingkat akses Deskripsi
Publik Produk API yang tersedia untuk semua developer. Anda dapat menambahkannya ke portal developer yang terintegrasi atau berbasis Drupal.
Pribadi atau Khusus internal

Produk API yang didesain untuk penggunaan pribadi atau internal.

Catatan: Tidak ada perbedaan fungsi antara tingkat akses Pribadi dan Khusus internal. Pilih label yang paling mendeskripsikan audiens yang dituju produk API.

Untuk portal terintegrasi, Anda dapat menambahkan produk API pribadi atau khusus internal dan menyediakannya untuk developer aplikasi, sesuai kebutuhan.

Untuk portal developer berbasis Drupal, Anda dapat mengelola akses ke produk API Pribadi atau Khusus internal di portal developer Anda, seperti yang dijelaskan di bagian berikut:

  • Untuk portal developer Drupal 10, Anda dapat mengonfigurasi akses ke produk API Pribadi atau Khusus internal di portal developer, seperti yang dijelaskan dalam Mengonfigurasi izin akses ke produk API.
  • Untuk portal developer Drupal 7, Anda tidak dapat menambahkan produk API Pribadi atau Khusus Internal ke portal developer Anda. Agar produk API Pribadi atau Khusus internal tersedia bagi developer aplikasi, Anda harus menambahkannya secara manual ke aplikasi yang terdaftar dari API atau UI pengelolaan Edge, seperti yang dijelaskan dalam Mendaftarkan aplikasi dan mengelola kunci API. Setelah ditambahkan, developer akan melihat produk API yang terkait dengan aplikasi di portal Anda, seperti yang dijelaskan dalam Mengelola produk API dalam aplikasi. Jika developer aplikasi menonaktifkan akses ke produk API yang bersifat internal atau pribadi, produk API dihapus dari aplikasi dan harus ditambahkan kembali secara manual oleh administrator portal.