REST vs GraphQL vs gRPC: kerangka keputusan untuk tahun 2026

Tim Anda memulai layanan baru. Seseorang membuka thread Slack: "Haruskah kita menggunakan GraphQL?" Orang lain menjawab dengan link ke benchmark gRPC. Utasnya terbagi menjadi tiga kubu. Dua jam kemudian, tidak ada keputusan.

Masalahnya bukan pada kurangnya informasi. Masalahnya adalah kurangnya kriteria. REST, GraphQL, dan gRPC masing-masing memecahkan bentuk masalah yang berbeda. Pilih yang salah dan Anda membayar pajak untuk setiap permintaan selama bertahun-tahun. Pilih yang tepat dan arsitekturnya menghilang ke latar belakang.

Panduan ini memberi Anda kerangka keputusan yang konkrit, bukan "tergantung". Setiap protokol menjadi spesifik kasus penggunaan yang menang, contoh kode yang dapat Anda jalankan, dan tabel perbandingan yang dapat Anda gunakan dokumen desain.

Kerangka 30 detik

Mulailah dengan tiga pertanyaan:

1. Siapa yang menyebut API ini? Pengembang eksternal, klien frontend Anda sendiri, atau layanan internal?
2. Berapa banyak bentuk data yang dibutuhkan klien? Satu bentuk tetap, atau banyak variasi?
3. Mana yang lebih penting: kemampuan cache, fleksibilitas kueri, atau throughput mentah?

Jawabannya dipetakan langsung ke protokol:

• ISTIRAHAT menang jika audiensnya bersifat eksternal, bentuk datanya tetap, dan penyimpanan cache penting.
• GrafikQL menang ketika banyak klien memerlukan potongan berbeda dari grafik data yang sama.
• gRPC menang ketika layanan internal berkomunikasi satu sama lain dan hasil lebih penting daripada keterbacaan manusia.

Berikut logika yang sama dengan kode:

REST: default universal

REST memetakan operasi ke kata kerja HTTP dan sumber daya ke URL. Setiap bahasa pemrograman memiliki klien HTTP. Setiap CDN memahami header cache. Setiap pengembang telah menggunakannya curl.

REST adalah pilihan tepat untuk API publik tempat Anda mengontrol bentuk data dan klien mengharapkan stabil, titik akhir yang terdokumentasi. 150+ titik akhir API botoi semuanya menggunakan REST. Berikut ini pencarian DNS:

Tanggapan:

Permintaannya adalah satu POST. Responsnya adalah objek JSON datar. Anda dapat mengujinya dengan curl, menyalurkannya melalui jq, atau menyebutnya dari bahasa apa pun dengan fetch. Tidak ada file skema untuk dikompilasi, tidak ada bahasa kueri untuk dipelajari, tidak ada langkah pembuatan kode.

Dimana REST bersinar

• API pengembang publik. Pengembang pihak ketiga mengharapkan REST. Biaya orientasi adalah nol.
• Sumber daya yang dapat di-cache. Caching HTTP berfungsi di setiap lapisan: browser, CDN, proxy terbalik. A GET /users/123 respons dengan header cache yang tepat tidak memerlukan biaya apa pun untuk permintaan berulang.
• Integrasi webhook. Webhook adalah permintaan HTTP POST. REST cocok dengan model mental.
• Operasi CRUD sederhana. Ketika setiap titik akhir melakukan satu hal dengan satu bentuk masukan dan satu bentuk keluaran, REST tidak menambahkan overhead.

Dimana REST gagal

• Pengambilan berlebihan. Aplikasi seluler yang memerlukan 3 bidang dari profil pengguna masih mengunduh objek 40 bidang penuh.
• Kurang mengambil. Dasbor yang menampilkan pengguna, timnya, dan aktivitas terkini mereka melakukan 3 panggilan HTTP berurutan. Latensi bertambah.
• Tidak ada evolusi skema bawaan. URL versi Anda (/v1/, /v2/) atau tambahkan kolom dan berharap klien mengabaikan kunci yang tidak diketahui.

GraphQL: kueri berbasis klien

GraphQL memungkinkan klien menentukan dengan tepat bidang mana yang dibutuhkan dalam satu permintaan. Server mengekspos skema yang diketik. Klien menulis kueri terhadap skema itu dan mendapatkan kembali respons yang sesuai.

API publik GitHub menunjukkan hal ini dengan baik. Satu kueri mengambil nama pengguna Anda dan 3 repositori teratas dengan jumlah bintang dan bahasa utama. Di REST, ini memerlukan setidaknya 2 panggilan.

Tanggapan:

Klien meminta name, stargazerCount, Dan primaryLanguage. Server mengembalikan bidang tersebut dengan tepat. Tidak ada data tambahan yang ditransfer. Tidak ada permintaan kedua.

Dimana GraphQL bersinar

