Selamat datang di episode lain dari Microsoft Knowledge Nugget. Saya pemandu Anda, Mirko Petra. Topik hari ini adalah sesuatu yang hampir semua orang pernah dengar, namun sedikit yang benar-benar paham. API. Anda mungkin sering mendengar istilah ini disebut-sebut. Ini adalah salah satu istilah teknologi yang digunakan orang saat ingin terlihat paham dengan apa yang mereka bicara. Namun faktanya, API sebenarnya sederhana. API hanyalah cara bagi satu perangkat lunak untuk berkomunikasi dengannya. Ponsel Anda meminta data kesebuah server. Server keminimkannya kembali. Itulah yang disebut panggilan API. Sekarang bayangkan Anda memiliki 20 API atau 50 atau serat. Masing-masing mungkin menggunakan autentikasi, batas kecepatan, dan dokumentasi yang berbeda. Jika ada, tiba-tiba apa yang dimulai sebagai percakapan sederhana antara dua aplikasi berubah menjadi kekacauan total. Tanpa pengelola pusat, setiap tim bekerja sendiri-sendiri.

Satu tim membangun sistem autentikasi sendiri. Tim lain membangun sistem pencetan lock sendiri. Celah keamanan muncul di mana. Pengembang, bingung tentang API, mana yang melakukan apa, dan Anda tidak memiliki pandangan tunggal tentang apa yang sebenarnya terjadi di seluruh sistem Anda. Azure API Management menjawab masalah ini. Yang beri Anda satu pusat kendali. Bayangkan seperti menara pengawas lalu lintas udara untuk API Anda. Di akhir episode ini, Anda akan mengerti apa fungsinya, mengapa itu penting, dan bagaimana semua bagiannya saling melengkapi. Siapkan kopi Anda, dan mari kita mulai. Masalahnya terlalu banyak API tanpa kendali. Inilah realita perangkat lunak-undari. Sepuluh tahun lalu, Anda mungkin memiliki satu aplikasi besar, monolid, satu basis data, satu API sederhana. Hari ini, aplikasi yang sama mungkin dipecah menjadi puluhan layanan mikro. Setiap layanan menangani satu hal, seperti akun pengguna, pembayaran, inventaris, notifikasi, dan masing-masing mengekspos API-nya sendiri.

Anda memiliki 10, 50, 100 titik masuk berbeda ke dalam sistem Anda. Sekarang bayangkan Anda seorang pengembang yang mencoba membangun sesuatu yang menggunakan API ini. Anda harus menemukan masing-masing dan mencari cara autentikasi untuk semua. Ada yang menggunakan kunci API, ada yang menggunakan OA, ada yang tidak menggunakan apapun. Anda harus menangani pembatasan kecepatan secara manual atau berisiko terblok. Anda harus memahami format data yang diharapkan oleh masing-masing API. Itu sangat melelahkan. Dan dari sisi operasional, situasinya lebih buruk. Tanpa gerbang pusat, setiap tim harus menambahkan keamanan dan pencatatan log ke layanan mereka sendiri secara manual. Beberapa tim melakukannya dengan baik, yang lain lupa mencatat log ke salah. Beberapa bahkan tidak melakukan validasi input salah. Tidak konsisten dan tentang kesalahan, mimpi buruk keamanan yang siap terjadi, kepatuan menjadi hampir mustahil.

Perlu membuktikan siapa yang mengakses apa dan kapan. Semoga berhasil menarik jejak audit dari 20 layanan berbeda, masing-masing dengan format pencatatan list. Berapa banyak panggilan API yang ditangani sistem Anda bulan lalu, Anda harus menggabungkan metrik dari belasan dashboard yang berbeda. Ini masalah. Seiring Anda berkembang, ini bukan sekarang menyulitkan. Ini merusak segala. Anda tidak bisa menambah pengembang, layanan, atau pelanggan tanpa titik kendali pusat. Bayangkan ini sebuah gedung. Bayangkan setiap ruangan memiliki kunceng berbeda. Tidak ada meja resepsionis atau direktor. Pengunjung berkeliaran mencari pintu yang tepat, merasa frustrasi, dan akhirnya menyerah. Kacauan total. Inilah masalah yang dirancang untuk diselesaikan oleh manajemen API. Apa itu Azure API Management? Menara kontrolnya. Jadi apa sebenarnya Azure API Management itu? Ini definisi yang paling sederhana.

