gRPC vs. REST

Dalam atlas besar internet, antarmuka pemrograman aplikasi (API) adalah jalan raya yang menghubungkan kota, kota kecil, pantai, dan tujuan lainnya. API memungkinkan aplikasi perangkat lunak untuk berkomunikasi satu sama lain untuk bertukar data, fitur, dan fungsionalitas. Laporan Imperva tahun 2023 menemukan bahwa sekitar 71% lalu lintas internet terdiri dari panggilan API, yang menunjukkan betapa pentingnya teknologi ini bagi kerja aplikasi dan perusahaan modern.

Tidak mengherankan bahwa memahami cara membangun API merupakan keterampilan mendasar bagi sebagian besar pengembang. Namun, sebagaimana layaknya infrastruktur penting, ada banyak ragamnya.

Untuk memperluas metafora kita, jalan raya 12 lajur tidak "lebih baik" daripada jalan biasa dengan satu lajur; jalan raya tersebut akan menghancurkan struktur lingkungan perkotaan dan jalan biasa akan menjadi bencana di daerah dengan lalu lintas tinggi. Gaya arsitektur yang berbeda untuk membangun API, seperti REST dan gRPC, memiliki cara yang sama: masing-masing memiliki kekuatan dan kelemahan dan memahami kekuatan dan kelemahan tersebut sangat penting untuk menciptakan infrastruktur yang sehat.

Representational State Transfer, atau REST, adalah seperangkat prinsip desain (atau kendala arsitektur): antarmuka seragam, decoupling klien-server, tanpa status, cacheability, arsitektur sistem berlapis, dan kode sesuai permintaan (opsional). API yang dibuat menggunakan prinsip-prinsip ini disebut REST API, atau RESTful API.

REST API dapat menggunakan berbagai bahasa pemrograman dan format data, asalkan sesuai dengan prinsip REST. Ini adalah cara paling umum untuk membuat API.

REST API menggunakan permintaan HTTP (juga dikenal sebagai metode HTTP) seperti GET, POST, PUT, dan DELETE untuk menjalankan fungsi basis data standar. Operasi ini digunakan untuk membuat, membaca, memperbarui, dan menghapus catatan sumber daya dan sering disebut sebagai "CRUD." Sumber daya sisi server diidentifikasi oleh URL yang disebut titik akhir.

Misalnya, REST API akan menggunakan permintaan GET untuk mengambil catatan. Permintaan POST membuat catatan baru. Permintaan PUT memperbarui catatan dan permintaan DELETE menghapusnya. Semua metode HTTP dapat digunakan dalam panggilan API. REST API yang dirancang dengan baik seperti situs web yang berjalan di peramban web dengan fungsionalitas HTTP bawaan.

Informasi sumber daya dapat dikirimkan ke klien dalam berbagai format pesan termasuk JavaScript Object Notation (JSON), HTML, XLT, Python, PHP, atau teks biasa. JSON populer karena dapat dibaca oleh manusia dan mesin serta tidak bergantung pada bahasa pemrograman.

Pelajari lebih lanjut tentang REST vs. GraphQL

Dukungan browser: Karena REST API menggunakan HTTP/1.1 dan metode HTTP standar, serta format seperti XML dan JSON, REST API kompatibel dengan browser. 

Kemudahan penggunaan: Karena kesederhanaan dan popularitasnya, REST secara luas dipandang lebih mudah dipahami, khususnya bagi pemula. Alat, tutorial, dan panduan berlimpah di GitHub dan di tempat lain.

Fleksibilitas: REST API dianggap memiliki hubungan yang longgar antara klien dan server. Fleksibilitas ini memungkinkan perubahan yang lebih sederhana dan lebih cepat: perubahan dapat dilakukan pada salah satu sisi tanpa memerlukan perubahan pada sisi lainnya.