• Aplikasi seluler. Bandwidthnya terbatas. Ukuran muatan penting. GraphQL menghilangkan pengambilan berlebihan di setiap layar.
• Tampilan dasbor dan agregasi. Satu kueri dapat mengambil data dari pengguna, pesanan, dan inventaris dalam satu perjalanan.
• Iterasi frontend yang cepat. Tim frontend mengubah kueri mereka tanpa menunggu tim backend membangun titik akhir baru.
• Pengetikan yang kuat. Skemanya adalah kontrak. Alat pembuat kode seperti GraphQL Code Generator menghasilkan tipe TypeScript darinya.

Dimana GraphQL gagal

• cache. Setiap kueri adalah POST ke /graphql. Caching HTTP di tingkat CDN atau browser tidak akan berfungsi tanpa lapisan kueri tetap atau kueri berbasis GET.
• Permukaan keamanan. Klien dapat menulis kueri mahal yang menggabungkan data yang sangat bertumpuk. Anda memerlukan analisis biaya kueri dan pembatasan kedalaman untuk mencegah penyalahgunaan.
• Kurva belajar. Pengembang perlu mempelajari bahasa kueri, desain skema, penyelesai, dan pola DataLoader. Waktu ramp-up lebih tinggi dari REST.
• N+1 kueri. Pola penyelesai naif memicu satu kueri database per item dalam daftar. Pengelompokan DataLoader memperbaikinya, tetapi Anda harus membuatnya sendiri.

gRPC: kecepatan internal

gRPC menggunakan Protocol Buffer untuk serialisasi dan HTTP/2 untuk transportasi. Anda menentukan layanan Anda kontrak di a .proto file, buat kode klien dan server, dan dapatkan panggilan RPC yang aman untuk tipe dengan muatan biner.

Dari definisi tersebut, protoc menghasilkan stub klien dan antarmuka server di Go, Java, Python, Rust, C++, atau selusin bahasa lainnya. Kode yang dihasilkan menangani serialisasi, deserialisasi, dan pembingkaian HTTP/2.

Dimana gRPC bersinar

• Komunikasi layanan-ke-layanan. Layanan mikro internal yang bertukar pesan berfrekuensi tinggi mendapat manfaat dari serialisasi biner dan aliran multipleks.
• Kontrak yang ketat. Itu .proto file adalah satu-satunya sumber kebenaran. Perubahan yang dapat menyebabkan gangguan ditangkap pada waktu kompilasi, bukan pada waktu proses.
• Streaming dua arah. gRPC mendukung streaming server, streaming klien, dan streaming dua arah. Fitur real-time seperti umpan transaksi langsung cocok secara alami.
• Lingkungan poliglot. Layanan Go dapat memanggil layanan Python melalui stub yang dihasilkan tanpa kode serialisasi manual.

Dimana gRPC gagal

• Dukungan peramban. Browser tidak dapat melakukan panggilan gRPC asli. Proksi grpc-web menambahkan lapisan kompleksitas dan latensi.
• Keterbacaan manusia. Muatan biner tidak dapat diperiksa curl atau alat pengembang browser. Debugging memerlukan alat khusus seperti grpcurl atau Bloom RPC.
• Kematangan ekosistem. REST memiliki peralatan selama puluhan tahun: Tukang pos, Swagger, gateway API, pembatas kecepatan. Peralatan gRPC terus berkembang namun tidak pada tingkat yang sama.
• Kurva belajar. Tim harus mempelajari Protocol Buffer, sintaksis proto3, pipeline pembuatan kode, dan pola penanganan error khusus gRPC.

Tabel perbandingan

Contoh keputusan dunia nyata

Stripe: REST untuk pembayaran

Stripe memproses pembayaran miliaran dolar melalui REST API. Titik akhir mereka dapat diprediksi pola: POST /v1/payment_intents, GET /v1/charges/:id. Setiap pengembang yang mengintegrasikan Stripe mengetahui HTTP. Gesekan orientasi mendekati nol. Stripe memilih REST karena audiens mereka adalah pengembang eksternal yang membutuhkan titik akhir yang stabil, terdokumentasi, dan dapat disimpan dalam cache.

GitHub: GraphQL untuk alat pengembang

GitHub bermigrasi dari REST (v3) ke GraphQL (v4) karena kliennya (aplikasi desktop, aplikasi seluler, integrasi pihak ketiga) semuanya memerlukan data berbeda dari objek yang sama. Alat CI perlu dilakukan status dan pemeriksaan berjalan. Aplikasi manajemen proyek memerlukan masalah, label, dan penerima tugas. Sebuah aplikasi seluler membutuhkan tampilan profil minimal. Satu titik akhir REST tidak dapat melayani ketiganya tanpa pengambilan berlebihan secara besar-besaran.

Google: gRPC untuk layanan internal