Ini adalah layanan terkelola yang berada di antara API backend Anda dan aplikasi, situs web, perangkat, serta mitra yang menggunakannya. Tapi begini, ini bukan sekadar proxy. Proxy yang meneruskan lalu lintas. Azure API Management mencakup siklus hidup penuh API Anda. Mempublikasikan, mengemankan, memantau, hingga akhirnya menghentikan. Ini adalah pusat kendali yang lengkap. Mari kita bagi menjadi tiga komentar utama. Yang pertama adalah gateway. Setiap permintaan masuk dari aplikasi atau situs web mencapai gateway terlebih dahulu bukan langsung ke backend Anda. Gateway memproses permintaan, menegakkan kebijakan yang Anda buat, mengumpulkan metrik, lalu meneruskannya ke layanan backend yang tepat. Anggap saja ini sebagai prodisi. Berikutnya adalah bidang manajemen. Disinilah Anda menentukan segalanya. API Anda, kebijakan Anda, produk Anda, langganan Anda. Anda melakukannya melalui portal Azure, baris perintah, atau infrastruktur sebagai kode seperti bicep atau terraform.

Ini adalah ruang kontrol untuk Anda mengonfigurasi cara kerja semua. Lalu portal pengembang. Ini adalah situs web mandiri tempat pengembang, baik internal maupun eksternal. Dapat menemukan API Anda, membaca dokumentasi, mendapatkan kunci langganan, dan bahkan menguji panggilan API langsung di browser mereka. Tidak perlu lagi saling mengirim surah beli CPDR. Ini adalah yang membantu. Kayakkan sebuah bandara modern. Gateway adalah anda sempat cunyit. Setiap pesawat mendarat di sana terlebih dahulu. Bidang manajemen adalah menara kontrolin. Ia mengarahkan lalu lintas, menetapkan aturan, dan memantau segala. Dan portal pengembang adalah papan informasinya. Pilot pemeriksaannya sebelum terbang dan mereka bisa menemukan semua informasi yang dibutuhkan tanpa harus berbicara dengan siapapun. Sekarang mari kita terus-terus di lebih dalam. Itu adalah bagian yang benar-benar dihubungi oleh aplikasi Anda dan tempat keajaiban yang sebenarnya terjadi.

Gateway, pintu depan API Anda. Mari kita bahas tentang gateway, karena inilah bagian yang benar-benar dihubungi oleh aplikasi Anda. Setiap permintaan dari aplikasi seluler, situs web, atau perangkat IoT akan menuju gateway terlebih dahulu. Bukan langsung ke back-end Anda, telah tujuan utamanya. Gateway berada di depan dan bertindak sebagai satu titik masuk. Gateway dapat menerapkan kebijakan sebelum meneruskan permintaan. Kebijakan adalah aturan yang Anda tulis dalam XML atau JSON, seperti pembatasan kecepatan, pemfilteran API, penulisan ulang header, dan pemeriksaan notifikasi. Semua itu tanpa mengubah satu baris mengurde back-end Anda. Berikut adalah contoh konkret. Katakanlah Anda memiliki tingkat gratis dan tingkat premium untuk APN. Dengan kebijakan, Anda dapat membatasi pengguna gratis hingga 5 permintaan per menit, sementara pengguna premium mendapatkan serat. Back-end Anda tidak pernah mengetahui perbedaannya.

