RPC Adalah: Pengertian, Cara Kerja & Bedanya dari REST

Setiap program, sekecil apa pun, tersusun dari kumpulan fungsi yang saling memanggil. Saat aplikasi toko daring menjalankan hitungOngkir(berat, kotaTujuan), prosesor melompat ke potongan kode tersebut, menghitung, lalu mengembalikan angka ongkos kirim dalam hitungan nanodetik. Semua terjadi di dalam satu komputer dan satu ruang memori yang sama.

Persoalannya muncul ketika fungsi itu tidak lagi berada di komputer yang sama. Tarif ongkir mungkin dihitung oleh server perusahaan ekspedisi, saldo tersimpan di server bank, dan riwayat transaksi kripto tersebar di ribuan node blockchain. Program Anda tetap ingin "memanggil fungsi", tetapi kini harus melewati jaringan.

Di sinilah RPC berperan. RPC adalah cara agar sebuah program bisa memanggil fungsi yang berjalan di komputer lain dengan gaya yang hampir sama seperti memanggil fungsi miliknya sendiri. Artikel ini membahas cara kerjanya, contoh pesan nyata, bedanya dengan REST, serta di titik mana janji "semudah fungsi lokal" itu mulai bocor.

Apa Itu RPC?

Kepanjangan RPC adalah Remote Procedure Call, yang artinya pemanggilan prosedur jarak jauh. Istilah procedure di sini sama maknanya dengan fungsi atau method dalam bahasa pemrograman modern. Jadi, kalau ada yang bertanya apa itu RPC, jawaban singkatnya adalah teknik komunikasi antarprogram yang dibungkus dalam bentuk pemanggilan fungsi.

Ciri terpenting RPC adalah location transparency (transparansi lokasi). Developer cukup menulis saldo = bank.cekSaldo(nomorRekening), dan baris itu terlihat sama persis dengan pemanggilan fungsi biasa. Urusan membuka koneksi, mengemas data, mengirimnya lewat jaringan, dan membaca balasan dikerjakan oleh pustaka RPC di belakang layar.

Hubungannya mengikuti pola client-server: program yang memanggil disebut klien, sedangkan program yang menjalankan fungsinya disebut server.

Singkatan RPC juga dipakai di dunia perbankan, misalnya Repayment Capacity dalam penilaian kredit dan KPR. Maknanya sama sekali berbeda. Seluruh pembahasan di artikel ini merujuk pada RPC di bidang komputasi dan jaringan.

Dari Xerox PARC ke Dompet Kripto: Perjalanan Singkat RPC

Gagasan RPC lahir dari laboratorium riset, bukan dari industri web. Istilah remote procedure call dicetuskan Bruce Jay Nelson pada 1981. Pada Februari 1984, ia dan Andrew Birrell dari Xerox PARC menerbitkan makalah "Implementing Remote Procedure Calls". Sistem mereka memakai alat bernama Lupine untuk membuat kode perantara secara otomatis, pola yang masih dipakai hampir semua sistem RPC hingga sekarang.

Sejak itu, kemasannya terus berganti sementara gagasannya tetap:

1. Sun RPC (ONC RPC), awal 1980-an: menjadi fondasi NFS (Network File System) dan spesifikasinya masih diperbarui lewat RFC 5531 pada 2009.
2. XML-RPC, 1998: membawa RPC ke atas HTTP dengan pesan berformat XML.
3. JSON-RPC 2.0, 2010: versi yang lebih ringkas dengan format JSON.
4. gRPC, 2015: dibuka Google sebagai open source, berangkat dari sistem internal bernama Stubby yang sudah mereka pakai lebih dari satu dekade.
5. MCP, 2024: protokol yang menghubungkan asisten AI dengan alat eksternal, dan seluruh pesannya memakai JSON-RPC 2.0.

Cara Kerja RPC: Stub, Marshalling, dan Perjalanan Satu Panggilan

Untuk memahami cara kerja RPC, kita perlu mengenal dua komponen perantara yang disebut stub. Client stub adalah potongan kode di sisi klien yang berpura-pura menjadi fungsi aslinya. Server stub adalah pasangannya di sisi server, yang menerima pesan lalu memanggil fungsi sesungguhnya.

