API-Based Architecture

Kamu baru saja menyelesaikan fitur baru untuk aplikasi mobile. Di laptop, semuanya berjalan mulus. Sekarang saatnya menghubungkan aplikasi itu ke server backend yang sudah berjalan di production. Kamu membuka dokumentasi internal, mencari endpoint yang tepat, lalu mulai menulis kode untuk mengirim request HTTP.

Tidak lama kemudian, tim frontend lain datang dengan pertanyaan: “Endpoint untuk data pengguna ada di mana?” Lalu tim integrasi dari mitra bisnis juga bertanya: “Kami perlu akses ke data pesanan, API-nya pakai format apa?”

Semua tim ingin mengakses fungsi yang sama, tetapi dari klien yang berbeda: web, mobile, bahkan aplikasi pihak ketiga. Setiap kali ada perubahan di backend, semua klien harus menyesuaikan. Setiap kali ada klien baru, backend harus menyediakan jalur akses baru. Tanpa pola yang jelas, situasi ini cepat berubah menjadi kusut.

Masalah yang Diselesaikan Pola Ini

Masalah intinya sederhana: bagaimana cara membuka akses ke fungsi bisnis dari berbagai klien tanpa membuat backend menjadi kusut dan tanpa membuat setiap klien harus tahu detail internal sistem?

Cara lama seringkali membuat backend dan klien menempel erat. Klien web memanggil fungsi langsung dari server. Klien mobile harus tahu struktur database. Pihak ketiga diberi akses langsung ke service internal. Akibatnya, perubahan kecil di backend bisa memaksa update di semua klien. Keamanan harus diurus berulang di setiap tempat. Tidak ada batas yang jelas antara “apa yang boleh dipanggil dari luar” dan “apa yang hanya untuk internal.”

API-Based Architecture memecahkan masalah ini dengan satu keputusan desain: semua fungsi bisnis yang boleh diakses dari luar diekspos melalui antarmuka yang terstandarisasi, yaitu API. Klien tidak perlu tahu bagaimana fungsi itu dijalankan di dalam. Mereka cukup tahu alamat endpoint, format request, dan bentuk response yang diharapkan.

Komponen Utama

Dalam arsitektur ini, ada empat lapisan yang bekerja bersama.

API Consumers adalah pihak yang memulai komunikasi. Mereka bisa berupa web app yang berjalan di browser, mobile app di ponsel pengguna, atau third-party client dari mitra bisnis. Semua konsumen ini berkomunikasi dengan cara yang sama: mengirim request HTTP ke endpoint yang sudah ditentukan.

API Gateway menjadi pintu masuk tunggal untuk semua request. Gateway ini menangani urusan yang sifatnya lintas konsumen: siapa yang boleh akses, berapa banyak request yang bisa dikirim dalam satu waktu, dan ke mana request harus diteruskan. Rate limiter memastikan tidak ada satu klien yang membanjiri sistem. Auth handler memeriksa token atau API key sebelum request diteruskan. Request router menentukan service mana yang harus menangani request tersebut.

API Services adalah inti dari arsitektur ini. Di sinilah logika bisnis berada. User Service menangani data dan fungsi terkait pengguna. Order Service mengelola pesanan. Payment Service memproses pembayaran. Setiap service mengekspos endpoint REST yang mengembalikan response dalam format JSON. Service-service ini dominan dalam arsitektur karena mereka yang melakukan pekerjaan nyata.

Data Stores adalah tempat data disimpan dan diambil. SQL Database dipakai untuk data yang membutuhkan relasi dan transaksi. NoSQL Database untuk data yang lebih fleksibel atau perlu skala besar. Cache seperti Redis atau CDN dipakai untuk menyimpan data yang sering diakses agar response lebih cepat.

Alur Kerja

Alur kerja dalam arsitektur ini mengalir dari kiri ke kanan. API Consumers mengirim request HTTP ke API Gateway. Gateway memeriksa otentikasi, memastikan request tidak melebihi batas rate, lalu meneruskan ke API Services yang sesuai. Services memproses request, berkomunikasi dengan Data Stores jika perlu, lalu mengembalikan response JSON ke Gateway. Gateway kemudian mengirimkan response itu kembali ke konsumen.