Back-end hanya memproses permintaan. Gateway menangani penegakannya. Gateway juga menangani cacing. Jika data diminta berulang kali, seperti daftar produk yang jarang berubah, Gateway dapat menyimpan respons dan menyajikannya secara langsung. Tidak perlu mengganggu back-end Anda sama sekali, yang berarti respons lebih cepat dan beban server lebih ringan. Ini juga dapat mengubah data. Back-end Anda mungkin mengubahkan XML, tetapi aplikasi seluler Anda mengharapkan JSON. Gateway dapat mengubah versinya secara langsung. Back-end Anda tidak perlu diubah, dan aplikasi Anda juga tidak perlu diubah. Gateway menangani penerjemahannya. Dan Gateway mencatat setiap panggilan, setiap permintaan, setiap respons, setiap kesalahan. Anda mendapatkan jejak audit lengkap tentang siapa yang memanggil apa-apa dan apa yang terjadi. Itu saja sudah sepadan untuk kebutuhan-kepatuhan. Jika Anda memiliki audiens global, Anda dapat menerapkan Gateway di berbagai wilayah.

Lalu lintas secara otomatis diarahkan ke yang terdekat, yang memberikan latensi lebih rendah dan pengalaman yang lebih baik. Satu hal lagi, Gateway menyembunyikan URL back-end asli Anda. Klien hanya melihat alamat Gateway. Server back-end Anda tetap tersembunyi dari internet. Itu adalah keuntungan keamanan yang sangat besar di check-out. Kebijakan mesin yang mengendalikan segalanya. Jadi bagaimana dengan saya sebutkan tadi? Itulah mesin yang membuat APIM benar-benar hebat. Kebijakan mengubah perilaku permintaan atau respons tanpa Anda harus menyentuh kode back-end. Anggaplah ini sebagai pembungkus di sekitar APN. Saat lalu lintas mengalir, kebijakan dapat menambah, menghapus, atau mengubah berbagai hal secara otomatis. Kebijakan dapat berjalan di empat titik dalam siklus hidup permintaan. Inbound, saat masuk sebelum permintaan mencapai back-end Anda. Outbound, saat kembali, sebelum respon sampai ke klien.

Back-end, tepat sebelum permintaan mencapai layanan Anda. Dan pada kesalahan ketika terjadi kegagang. Tugas masuk yang umum termasuk memvalidasi token JWT untuk memeriksa identitas pemanggil, memeriksa kunci API, menulis ulang URL, dan membatasi berdasarkan alamat IP. Semua ini terjadi sebelum back-end Anda menerima satu permintaan pun. Untuk lalu lintas keluar, Anda dapat mengubah padanus. Cari dan ganti teks, hapus kolom sensitif, ubah format. Anda dapat menyimpan respons dalam CC agar permintaan berulang tidak membabani back-end Anda. Anda bahkan dapat menghapus header yang membocorkan informasi internet. Berikut adalah contoh konkret. Katakanlah api Anda mengembalikan deskripsi produk dengan kata biru di mana-mana Anda ingin melakukan rebranding dan menggunakan kuning sebagai get. Alih-alih mengubah kode back-end, Anda cukup menambahkan satu kebijakan keluar. Cari biru, ganti dengan kuning.

Selesai. Back-end Anda tidak pernah berubah. Kebijakan pembatasan kecepatan dan kuota melindungi back-end Anda dari penyak. Jika aplikasi seorang rusak dan mulai membombadir api Anda 10 ribu kali per detik, kebijakan akan bertindak dan berkata pelan-pelan. Baikkan Anda tetap sehat. Perlogika tingkat lanjut. Anda dapat menulis ekspresi secara custom di dalam kebijakan. Ekspresi tersebut dikompilasi untuk internet. Jadi tidak ada dia waktu proses. Anda dapat mencari peran pengguna, menghitung batas kecepatan dinamis, atau mengubah respon secara kondisional berdasarkan header permintaan. Poin utamanya adalah ini. Kebijakan memungkinkan Anda mengontrol perilaku api tanpa menyentuh kode yang menjalankannya. Itu berarti perubahan lebih cepat, lebih sedikit penyebaran, dan risiko lebih rendah. Produk dan langganan mengemas api untuk konsumen. Sekarang api Anda sudah ditentukan, kebijakan sudah ada, dan gateway berjalan, lancar.