Ekosistem yang kuat: REST API memiliki sejumlah besar alat bantu serta dukungan dan dokumentasi yang luas. Spesifikasi OpenAPI, atau OAS, misalnya, menyediakan definisi standar industri tentang parameter dan kemampuan REST API. Versi terbaru OAS, OAS 3.1, menyertakan kompatibilitas penuh dengan Skema JSON, identifikasi standar yang menggunakan pengenal SPDX, dan banyak lagi.

Ketergantungan pada HTTP/1.1: Meskipun penggunaan HTTP/1.1 oleh REST memberikannya dukungan browser universal dan beberapa penyesuaian pada header, hal ini juga membuat REST API kehilangan beberapa manfaat dari HTTP/2 yang lebih baru. Manfaat yang hilang itu termasuk streaming dua arah; REST hanya mendukung streaming unary, di mana satu permintaan diikuti oleh satu respons.

Lebih lambat dan kurang efisien: Seperti halnya HTTP/1.1, Ketergantungan REST pada format seperti XML dan JSON memiliki kelemahan serta manfaat. Format tersebut dapat dibaca oleh manusia, dan itu bagus, tetapi juga merupakan file yang relatif besar, yang berarti transmisi lebih lambat.

Membutuhkan alat tambahan: Ekosistem REST mungkin kuat, tetapi memang harus kuat, karena beberapa fitur tidak dibangun ke dalam arsitekturnya. Pembuatan kode, misalnya, tersedia dalam bentuk plug-in untuk REST, tetapi itu masih merupakan langkah ekstra, dengan kerumitan ekstra.

gRPC adalah kerangka kerja sumber terbuka yang awalnya dikembangkan Google sebagai implementasi spesifik dari panggilan prosedur jarak jauh, atau RPC. Sekarang dikelola oleh Cloud Native Computing Foundation (CNCF).

gRPC mungkin saja bukan singkatan dari "Google Remote Procedure Call," karena para pengembangnya bersikeras bahwa gRPC bisa jadi singkatan dari "gRPC Remote Procedure Call," atau berbagai kemungkinan lainnya. Bagaimanapun, gRPC seperti RPC lainnya, memungkinkan panggilan jarak jauh muncul dan berfungsi sebagai panggilan lokal.

Sebagai model untuk interaksi klien/server, RPC sering digunakan dalam pengembangan API. Dalam model RPC, klien berinteraksi dengan perantara yang biasa disebut sebagai stub. Rintisan ini mengonversi data untuk transmisi dan, setelah menerima hasil yang diminta dari server, mengonversinya kembali ke format asli untuk klien. Ada banyak jenis kerangka kerja RPC termasuk XML-RPC dan JSON-RPC.

Kerangka kerja RPC ini ringan, relatif mudah digunakan dan memberikan manfaat seperti pengembangan yang disederhanakan dan abstraksi komunikasi jaringan. Namun, lingkungan seperti arsitektur layanan mikro dan sistem dengan beban data tinggi seringkali memerlukan kerangka kerja kinerja yang lebih tinggi dan gRPC dikembangkan untuk memenuhi kebutuhan itu.

gRPC menggunakan bahasa definisi antarmuka (IDL) yang disebut Protocol Buffers (Protobuf) untuk menserialisasi data terstruktur menjadi biner. Karena biner lebih ringkas daripada JSON atau XML, hal ini memungkinkan transfer muatan yang lebih besar dengan kecepatan yang lebih cepat.

gRPC juga menggunakan HTTP/2, yang memungkinkan streaming dua arah dan menjadikan gRPC pilihan yang kuat untuk API di lingkungan terdistribusi (terutama yang membutuhkan komunikasi real-time), arsitektur layanan mikro, aplikasi streaming, dan koneksi perangkat Internet of Things (IoT).

Kecepatan: gRPC, melalui Protobuf, melakukan serialisasi dan deserialisasi data dari berbagai bahasa, termasuk Java, Python, Ruby, dan banyak lagi, ke dalam muatan biner untuk transmisi. Kode ini ringan, sehingga waktu transmisi dan latensi dalam pertukaran data dikurangi dengan API gRPC.