Alur ini terdengar sederhana, dan memang seharusnya begitu. Kesederhanaan inilah yang membuat arsitektur ini mudah dipahami dan diadopsi.

Kapan Pola Ini Cocok Dipakai

API-Based Architecture sangat cocok untuk situasi di mana sistem perlu diakses dari berbagai jenis klien. Public API yang dibuka untuk developer eksternal adalah contoh paling jelas. Mobile backend yang melayani aplikasi iOS dan Android juga pas dengan pola ini.

Arsitektur ini juga cocok untuk komunikasi antar microservice. Setiap service mengekspos API-nya sendiri, dan service lain cukup memanggil endpoint yang tersedia. Integrasi pihak ketiga juga menjadi lebih rapi karena mitra hanya perlu mengikuti kontrak API yang sudah ditentukan.

Keunggulan utama pola ini adalah ringan, tidak terikat bahasa pemrograman tertentu, mudah diskalakan, dan didukung oleh banyak tool. Selama klien bisa mengirim HTTP dan memahami JSON, mereka bisa berkomunikasi dengan sistem.

Trade-off, Batasan, dan Risiko Operasional

Tidak ada arsitektur yang sempurna. API-Based Architecture punya kelemahan yang perlu kamu sadari.

Yang pertama adalah masalah chatty communication. Karena setiap interaksi adalah request-response HTTP, operasi yang membutuhkan banyak panggilan bolak-balik bisa menjadi lambat. Bayangkan aplikasi mobile yang perlu memanggil sepuluh endpoint berbeda hanya untuk menampilkan satu halaman. Latensi menumpuk.

Kedua, arsitektur ini tidak memiliki state management bawaan. Setiap request harus membawa informasi yang cukup untuk diproses secara mandiri. Jika kamu perlu menyimpan state antar request, kamu harus mengelolanya sendiri, misalnya dengan token atau session store.

Ketiga, versioning API bisa menjadi kompleks. Ketika endpoint berubah, klien lama mungkin masih bergantung pada versi lama. Kamu harus menjaga beberapa versi API tetap berjalan sampai semua klien migrasi. Ini menambah beban operasional.

Dari sisi operasional, API Gateway bisa menjadi single point of failure jika tidak dirancang dengan baik. Rate limiting dan autentikasi yang salah konfigurasi bisa memblokir akses yang sah. Keamanan juga perlu perhatian ekstra: OAuth2 atau JWT untuk otentikasi, API keys untuk identifikasi klien, TLS untuk enkripsi, dan throttling untuk mencegah penyalahgunaan.

Implikasi Praktis untuk Tim Engineering

Jika tim kamu memutuskan memakai pola ini, ada beberapa keputusan praktis yang perlu diambil.

Pertama, putuskan format kontrak API sejak awal. OpenAPI (sebelumnya Swagger) adalah pilihan umum untuk mendokumentasikan endpoint, format request, dan struktur response. Kontrak ini menjadi acuan bersama antara tim backend dan tim klien.

Kedua, rencanakan strategi versioning. Beberapa tim menaruh nomor versi di URL (/v1/users), beberapa di header request. Pilih satu dan konsisten.

Ketiga, siapkan infrastruktur untuk horizontal scaling. Karena service dalam arsitektur ini idealnya stateless, kamu bisa menambah instance service saat beban naik. Cache di Gateway atau di layer Data Stores membantu mengurangi beban ke database.

Keempat, jangan lupakan monitoring. Kamu perlu tahu endpoint mana yang lambat, service mana yang error, dan klien mana yang mengirim request bermasalah. Tanpa visibilitas, operasional API-Based Architecture bisa terasa seperti mengemudi buta.

Terakhir, sadari bahwa pola ini tidak cocok untuk semua situasi. Real-time streaming, komunikasi dengan frekuensi sangat tinggi dan latensi sangat rendah, atau workflow transaksional yang kompleks mungkin lebih baik ditangani dengan pola arsitektur lain.