Apa perbedaan GRPC dari REST?

Saya membaca penjelasan GRPC ini dan diagram ini menarik:

Bagaimana cara kerja lapisan transport? Jika melalui jaringan ... mengapa disebut RPC? Lebih penting lagi, bagaimana ini berbeda dari REST yang mengimplementasikan API untuk lapisan layanan (kelas di klien yang memiliki metode yang membuat permintaan http)?

rest grpc

— Jwan622
sumber

«Jika melalui jaringan ... mengapa disebut RPC» - Karena RPC adalah Panggilan Prosedur Jarak Jauh, dan 'jarak jauh' bisa berarti 'di host lain'.

— Aneh

Jawaban:

104

Lapisan transport bekerja menggunakan HTTP / 2 di atas TCP / IP. Ini memungkinkan koneksi latensi yang lebih rendah (lebih cepat) yang dapat memanfaatkan satu koneksi dari klien ke server (yang membuat penggunaan koneksi lebih efisien dan dapat menghasilkan penggunaan sumber daya server yang lebih efisien.

HTTP / 2 juga mendukung konektivitas dua arah dan konektivitas asynchronous. Jadi dimungkinkan bagi server untuk secara efisien melakukan kontak dengan klien untuk mengirim pesan (respons / pemberitahuan asinkron, dll ..)

Meskipun, REST dan gRPC dapat menghasilkan stub klien / server (menggunakan sesuatu seperti swagger untuk REST), REST memiliki serangkaian panggilan 'fungsi' utama (atau kata kerja):

+ ----------- + ---------------- +
| Kata Kerja HTTP | CRUD |
+ ----------- + ---------------- +
| DAPATKAN | Baca |
| PUT | Perbarui / Ganti |
| PATCH | Perbarui / Modifikasi |
| HAPUS | Hapus |
+ ----------- + ---------------- +

sedangkan gRPC Anda dapat menentukan semua jenis panggilan fungsi termasuk sinkron / asinkron, searah / dua arah (aliran), dll ..

Dengan menggunakan gRPC, klien melakukan panggilan ke metode lokal. Bagi pemrogram, sepertinya Anda melakukan panggilan lokal, tetapi lapisan yang mendasarinya (rintisan klien yang dibuat secara otomatis) mengirimkan panggilan tersebut ke server. Untuk server sepertinya metodenya dipanggil secara lokal.

gRPC menangani semua saluran air yang mendasarinya dan menyederhanakan paradigma pemrograman. Namun, bagi beberapa puritan REST yang berdedikasi, ini mungkin tampak seperti komplikasi yang berlebihan. YMMV

— mmccabe.dll
sumber

Jadi, pertanyaan singkat: Di REST, Anda juga dapat memanggil berbagai jenis fungsi. Misalnya, di Rails, saya dapat mengirim permintaan GET ke titik akhir yang non-RESTful dan melakukan sesuatu selain hanya mendapatkan sumber daya. Saya benar-benar dapat menendang fungsi apa pun dari titik akhir non-RESTful itu. Saya juga dapat membuat layanan di REST yang tampaknya memanggil metode lokal tetapi sebenarnya membuat panggilan http ke titik akhir. Jadi perbedaannya tidak terlalu besar kan ... setidaknya pada lapisan transport. Atau apakah mereka?

— Jwan622

REST / RESTful dijalankan melalui HTTP, gRPC dijalankan melalui HTTP / 2 (seperti WebSocket). Dengan menggunakan generator kode dari Swagger, dimungkinkan untuk menghasilkan stub klien dan server untuk REST, gRPC menggunakan file proto untuk menghasilkan stubnya (tidak berbeda dengan pendekatan WSDL / SOAP lama). File proto mendefinisikan tipe, sehingga stub klien / server yang dihasilkan adalah tipe yang aman. Di perangkat seluler, koneksi gRPC efisien karena dapat berbagi soket HTTP / 2 dasar yang sama dengan koneksi bersamaan lainnya dari aplikasi seluler.

— mmccabe

Berikut adalah pengantar yang bagus untuk gRPC: medium.com/square-corner-blog/grpc-reaches-1-0-85728518393b Berikut adalah demo dari gRPC: github.com/mmcc007/go

— mmccabe

Jwan622 dan mmccabe: Dengan menggunakan perpustakaan Superglue 2.1, saya dapat membangun rumah dengan apel dan jeruk. Pada titik tertentu, kita harus memilih alat yang tepat untuk pekerjaan itu dan selalu berusaha meminimalkan kompleksitas sistem perangkat lunak kita. Ingat, menghapus kode selalu merupakan pengoptimalan kinerja;)