Namun, bagaimana Anda memberikan akses berbeda kepada pelanggan yang berbeda? Disitulah produk dan langganan berbeda. Di APIM, Anda mengelompokkan api ke dalam sesuatu yang disebut produk. Anggap saja sebagai paket. Anda mungkin memiliki produk tingkat gratis yang hanya mencakup api dasar Anda. Mungkin hanya akses baca saja, lalu produk premiumnya mencakup segalanya, termasuk operasi tulis dan titik akhir admin. Pengembang tidak berlangganan api individu, mereka berlangganan produk. Saat mereka berlangganan, mereka mendapatkan kunci langganan. Sebenarnya, dua kunci, sehingga Anda dapat merotasi satu tanpa waktu. Kunci itu adalah izin mereka untuk menggunakan AIP apapun dalam produk tersebut. Anda mengontrol bagaimana langganan berkerja. Produk dapat memerlukan persetujuan. Anda menerima setiap pelanggan secara manual, atau mereka bisa terbuka untuk sualayan. Siapapun dapat mendaftar dan mendapatkan akses langsung.

Anda juga dapat menyertakan ketentuan hukum yang harus dituju pengguna sebelum berlangganan. Itu penting jika api Anda menangani data sensitif. Beginilah cara Anda memonetisasi api. Produk gratis dengan batas kecepatan rendah 5 panggilan per menit. Produk berbayar dengan batas lebih tinggi atau lebih banyak titik akhir 100 panggilan per menit, ditambah akses ke fitur premium. Pengembang tidak peduli. Gateway menerapkan batasan berdasarkan produk mana yang dilanggani oleh pemanggil. Berikut contoh nyatanya. Bayangkan Anda sedang membangun aplikasi Converent. Anda membuat produk peserta dengan api untuk jadwal sesi, biografi pembicara, dan peta lokasi. Lalu produk sponsor yang juga menyertakan api penghasil prospek. Sponsor dapat memindai rencana peserta dan mendapatkan info kota. Backend yang sama produk berbeda, tingkat akses berbeda. Kedua kunci langganan tersebut dirancang untuk rotasi.

Jika kunci disusupi, Anda dapat membuat yang baru. Kunci kedua mungkin akan Anda beralih tanpa mengganggu layan. Buat kunci baru, perbarui aplikasi Anda. Batalkan yang lama. Ulus. Portal pengembang. Sualayan untuk konsumen api. Anda telah menyiapkan produk api. Tarang pengembang perlu menemukan. Itulah tugas portal pengembang. Portal pengembang adalah situs web yang terintegrasi ke dalam setiap instans web. Pengembang menggunakannya untuk menelusuri api Anda, membaca dokumentasi, dan menguji endpoint secara interaktif langsung di perambat mereka. Tidak perlu pengaturan dan tidak ada email bolak-balik. Namun masalahnya, portal ini tidak dipublikasikan secara default. Saat pertama kali membuat instans APM, portal memang ada, tetapi tidak ada yang bisa melihatnya. Anda harus menyesuaikan dan menerbitkannya terlebih dahulu. Itu disengaja. Anda tidak ingin menunjukkan portal yang belum selesai kepada dunia.