Kedua stub ini jarang ditulis manual. Developer mendeskripsikan fungsi yang tersedia beserta parameter dan tipe datanya dalam berkas IDL (Interface Definition Language). Setelah itu, alat pembuat kode menghasilkan stub untuk berbagai bahasa pemrograman sekaligus.

Berikut perjalanan satu panggilan RPC dari awal sampai akhir:

1. Klien memanggil client stub: dari sudut pandang kode, ini pemanggilan fungsi lokal biasa.
2. Stub mengemas parameter: proses ini disebut marshalling, yaitu mengubah nama fungsi dan parameter menjadi deretan byte berformat JSON, XML, atau biner.
3. Pesan dikirim lewat jaringan: memakai transport seperti TCP, UDP, atau HTTP.
4. Server stub membongkar pesan: proses ini disebut unmarshalling, lalu stub memanggil fungsi aslinya.
5. Fungsi dijalankan: nilai kembalian atau pesan error dikemas lagi, lalu dikirim balik.
6. Klien menerima hasil: client stub membongkar balasan dan menyerahkannya ke kode pemanggil, seolah fungsi lokal baru saja selesai.

RPC tidak menggantikan TCP/IP, melainkan berdiri di atasnya. Buku ajar model OSI biasa menempatkannya di lapisan session. Klien juga harus tahu ke port mana pesan dikirim. Sun RPC memakai portmapper (rpcbind) di port 111 sebagai buku alamat. Windows memakai RPC Endpoint Mapper di port TCP 135, yang menunjukkan port dinamis layanan tujuan di rentang 49152–65535.

Membedah Satu Panggilan JSON-RPC

Teori di atas lebih mudah dipahami dengan melihat pesannya langsung. Kita pakai JSON-RPC 2.0 karena pesannya berupa teks JSON yang bisa dibaca manusia.

Contoh berikut memanggil fungsi eth_blockNumber pada node Ethereum publik untuk menanyakan nomor blok terbaru. Anda bisa menjalankannya langsung dari terminal karena endpoint ini terbuka tanpa API key:

curl -X POST \
  https://ethereum-rpc.publicnode.com \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc": "2.0",
    "method": "eth_blockNumber",
    "params": [], "id": 1}'

Server membalas dengan pesan seperti di bawah ini. Angkanya akan berbeda di komputer Anda karena blok baru terus terbentuk.

{"jsonrpc": "2.0", "result": "0x18ebfc0", "id": 1}

Nilai 0x18ebfc0 adalah bilangan heksadesimal yang setara dengan blok nomor 26.132.416 saat kami mengujinya pada Oktober 2026. Perhatikan bahwa tidak ada URL seperti /blocks/latest. Semua panggilan dikirim ke satu alamat yang sama, dan yang membedakan hanya isi field method.

Empat field dalam permintaan tadi punya tugas masing-masing:

1. jsonrpc: versi protokol, wajib bernilai "2.0".
2. method: nama fungsi yang dipanggil di server.
3. params: parameter fungsi, berupa array atau objek. Array kosong berarti fungsi tidak membutuhkan parameter.
4. id: penanda yang dikembalikan utuh di balasan, supaya klien bisa mencocokkan jawaban dengan pertanyaannya.

Kalau nama fungsinya salah, server tidak membalas dengan kode HTTP 404 seperti pada REST. Status HTTP tetap 200, dan kegagalannya dilaporkan di dalam objek error:

{
  "jsonrpc": "2.0",
  "id": 2,
  "error": {
    "code": -32601,
    "message": "the method eth_tebakAngka does not exist/is not available"
  }
}

Spesifikasi JSON-RPC 2.0 mencadangkan lima kode error baku. Kode -32700 berarti JSON tidak valid dan -32600 berarti struktur permintaan salah. Kode -32601 berarti fungsi tidak ditemukan, -32602 parameter tidak valid, dan -32603 kesalahan internal.

Permintaan tanpa field id disebut notification, dan server tidak akan membalasnya. Beberapa permintaan juga bisa dibungkus dalam satu array JSON (batch) supaya terkirim sekaligus.

Jenis-Jenis Implementasi RPC

