Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Proksi adalah server perantara yang berada di antara klien (seperti aplikasi Anda) dan server tujuan (seperti API back-end). Saat aplikasi Anda mengirim permintaan, proksi menerimanya terlebih dahulu. Proksi kemudian dapat meneruskan permintaan ke server target, memodifikasinya, memblokirnya, atau mengembalikan respons secara langsung.
Singkatnya, proksi bertindak atas nama klien atau server untuk menengahi komunikasi.
Cara kerja proksi
Proksi beroperasi di tingkat HTTP (atau protokol aplikasi lainnya) dengan menerima permintaan masuk dan mengambil satu atau beberapa tindakan berikut:
- Meneruskan permintaan ke server target lalu menyampaikan respons kembali ke klien.
- Memodifikasi header, URL, atau payload sebelum meneruskan.
- Mencegat dan menanggapi permintaan secara lokal tanpa menghubungi server target.
- Menolak permintaan berdasarkan aturan atau kebijakan akses.
Dari perspektif klien, klien hanya mengirim permintaan ke URL. Proksi menangani segala sesuatu yang lain di belakang layar. Polanya adalah klien untuk melakukan proksi ke server target.
Pola ini memperkenalkan lapisan kontrol dan abstraksi yang dapat Anda gunakan untuk meningkatkan keamanan, pengamatan, performa, dan kemampuan uji.
Jenis proksi
Ada berbagai jenis proksi. Masing-masing cocok untuk peran tertentu dalam arsitektur sistem.
Meneruskan proksi
Proksi penerusan berada di depan klien . Ketika aplikasi Anda membuat permintaan, permintaan tersebut akan melalui proksi, yang memutuskan apakah akan dan bagaimana meneruskannya. Proksi penerusan umumnya digunakan untuk:
- Mengontrol akses ke sumber daya eksternal.
- Menganonimkan lalu lintas klien.
- Catat lalu lintas keluar untuk pemantauan.
- Terapkan pemfilteran atau transformasi konten.
Proksi terbalik
Proksi terbalik berada di depan server . Klien tidak menyadari infrastruktur back-end yang mendasar. Proksi terbalik menerima permintaan masuk dan meneruskannya ke salah satu dari beberapa server back-end. Proksi terbalik umumnya digunakan untuk:
- Sebarkan beban lalu lintas di antara beberapa layanan.
- Sajikan respons cache untuk mengurangi beban back-end.
- Hentikan koneksi TLS/SSL.
- Sembunyikan detail layanan internal dari internet publik.
Proksi transparan
Proksi transparan mencegat lalu lintas tanpa klien dikonfigurasi secara eksplisit untuk menggunakannya. Jenis ini digunakan di lingkungan perusahaan atau penyedia layanan internet untuk memberlakukan kebijakan atau memantau penggunaan.
Mengapa proksi penting bagi pengembang aplikasi
Seringkali tim infrastruktur atau jaringan mengelola proksi. Namun, proksi secara langsung memengaruhi perilaku aplikasi, terutama dalam lingkungan pengembangan dan pengujian. Berikut adalah beberapa cara praktis yang memengaruhi pekerjaan Sehari-hari Anda.
Penelusuran kesalahan dan pengamatan
Proksi dapat menangkap dan memeriksa lalu lintas HTTP. Alat seperti Dev Proxy, Fiddler, Proxyman, Charles Proxy, atau mitmproxy bertindak sebagai proksi penerusan lokal. Anda dapat menjalankan aplikasi Anda melalui mereka untuk menganalisis permintaan dan respons, menemukan kesalahan, dan memverifikasi header atau token autentikasi.
Gateway API dan perutean
Dalam banyak sistem produksi, lalu lintas ke back end aplikasi Anda dirutekan melalui API gateway atau proksi terbalik, seperti NGINX, atau layanan cloud-native seperti Azure API Management. Proksi ini menangani perutean, autentikasi, pembatasan laju, dan banyak lagi.
Saat merancang API atau membangun layanan terdistribusi, Anda harus memahami bagaimana proksi memengaruhi header (seperti X-Forwarded-For), batas waktu habis, dan permintaan ukuran.
CORS dan pengembangan lokal
Selama pengembangan lokal, terutama dalam aplikasi web, Anda mungkin mengalami pembatasan berbagi sumber daya lintas asal (CORS) saat Anda memanggil API dari browser. Proksi pengembangan dapat meneruskan permintaan Anda ke API target saat menulis ulang header untuk melewati batasan CORS. Contoh umum alat pengembang yang mengubah permintaan CORS adalah vite, webpack-dev-server, atau middleware proksi khusus dalam kerangka kerja seperti Express atau ASP.NET Core.
Virtualisasi dan pengujian layanan
Proksi dapat mensimulasikan API back-end. Kemampuan ini berguna ketika layanan nyata tidak tersedia, tidak stabil, atau mahal untuk digunakan selama pengujian. Dengan mencegat dan menipu respons, Anda dapat menguji perilaku aplikasi di bawah skenario yang berbeda seperti batas waktu, kesalahan, atau data yang salah bentuk.
Alat seperti Dev Proxy atau implementasi proksi kustom umumnya digunakan untuk tujuan ini dalam integrasi dan pengujian end-to-end.
Autentikasi dan keamanan
Proksi sering menjadi garis depan pertahanan dalam mengamankan aplikasi. Mereka dapat menerapkan kontrol akses, menyuntikkan header autentikasi, atau mengakhiri koneksi TLS/SSL. Sebagai pengembang, penting untuk mengetahui bagaimana aplikasi Anda bertingkah ketika berada di belakang proksi dan cara mengakses header yang membawa informasi autentikasi atau identitas.
Header Umum dan Pertimbangan Penggunaan Proksi
Saat permintaan melewati proksi, header tertentu ditambahkan atau dimodifikasi untuk mempertahankan metadata penting. Misalnya:
-
X-Forwarded-For: Menunjukkan alamat IP asli klien. -
X-Forwarded-Proto: Menunjukkan protokol asli (HTTP atau HTTPS). -
X-Forwarded-Host: Menunjukkan host asli yang diminta oleh klien.
Saat aplikasi Anda berjalan di belakang proksi terbalik, pastikan kerangka kerja atau platform Anda dikonfigurasi untuk mempercayai dan menginterpretasikan header ini dengan benar.
Gunakan proksi untuk menguji bagaimana aplikasi Anda menangani kegagalan API
Karena proksi penerusan melihat setiap permintaan yang dikirim aplikasi Anda, proksi juga dapat menjawab beberapa permintaan tersebut dengan respons kegagalan alih-alih meneruskannya: 500, 429 Too Many Requests dengan header Retry-After, atau respons yang membutuhkan waktu 8 detik. Aplikasi Anda terus memanggil URL API nyata, sehingga Anda menguji aplikasi saat berjalan dalam produksi, termasuk klien HTTP, SDK, dan kebijakan coba lagi.
Dibandingkan dengan cara lain untuk menguji kegagalan API:
| Approach | Apa yang Anda temukan | Yang Anda lewatkan |
|---|---|---|
| Tunggu mode produksi | Kegagalan aktual | Semuanya, sampai pengguna mengkliknya |
| Mock API dalam pengujian Anda, atau biarkan agen pengkodean Anda menulis mock | Apakah cabang error Anda berjalan atau tidak | Kode status API yang sebenarnya, header API, dan badan kesalahan API, serta kebijakan coba lagi SDK Anda. Aplikasi Anda juga memerlukan sakelar khusus pengujian untuk mengakses mock. |
| Panggil API yang sebenarnya dan berharap API itu gagal | Perilaku sebenarnya | Anda tidak dapat memicu kegagalan secara sengaja |
| Jalankan aplikasi Anda melalui proksi yang mensimulasikan kegagalan | Kesalahan, pembatasan, dan latensi pada URL nyata, saat diperlukan | Kode Anda secara terpisah. Simpan pengujian unit Anda untuk itu. |
Proksi Dev sebagai proksi penerusan untuk pengembangan dan pengujian
Dev Proxy adalah proksi penerusan yang Anda jalankan di komputer atau di CI untuk mencegat dan memodifikasi permintaan dari aplikasi Anda ke API yang Anda pilih. Dengan Dev Proxy, Anda dapat:
- Lihat bagaimana aplikasi Anda merespons kesalahan API.
- Verifikasi bagaimana aplikasi Anda menangani batas laju API dan pembatasan.
- Lihat cara aplikasi Anda menangani API lambat.
- Siapkan mock API tanpa menulis baris kode.
- Dapatkan panduan kontekstual tentang cara Anda menggunakan API.
Untuk mencobanya pada API yang dipanggil aplikasi Anda, unduh preset dan mulai Dev Proxy dengannya. Misalnya, untuk GitHub:
devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"
Preset juga tersedia untuk titik akhir OpenAI (openai-throttling), Anthropic (anthropic-throttling), dan Microsoft Graph OneDrive dan SharePoint (microsoft-graph-rate-limiting).
Cobalah sendiri
Pilih skenario yang cocok dengan apa yang Anda bangun:
- Uji bagaimana aplikasi Anda menangani kesalahan API (5 menit)
- Menyimulasikan pembatasan laju pada API apa pun (10 menit)
- Respons API tiruan tanpa mengubah kode Anda (10 menit)
- Gunakan model lokal alih-alih OpenAI saat Anda mengembangkan (15 menit)