Anda dapat menyesuaikan warna merek, logo, bahkan menyematkan konten WordPress untuk blog di samping dokumentasi api Anda. Portal ini dapat disesuaikan sepenuhnya Anda sesuai dengan tampilan dan luansa perusahaan. Nilai sebenarnya adalah swalayan. Pengembang mendaftar, mendapatkan kunci langganan mereka secara otomatis, dan langsung mulai memanggil API. Tidak ada email manual, tidak perlu menunggu persetujuan, tidak ada tiket dukungan yang mendanyakan cara mendapatkan kunci. Mereka melakukannya sendiri, yang secara signifikan mengurangi beban dukungan Anda. Anda juga dapat mempublikasikan log perubahan dan catatan. Saat Anda memperbarui API, pengembang melihatnya di portal tanpa kejutan. Akses bisa bersifat publik bagi siapa saja dengan URL. Atau Anda dapat membatasinya untuk pengguna dari penyewa entry ID Anda, sehingga hanya orang di organisasi Anda yang bisa melusuri. Kedua opsi tersedia untuk kasih pengguna yang berbeda.

Portal pengembang adalah hal yang menjadikan manajemen API Anda sebagai platform ingat. Anggap saja sebagai etalas untuk API Anda. Tanpanya, pengembang harus mencari melalui dokumen dan bertanya ke sana kemari. Dengan portal, mereka menemukan apa yang dibutuhkan dan mulai memulai. Keamanan, autentikasi, otorisasi, dan rahasia. Semua kekuatan ini tidak berguna jika keamanan tidak dikunci dengan ketat. Jadi, mari kita bahas bagaimana API menangani identitas, akses, dan rahasia. API mendukung berbagai metode autentikasi. Yang paling sederhana adalah kunci langganan yang telah kita bahas sebelumnya. Namun, untuk sistem produksi, Anda memerlukan sesuatu yang lebih kuat seperti OO2.0 token JWT, sertifikat klien, atau penfilteran IP. Anda dapat melapisinya berdasarkan seberapa sensitif API Anda. Untuk produksi, praktek terbaik adalah menggunakan OO2.0 entry ID. Begini cara kerjanya. Aplikasi klien mendapatkan token dari entry ID dan mengirimkannya bersama permintaan API.

API memvalidasi token dengan memeriksa tanda tangan, penerbit audiens, dan masa berlakunya. Jika valid, API meneruskan permintaan ke backend Anda, termasuk token tersebut. Backend Anda mempercayainya karena API sudah meverifikasinya, jadi backend tidak perlu memvalidasi ulang. Itu adalah satu hal yang tidak perlu lagi ditangani setiap klien. Sekarang mari kita bicara tentang RISE. Kunci API, string koneksi, sertifikat. Anda tidak ingin itu. Ditulis langsung dalam file kebijakan atau kontrol sumber. API memiliki fitur yang disebut Name Values. Anda menyimpan rahasia secara terpusat di API dan merujuknya berdasarkan nama di kebijakan Anda. Nilai sebenarnya tidak pernah muncul dalam kode kebijakan Anda. Lebih baik lagi, Anda dapat menghubungkan Name Values ke Azure Key Vault. Rahasia tetap terenkripsi di Key Vault dan API mengambilnya saat terentak. Tidak ada seorang pun bahkan tim DevOps Anda yang melihat nilai rahasia sebenarnya.

Saat Anda perlu merotasi kunci, Anda perbarunya di Key Vault dan API secara otomatis mendeteksi perubahan tersebut. API juga mendukung identitas terkelola. Ini memungkinkan API mengautentikasi ke layanan Azure lain, seperti Key Vault atau API Backend tanpa menyimpan kredensial apapun. Azure menangani identitas tersebut, jadi Anda perlu memberikan isi. Dan untuk isolasi jaringan, Anda dapat menempatkan API di dalam jaringan virtual. Itu adalah tingkat premium. Intinya adalah layanan backend Anda tidak perlu diekspos langsung ke internet. APIM adalah satu-satunya hal yang dilihat oleh dunia luar. Pendekatan berlapis ini membangun pertahanan yang mendalam. Autentikasi di gateway, rahasia di perangkas, isolasi jaringan di sekitar backend Anda. Setiap lapisan memperkuat lapisan berit. Tingkat harga, mana yang cocok untuk Anda? Jadi berapa biaya ini? Mari kita bahas tingkatan. Tingkat konsumsi.