RPC adalah konsep, bukan satu produk. Implementasinya berbeda dalam format pesan, transport, dan lingkungan tempat ia lazim dipakai.

ONC RPC dan NFS

ONC RPC (Open Network Computing), yang dulu dikenal sebagai Sun RPC, adalah salah satu implementasi tertua yang masih aktif. Data dikemas dalam format biner XDR (External Data Representation) dan bisa dikirim lewat TCP maupun UDP. Setiap kali server Linux me-mount folder bersama lewat NFS, protokol inilah yang bekerja di bawahnya.

Microsoft RPC

Windows memakai turunan DCE/RPC yang disebut MSRPC. Pengelolaan layanan jarak jauh, replikasi Active Directory, hingga proses bergabung ke domain bergantung padanya.

XML-RPC dan JSON-RPC

Keduanya membawa RPC ke atas HTTP dengan format teks. XML-RPC memakai XML yang lebih panjang, dan masih tertanam di WordPress lewat berkas xmlrpc.php yang kami bahas tersendiri di artikel XML-RPC. JSON-RPC lebih ringkas dan kini menjadi format pilihan untuk node blockchain, alat AI, serta editor kode.

gRPC dan Protocol Buffers

gRPC adalah kerangka RPC open source dari Google yang berjalan di atas HTTP/2 dan mengemas data dalam format biner Protocol Buffers. Kontraknya ditulis di berkas .proto. Contoh berikut mendefinisikan layanan ongkir dengan satu fungsi Hitung:

syntax = "proto3";

service Ongkir {
  rpc Hitung (Permintaan) returns (Hasil);
}

message Permintaan {
  int32 berat_gram = 1;
  string kota_tujuan = 2;
}

message Hasil {
  int64 biaya_rupiah = 1;
}

Dari berkas ini, kompiler protoc membuat stub klien dan server untuk bahasa seperti Go, Java, Python, atau Node.js. Selain pola satu permintaan satu jawaban, gRPC mendukung streaming dari server, dari klien, atau dua arah sekaligus. Kemampuan ini membuatnya populer untuk komunikasi antarlayanan di arsitektur microservices.

Apache Thrift, Java RMI, dan tRPC

Apache Thrift lahir di Facebook dengan gagasan mirip gRPC. Java RMI (Remote Method Invocation) khusus untuk program Java. Sementara itu, tRPC populer di kalangan developer TypeScript karena tipe data fungsi server langsung terbaca di kode klien tanpa berkas IDL.

Contoh RPC yang Sudah Anda Pakai Sehari-hari

Banyak orang mengira RPC hanya urusan engineer sistem terdistribusi. Kenyataannya, kemungkinan besar Anda sudah memakainya hari ini:

1. Dompet kripto: RPC URL yang diminta MetaMask saat menambah jaringan adalah endpoint JSON-RPC sebuah node blockchain. Dompet memanggil fungsi seperti eth_getBalance ke alamat itu setiap kali menampilkan saldo. Penyedia seperti Alchemy atau QuickNode pada dasarnya menjual akses ke server RPC semacam ini.
2. Asisten AI: MCP (Model Context Protocol) memakai JSON-RPC 2.0 untuk seluruh pesan antara aplikasi AI dan server alat.
3. Editor kode: Pelengkap otomatis dan fitur "go to definition" di VS Code bekerja lewat Language Server Protocol, yang isi pesannya juga JSON-RPC.
4. Jaringan kantor berbasis Windows: Bergabung ke domain, replikasi Active Directory, dan administrasi jarak jauh mengandalkan MSRPC di port 135.
5. Server Linux dengan penyimpanan bersama: Folder NFS yang di-mount di banyak server berjalan di atas ONC RPC.

RPC vs REST: Memanggil Aksi atau Mengelola Sumber Daya

RPC dan REST sama-sama bisa berjalan di atas HTTP dan sama-sama dipakai untuk membangun API. Perbedaannya ada pada cara berpikir. RPC berpusat pada aksi: Anda memanggil kata kerja seperti batalkanPesanan. REST API berpusat pada sumber daya: Anda mengubah kata benda seperti /pesanan/881 memakai metode HTTP baku.