Google membuat gRPC ("g" adalah singkatan dari kata yang berbeda setiap rilis) untuk menangani layanan-ke-layanan internal komunikasi dalam skala besar. Saat mesh layanan Anda memproses jutaan RPC per detik, bedanya antara penguraian teks JSON dan deserialisasi biner Protocol Buffer itu penting. Google memilih gRPC karena audiensnya bersifat internal, kontraknya ketat, dan hasil adalah kendala utama.

Mengapa botoi memilih REST untuk 150+ titik akhir

API botoi melayani titik akhir utilitas independen: pencarian DNS, validasi email, pemformatan JSON, kode QR generasi, perhitungan hash. Setiap titik akhir mengambil masukan tertentu dan mengembalikan keluaran tertentu. Tidak ada grafik data relasional yang menghubungkan data DNS ke kode QR.

Tiga faktor menjadikan REST pilihan yang jelas:

• Dukungan klien universal. Pengembang menyebut botoi dari Node.js, Python, Go, Ruby, PHP, skrip shell, dan agen AI. REST berfungsi di semuanya tanpa pengaturan apa pun.
• Kemampuan cache. DAPATKAN titik akhir untuk sumber daya statis (seperti pencarian negara atau daftar mata uang) manfaat dari cache HTTP pada lapisan CDN. Ini menjaga waktu respons di bawah 20 ms untuk permintaan berulang.
• Kemampuan untuk ditemukan. Setiap titik akhir memiliki URL yang stabil, entri spesifikasi OpenAPI, dan interaktif dokumen melalui Scalar. Pengembang baru menemukan dan menguji titik akhir dalam waktu kurang dari satu menit.

GraphQL akan menambah kompleksitas tanpa manfaat. Tidak ada grafik kueri untuk dilintasi. gRPC akan melakukannya kecualikan klien browser dan skrip shell. REST adalah alat yang tepat untuk masalah seperti ini.

Mencampur protokol dalam satu sistem

Kerangka kerja ini berlaku per batasan, bukan per organisasi. Banyak sistem produksi menggabungkan protokol:

• Lapisan API eksternal: ISTIRAHAT. Pengembang dan webhook pihak ketiga mengharapkan HTTP + JSON.
• Gerbang yang menghadap klien: GrafikQL. Klien seluler dan web menanyakan gateway yang mengumpulkan data dari beberapa layanan.
• Jaring layanan internal: gRPC. Layanan backend berkomunikasi dengan muatan biner dan kontrak yang ketat.

Ini bukan kompleksitas demi kompleksitas. Setiap batasan mempunyai audiens yang berbeda dengan yang berbeda-beda kendala. Protokol harus sesuai dengan batasannya, bukan sebaliknya.

Daftar periksa keputusan

Salin ini ke dokumen desain Anda. Jawab setiap pertanyaan, dan pilihan protokol menjadi jelas.

1. Siapa konsumen API? Pengembang eksternal (REST), tim frontend Anda sendiri (GraphQL), layanan internal (gRPC).
2. Berapa banyak bentuk data yang diminta klien? Satu bentuk (REST), banyak bentuk (GraphQL), kontrak tetap (gRPC).
3. Apakah cache HTTP penting? Ya (REST), terkadang (GraphQL dengan susah payah), tidak (gRPC).
4. Apakah Anda memerlukan streaming? Tidak (REST baik-baik saja), langganan (GraphQL), dua arah (gRPC).
5. Bahasa apa yang digunakan klien? Semuanya (REST), JS/TS-heavy (perkakas GraphQL paling kuat di sini), poliglot dengan pembuatan kode (gRPC).
6. Apa keahlian tim saat ini? Jika tidak ada yang mengetahui Protocol Buffer, gRPC memerlukan biaya peningkatan yang besar. Jika tidak ada yang tahu pemecah masalah GraphQL, tunggu satu bulan pembelajaran sebelum kesiapan produksi.

Kesalahan umum yang harus dihindari

• Memilih GraphQL karena terasa baru. GraphQL menambahkan kompleksitas penyelesai, kueri analisis biaya, dan mitigasi N+1. Jika API Anda memiliki 10 titik akhir CRUD dengan bentuk tetap, REST memilikinya pekerjaan yang sama dengan lebih sedikit kode.
• Memilih gRPC untuk API publik. Pengguna Anda tidak dapat memanggil gRPC dari browser curl, atau dari alat berkode rendah. Anda akhirnya akan membangun gerbang REST di depannya.
• Memilih REST untuk grafik data yang kompleks. Jika tim frontend Anda meminta 5 yang baru titik akhir "ringkasan" per sprint karena titik akhir yang sudah ada mengembalikan terlalu banyak atau terlalu sedikit data, itu pertanda GraphQL akan mengurangi overhead koordinasi.
• Mengabaikan keahlian tim. Protokol tercepat untuk dikirimkan adalah protokol tim Anda sudah tahu. Tim yang fasih dalam REST yang beralih ke gRPC akan menghabiskan waktu berminggu-minggu untuk membuat alat sebelumnya menulis logika bisnis.