Pembuatan kode: gRPC menyertakan kompiler Protobuf yang disebut [protoc], yang menawarkan fitur pembuatan kode asli. Setelah struktur data didefinisikan dalam file .proto , gRPC dapat menghasilkan kode sisi klien dan server.

Dukungan HTTP/2: Dengan mengandalkan protokol transport HTTP/2, gRPC mendukung berbagai jenis streaming. Sebagai contoh, ini mendukung streaming dua arah, di mana klien dan server dapat secara independen mengirim pesan dalam aliran baca/tulis, di samping streaming sisi klien dan sisi server.

Pencegat: gRPC mendukung middleware yang dikenal sebagai pencegat, yang memungkinkan peningkatan fungsionalitas. Pencegat dapat diinstal untuk menerapkan keamanan, autentikasi, analisis metrik, dan banyak lagi.

Pembatalan dan batas waktu: gRPC mendukung pembatalan, atau dikenal sebagai batas waktu atau tenggat waktu: waktu tertentu sebelum panggilan akan dibatalkan.

Kebaruan dan ekosistem: Meskipun gRPC memang menyertakan fitur tambahan seperti pembuatan kode, ini adalah arsitektur yang relatif baru, baru melihat rilis awalnya pada tahun 2016. Kebaruan itu telah membuat dokumentasi dan dukungan terbatas jika dibandingkan dengan gaya arsitektur yang lebih lama.

Kurva pembelajaran yang curam: Beberapa pengembang merasa bahwa gRPC memiliki kurva pembelajaran yang lebih curam dibandingkan dengan REST. Serialisasi data binernya menyediakan komunikasi yang efisien, tetapi tidak dapat dibaca manusia.

Kurangnya dukungan browser: Karena peramban web tidak mendukung protokol gRPC secara bawaan, maka tidak mungkin untuk secara langsung memanggil layanan gRPC dari aplikasi berbasis peramban. Salah satu cara untuk mengatasi masalah ini adalah dengan menggunakan proksi seperti gRPC-Web. GRPC-Web pada dasarnya bertindak sebagai lapisan terjemahan antara protokol HTTP dan gRPC browser.

REST dan gRPC memiliki banyak elemen yang sama dan keduanya digunakan untuk membangun sistem yang dapat diskalakan. Kesamaan meliputi:

Arsitektur klien/server: gRPC dan REST keduanya merupakan arsitektur klien/server dengan format permintaan-respons yang memungkinkan klien dan server untuk berkomunikasi dan bertukar data. Dalam arsitektur ini, klien mengirimkan permintaan dan server merespons dengan mengembalikan data yang diminta atau melakukan tindakan yang diminta.

Independen platform: gRPC dan REST memungkinkan layanan yang dibangun pada platform berbeda dengan sistem operasi berbeda untuk berkomunikasi.

Tanpa status: Baik REST maupun gRPC dianggap tidak memiliki status, yang berarti bahwa setiap permintaan menyertakan semua informasi yang diperlukan untuk melengkapinya. Server tidak perlu menyimpan informasi apa pun tentang permintaan sebelumnya.

Dukungan bahasa: Kedua gaya arsitektur ini bersifat agnostik bahasa, artinya API ini dapat digunakan oleh aplikasi yang ditulis dalam berbagai bahasa pemrograman. Kualitas ini membuat keduanya portabel di seluruh lingkungan pemrograman.

Penggunaan HTTP: Baik REST maupun gRPC mengandalkan komunikasi berbasis HTTP. Namun, gRPC menggunakan HTTP/2, sedangkan REST mengandalkan HTTP/1.1. Selain itu, gRPC mengabstraksi protokol komunikasi HTTP/2 yang mendasarinya, sementara komunikasi HTTP kurang diabstraksi dalam REST.

Perbedaan utama antara REST dan gRPC dapat membantu pengembang memutuskan mana yang terbaik untuk API yang mereka bangun. Perbedaan tersebut meliputi:

Format data: REST API terutama menggunakan format berbasis teks seperti JSON dan XML. gRPC menggunakan Protobuf untuk menyandikan data ke dalam format biner.