Bandingkan dua permintaan dengan tujuan yang sama, yaitu membatalkan pesanan nomor 881. Gaya RPC memanggil nama aksinya:

POST /rpc
{
  "jsonrpc": "2.0",
  "method": "batalkanPesanan",
  "params": {"id": 881},
  "id": 7
}

Gaya REST mengubah status sumber dayanya:

PATCH /pesanan/881
{"status": "dibatalkan"}

Tabel berikut merangkum perbedaan keduanya:

Tidak ada yang lebih unggul secara mutlak. Banyak perusahaan memakai REST untuk API publik dan gRPC untuk komunikasi di dalam data center mereka.

Kelebihan RPC

1. Kode klien terasa natural: Developer cukup memanggil fungsi, tanpa merakit URL, header, dan body secara manual setiap kali.
2. Kontrak tegas sejak awal: Dengan IDL, nama fungsi dan tipe parameter terkunci, sehingga salah tipe ketahuan saat kompilasi.
3. Satu kontrak untuk banyak bahasa: Berkas .proto yang sama bisa menghasilkan stub Go untuk server dan stub Kotlin untuk aplikasi Android.
4. Pesan lebih hemat: Format biner seperti Protocol Buffers lebih kecil dan lebih cepat diproses dibanding JSON.
5. Mendukung streaming: gRPC bisa mengalirkan data dua arah dalam satu koneksi, berguna untuk notifikasi waktu nyata atau pengiriman data sensor.

Kelemahan RPC dan Hal yang Perlu Dipertimbangkan

Janji terbesar RPC sekaligus menjadi sumber masalah terbesarnya. Karena panggilan jarak jauh dibuat terlihat seperti panggilan lokal, developer mudah lupa bahwa di antara keduanya ada jaringan yang bisa lambat, putus, atau kehilangan pesan.

Kegagalan Parsial: Terkirim, tetapi Hasilnya Tidak Diketahui

Panggilan fungsi lokal hanya punya dua kemungkinan, yaitu berhasil atau gagal. Panggilan RPC punya kemungkinan ketiga yang jauh lebih merepotkan. Bayangkan klien memanggil transfer(100000), server menjalankannya, tetapi balasan hilang karena koneksi putus. Dari sisi klien, situasi ini terlihat persis sama dengan permintaan yang tidak pernah sampai.

Kalau klien mencoba ulang, uang bisa terkirim dua kali. Kalau tidak, klien mengira transfer gagal padahal sudah terjadi. RFC 5531 menegaskan bahwa RPC tidak menjamin keandalan apa pun. Server hanya bisa mendekati semantik at-most-once (dijalankan paling banyak sekali) dengan mengingat ID transaksi yang sudah diproses.

Solusinya adalah merancang fungsi yang idempotent, yaitu fungsi yang aman dipanggil berkali-kali dengan hasil akhir yang sama. Untuk aksi yang tidak idempotent secara alami seperti transfer, klien menyertakan kunci unik (idempotency key) di setiap permintaan. Dengan kunci itu, server bisa mengenali permintaan ulang dan menolak eksekusi kedua.

Latensi Jauh di Atas Panggilan Lokal

Panggilan fungsi lokal selesai dalam hitungan nanodetik. Panggilan RPC di dalam satu data center membutuhkan ratusan mikrodetik sampai beberapa milidetik, dan lintas benua bisa ratusan milidetik. Selisihnya puluhan ribu kali lipat atau lebih. Fungsi RPC yang dipanggil di dalam perulangan 1.000 kali, dengan 2 milidetik per panggilan, menahan halaman selama 2 detik.

Keterikatan antara Klien dan Server

Mengganti nama fungsi atau mengubah tipe parameter bisa membuat klien lama gagal total. Tim perlu disiplin mengelola versi, misalnya hanya menambah field baru dan tidak pernah mengubah nomor field Protocol Buffers yang sudah dipakai.

Sulit Diamati dari Browser

Browser tidak bisa memanggil gRPC secara langsung tanpa lapisan perantara seperti gRPC-Web. Pesan binernya juga tidak terbaca di tab Network, sehingga debugging membutuhkan alat khusus seperti grpcurl.

Pintu yang Terbuka ke Internet