Bayar perpanggilan API tanpa biaya bulan nentuk. Sangat cocok untuk beban kerja bervolume rendah atau tidak menentu seperti saat membuat protokol. Jika Anda belum yakin apa yang Anda butuhkan, mulai lihat di sini. Tingkat pengembang memberi Anda biaya bulan dan tetapi yang rendah sekitar 50 dolar. Fitur angkat tetapi tanpa SAA. Ideal untuk lingkungan pengembangan dan pengujian. Anda mendapatkan semua yang dimiliki versi premium tetapi tidak bisa menggunakannya. Tingkat dasar adalah tingkat awal untuk produksi. Teruput lebih rendah tidak dukungan jaringan virtual tetapi Anda mendapatkan SLA yang nyata. Bagus untuk alat internal atau proyek kecil di mana jaringan pribadi tidak terlalu krusial. Kebanyakan bisnis memilih tingkat standar. Termasuk dukungan jaringan virtual, SLA 99.5% dan throughput yang baik. Jika Anda menjalankan API yang krusial bagi bisnis, disinilah Anda akan melakukan pilihan.

Tingkat premium ditujukan bagi perusahaan global yang membutuhkan reliability maksimal dan jaringan pribadi. Penyebaran multiwilayah, gateway yang dihost sendiri, SLA 99.99% dan injeksi jaringan virtual penuh. Dimulai dari sekitar 2.700 per bulan per unit. Microsoft juga memperkenalkan tingkat V2, Basic V2, Standard V2, dan Premium V2. Mereka menyederhanakan harga dengan kuota permintaan yang disertakan dan kelebihan per juta. Alih-alih melacak banyak pengukur Anda mendapatkan kuota permintaan yang jelas dan membayar kelebihan penggunaan dalam kenaikan sederhan. Berikut cara memilihnya. Mulai dengan tingkat developer untuk pengujian. Pindah ke standar untuk produksi. Pilih premium jika Anda memerlukan skala global atau jaringan pribadi. Dan ingat, Anda selalu dapat bermigrasi ke tingkat lain yang tinggi. Rata yang kecil dan berkembangan seri kebutuhan Anda. Ini yang telah kita bahas. Manajemen API mengatasi kekacauan berbagai API dan menyatukannya ke dalam satu pusat kendali untuk gateway kebijakan, keamanan, dan pengalaman pengembang.

Poin utamanya adalah ini lebih dari sekadar proksi. Anggap ini sebagai otak dan sistem saraf dari ekosistem API Anda. Tanpanya setiap tim membangun autentikasi, logging, dan pembetasan tarif mereka sendiri, Anda akan berakhir dengan ketidak konsistenan, celah keamanan, dan tidak adanya satu pandangan tunggal tentang apa yang terjadi. Dengannya, Anda mendapatkan konsistensi, keamanan, dan skalabilitas tanpa harus memulai dari awal untuk setiap layanan. Berikut adalah hatian sederhana. Pikirkan satu API yang saat ini Anda ekspos secara langsung. Mungkin titik akhir fungsi atau layanan aplikasi. Bagaimana menempatkan manajemen API di depannya dapat mengubah postur keamanan dan kemampuan Anda dalam memantau penggunaan. Bahkan hanya dengan memikirkan latihan itu akan menunjukkan nilainya pada langkah selanjutnya berlangganan ke seluruh ini. Pada episode mendatang, kami akan menunjukkan cara mengimpor API, menerapkan kebijakan pertama Anda, dan memantau penggunaan secara real-time.

Anda akan beralih dari teori ke praktik. Dan jika Anda merasa ini bermanfaat, bagikan kepada seseorang yang sedang memenuh. Itu akan menyambarkan mereka ada sakit kepala selama berbulan. Terima kasih telah mendengar. Terima kasih telah menonton!