Pola komunikasi: REST hanya mendukung komunikasi unary, yang berarti satu permintaan diikuti oleh satu respons. gRPC mendukung yang lain, termasuk streaming dua arah (pertukaran klien dan server secara independen), streaming server (satu permintaan memicu beberapa respons) dan streaming klien (beberapa permintaan menghasilkan satu respons).

Pola desain: gRPC memiliki desain berorientasi layanan, di mana operasi server yang dapat dipanggil didefinisikan sebagai layanan atau fungsi. Dalam REST, desain berorientasi pada sumber daya, di mana metode HTTP digunakan untuk mengakses sumber daya server melalui titik akhir yang ditentukan oleh URL.

Kopling: Klien dan server gRPC saling terhubung erat, artinya klien dan server harus memiliki akses ke file proto middleware yang sama. Perubahan apa pun pada yang satu memerlukan perubahan pada yang lain. REST terhubung secara longgar. Kemandirian ini berarti bahwa perubahan pada satu komponen tidak memengaruhi komponen lainnya.

Pembuatan kode: gRPC menawarkan pembuatan kode bawaan, sementara REST tidak, meskipun ada plug-in yang tersedia.

Implementasi: REST tidak memerlukan perangkat lunak khusus dan memang mendukung browser. gRPC membutuhkan perangkat lunak khusus di kedua sisi server dan klien.

REST adalah pilihan desain API yang populer karena suatu alasan; kesederhanaannya, kompatibilitas yang luas, dan fleksibilitas menjadikannya pilihan yang sangat baik untuk banyak aplikasi. Untuk API publik, REST seringkali merupakan pilihan yang lebih masuk akal, karena lebih banyak digunakan dan seringkali lebih mudah dipahami. Banyak pengembang lebih akrab dengan REST dan mungkin memiliki infrastruktur yang signifikan khusus untuk REST, termasuk server, alat API management, alat pengembang, dan berbagai alat pengujian.

REST juga mendukung caching bawaan, atau kemampuan untuk menyimpan data yang sering diakses, baik secara lokal maupun melalui proxy. Caching dapat secara signifikan meningkatkan kecepatan dan efisiensi, meskipun juga perlu menyertakan berbagai informasi validasi, autentikasi, dan kedaluwarsa.

REST juga umumnya lebih disukai untuk layanan web dan API web, karena dukungannya untuk HTTP/1.1 dan dukungan browser universal. Umumnya lebih disukai daripada gRPC untuk komunikasi data yang lebih sederhana. Koplingnya yang longgar dan kompleksitasnya yang berkurang dapat meningkatkan skalabilitas arsitektur sistem dan dapat membantu membuat lingkungan menjadi lebih fleksibel dari waktu ke waktu. Namun, kemampuan beradaptasi ini harus dibayar dengan biaya kinerja. 

gRPC adalah arsitektur yang relatif lebih baru, dengan para pengembang yang semakin merangkul kecepatan, efisiensi, dan alat bawaannya. Ini sering digunakan untuk aplikasi streaming real-time dan API kompleks yang membutuhkan kinerja tinggi dan penanganan beban data tinggi dalam sistem terdistribusi. Meskipun lebih kompleks daripada REST, penggunaan HTTP/2 dan Protobuf memberi gRPC skalabilitas kinerja yang lebih besar. 

gRPC sangat cocok untuk arsitektur layanan mikro, karena kemampuannya untuk mengalirkan data dua arah secara real-time memungkinkan berbagai layanan dalam suatu aplikasi untuk mengirim dan menerima secara bersamaan dan independen. Ia juga mendapat dukungan dalam aplikasi mobile karena transmisi datanya yang cepat dan padat, dan karena aplikasi mobile cenderung tidak bergantung pada browser.

gRPC juga ideal untuk menghubungkan item IoT ke API backend, karena muatannya yang ringkas, latensi rendah, dan efisiensi kinerja tinggi cocok dengan teknologi rendah daya.