Port RPC yang terbuka ke publik adalah sasaran klasik. Port 135 Windows menjadi jalur penyebaran worm Blaster pada 2003. Sementara itu, rpcbind di port 111 bisa dipakai penyerang untuk memetakan layanan yang berjalan di server.

Kapan Memilih RPC, Kapan Tidak

Sebagai pegangan praktis, berikut panduan yang kami sarankan:

1. Komunikasi antarlayanan internal: pilih gRPC bila layanan saling memanggil ratusan kali per detik dan ditulis dalam dua bahasa pemrograman atau lebih.
2. API untuk publik dan aplikasi web: pilih REST, karena lebih familier bagi developer pihak ketiga dan respons GET bisa di-cache.
3. Integrasi ringan berbasis aksi: JSON-RPC cocok untuk alat AI, node blockchain, atau panel kendali yang perintahnya berupa "jalankan tugas X".
4. Selalu pasang batas waktu: misalnya 300–500 milidetik untuk layanan internal di data center yang sama, dan 2–5 detik untuk layanan pihak ketiga. Tanpa deadline, satu layanan yang macet bisa menahan seluruh rantai panggilan.
5. Batasi percobaan ulang: ulangi maksimal 3 kali dengan jeda yang makin panjang, misalnya 100, 200, lalu 400 milidetik. Lakukan hanya untuk fungsi yang idempotent atau yang membawa kunci idempotensi.
6. Jangan buka port RPC ke internet: port 111 dan 135 cukup diizinkan dari jaringan internal lewat firewall. Untuk gRPC yang harus diakses dari luar, wajibkan TLS dan autentikasi.

Pertanyaan yang Sering Muncul

Apa bedanya RPC dan API?

API adalah istilah umum untuk antarmuka yang memungkinkan dua program berkomunikasi. RPC adalah salah satu gaya membangun API, sejajar dengan REST dan GraphQL. Jadi, setiap layanan RPC adalah API, tetapi tidak setiap API memakai gaya RPC.

Apakah RPC sama dengan gRPC?

Tidak. RPC adalah konsepnya, sedangkan gRPC adalah salah satu implementasinya yang dikembangkan Google. Huruf "g" pada namanya bahkan diberi kepanjangan berbeda di setiap versi rilis.

Apa arti pesan "The RPC server is unavailable" di Windows?

Pesan ini berarti komputer Anda gagal menghubungi layanan RPC di komputer tujuan. Penyebab paling umum adalah port 135 atau rentang 49152–65535 diblokir firewall. Penyebab lain: layanan Remote Procedure Call di komputer tujuan mati, atau nama komputernya gagal diterjemahkan DNS.

RPC di MetaMask itu apa, dan apakah aman menggantinya?

RPC URL adalah alamat server yang dipakai dompet untuk membaca data dan mengirim transaksi ke blockchain. Kunci privat tetap di perangkat karena transaksi ditandatangani sebelum dikirim. Namun, penyedia RPC bisa melihat alamat dompet dan IP Anda, dan RPC palsu bisa menampilkan data keliru. Pakai RPC URL dari dokumentasi resmi jaringan.

Apakah RPC selalu memakai HTTP?

Tidak. ONC RPC bisa berjalan langsung di atas TCP atau UDP. JSON-RPC bahkan bisa dikirim lewat standard input/output antarproses di satu komputer, seperti pada MCP dan Language Server Protocol. Yang memang berbasis HTTP adalah gRPC dan XML-RPC.

Kesimpulan

RPC adalah cara memanggil fungsi di komputer lain dengan gaya yang menyerupai pemanggilan fungsi lokal, berkat stub yang mengurus marshalling dan pengiriman lewat jaringan. Gagasan dari 1984 ini masih hidup dalam ONC RPC, MSRPC, JSON-RPC, gRPC, hingga protokol AI terbaru.

Gunakan RPC, khususnya gRPC, untuk komunikasi internal yang padat dan membutuhkan kontrak ketat, dan tetap pilih REST untuk API publik. Apa pun implementasinya, perlakukan setiap panggilan RPC sebagai panggilan jaringan: pasang batas waktu, rancang fungsi yang aman dipanggil ulang, dan jangan buka portnya ke internet.

Semoga artikel ini membantu.