— Martin Andersson

Dari sudut pandang saya, hal-hal seperti RESTful API selalu menjadi "retasan" untuk mengikuti protokol lama. Jika ada sesuatu yang memungkinkan saya menggunakan tumpukan yang lebih cocok untuk bahasa modern dan masih agnostik terhadap bahasa yang secara spesifik digunakan oleh klien DAN meningkatkan kinerja secara dramatis, maka saya akan menjadi orang pertama yang ikut serta!

— Martin Andersson

REST tidak membutuhkan JSON atau HTTP / 1.1

Anda bisa dengan mudah membangun layanan RESTful yang mengirim pesan protobuf (atau apa pun) melalui HTTP / 2

Anda dapat membangun layanan RESTful yang mengirim JSON melalui HTTP / 2

Anda dapat membangun layanan RESTful yang mengirim pesan protobuf melalui HTTP / 1.1

Layanan RESTful bukanlah "hack" di atas HTTP / xx, mereka adalah layanan yang mengikuti prinsip-prinsip arsitektur dasar yang telah membuat versi HTTP berhasil (seperti cache permintaan GET & replayability permintaan PUT).

gRPC, SOAP, et. al lebih seperti peretasan - peretasan di atas HTTP ke terowongan layanan gaya RPC melalui HTTP, untuk merutekan batasan firewall & middlebox. Itu tidak selalu berarti buruk. Terkadang Anda mungkin menginginkan layanan gaya RPC daripada layanan REST, dan kita harus hidup di dunia di mana middlebox sulit untuk diganti.

Jika Anda tidak punya waktu untuk membaca tentang definisi sebenarnya dari REST: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Selalu ada TLDR; versi di wikipedia:

https://en.wikipedia.org/wiki/Representational_state_transfer

Jika Anda membutuhkan layanan bergaya RPC, tentu saja, gRPC sangat bagus. Jika Anda ingin hidup di web, atau Anda ingin semua manfaat yang datang dengan layanan gaya RESTful, maka buat layanan gaya RESTful. Dan jika terlalu lambat untuk membuat serial / deserialisasi data dalam format JSON di layanan tenang Anda, tidak masalah untuk menggunakan protobuf atau apa pun.

Jika gRPC adalah versi 2 dari apa pun, itu adalah SOAP versi 2. Yang tidak buruk, seperti SOAP.

Dan, tidak, Anda tidak bisa begitu saja "memanggil fungsi apa pun" dalam permintaan GET Anda, dan memiliki layanan RESTful.

Satu hal lagi: jika Anda akan menggunakan protobuf melalui layanan RESTful, lakukan dengan benar, gunakan header tipe konten, dll. Dengan itu, Anda dapat dengan mudah mendukung JSON DAN protobuf.

Mundur dari kotak SOAP saya sekarang ..;)

— pengguna2077221
sumber

Apakah Anda menyiratkan bahwa layanan RESTful tidak dapat dibuat menggunakan gRPC?

— Kevin S

RTFM yang mengutip disertasi Fielding terlalu berlebihan, tetapi sebaliknya mendapat tanggapan yang bagus.

— rmharrison

Keuntungan terbesar gRPC dibandingkan REST adalah dukungannya terhadap HTTP / 2 dibandingkan dengan kakek HTTP 1.1. Kemudian keuntungan terbesar dari HTTP / 2 dibandingkan HTTP 1.1 adalah, 'HTTP / 2 memungkinkan server untuk "mendorong" konten' ...

— Denis Wang
sumber

Server push tidak membutuhkan HTTP / 2.

— Robin Green

Bisakah kamu lebih spesifik? Ini adalah wiki yang berbicara tentang HTTP / 2 Server Push: en.wikipedia.org/wiki/HTTP/2_Server_Push

— Denis Wang

Maaf, yang saya maksud bukan dorongan server HTTP 2, maksud saya streaming balasan. Ada cara lain untuk melakukan streaming balasan, seperti long polling, atau websockets, misalnya.

— Robin Green

Server gRPC tidak mengirim HTTP / 2 "push dan klien gRPC mengabaikan HTTP / 2" push ". Jadi, keuntungan gRPC yang diwarisi dari HTTP / 2 tidak boleh menyertakan" push ".

— user675693