Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. REST API
Code

REST vs. gRPC: Pertempuran API

by
Difficulty:IntermediateLength:ShortLanguages:

Indonesian (Bahasa Indonesia) translation by Evita Karlina (you can also view the original English article)

The REST API telah menjadi pilar pemrograman web untuk waktu yang lama. Namun baru-baru ini gRPC telah mulai merambah wilayahnya. Ternyata ada beberapa alasan bagus untuk itu. Dalam tutorial ini, Anda akan belajar tentang seluk beluk gRPC dan bagaimana hal itu dibandingkan dengan REST.

Protobuf vs. JSON

Salah satu perbedaan terbesar antara REST dan gRPC adalah format payload. Pesan REST biasanya berisi JSON. Ini bukan persyaratan yang ketat, dan secara teori Anda dapat mengirim apa pun sebagai tanggapan, tetapi dalam prakteknya seluruh ekosistem REST — termasuk perkakas, praktik terbaik, dan tutorial — difokuskan pada JSON. Aman untuk mengatakan bahwa, dengan sangat sedikit pengecualian, REST API menerima dan mengembalikan JSON.

gRPC, di sisi lain, menerima dan mengembalikan pesan Protobuf. Saya akan membahas ketikan yang kuat nanti, tetapi hanya dari sudut pandang kinerja, Protobuf adalah format yang sangat efisien dan dikemas. JSON, di sisi lain, adalah format tekstual. Anda dapat memampatkan JSON, tetapi kemudian Anda kehilangan manfaat dari format tekstual yang dapat Anda harapkan dengan mudah.

HTTP/2 vs. HTTP 1.1

Mari kita bandingkan protokol transfer yang digunakan REST dan gRPC. REST, seperti yang disebutkan sebelumnya, sangat bergantung pada HTTP (biasanya HTTP 1.1) dan model permintaan-respons. Di sisi lain, gRPC menggunakan protokol HTTP / 2 yang lebih baru.

Ada beberapa masalah yang mengganggu HTTP 1.1 yang diperbaiki HTTP / 2. Inilah yang utama.

HTTP 1.1 Terlalu Besar dan Rumit

HTTP 1.0 RFC 1945 adalah RFC 60 halaman. HTTP 1.1 awalnya dijelaskan dalam RFC 2616, yang menggelembung hingga 176 halaman. Namun, kemudian IETF membaginya menjadi enam dokumen berbeda — RFC 7230, 7231, 7232, 7233, 7234, dan 7235 — dengan jumlah halaman gabungan yang lebih tinggi. HTTP 1.1 memungkinkan banyak bagian opsional yang berkontribusi pada ukuran dan kerumitannya.

Pertumbuhan Ukuran Halaman dan Jumlah Objek

Kecenderungan halaman web adalah meningkatkan ukuran total halaman (rata-rata 1,9MB) dan jumlah objek pada halaman yang membutuhkan permintaan individu. Karena setiap objek memerlukan permintaan HTTP terpisah, perkalian objek terpisah ini meningkatkan beban di server web secara signifikan dan memperlambat waktu pemuatan halaman untuk pengguna.

Masalah Latensi

HTTP 1.1 sensitif terhadap latensi. Sebuah jabat tangan TCP diperlukan untuk setiap permintaan individu, dan jumlah permintaan yang lebih besar mengambil tol yang signifikan pada waktu yang diperlukan untuk memuat halaman. Peningkatan berkelanjutan dalam bandwidth yang tersedia tidak memecahkan masalah latensi ini dalam banyak kasus.

Kepala Pemblokiran Jalur

Pembatasan pada jumlah koneksi ke domain yang sama (dulu hanya 2, hari ini 6-8) secara signifikan mengurangi kemampuan untuk mengirim beberapa permintaan secara paralel.

Dengan pipelining HTTP, Anda dapat mengirim permintaan sambil menunggu tanggapan atas permintaan sebelumnya, yang secara efektif membuat antrean. Tapi itu memperkenalkan masalah lain. Jika permintaan Anda macet di balik permintaan yang lambat maka waktu respons Anda akan terganggu.

Ada kekhawatiran lain seperti hukuman kinerja dan sumber daya ketika berpindah jalur. Saat ini, pipelining HTTP tidak diaktifkan secara luas.

Bagaimana HTTP / 2 Mengatasi Masalah

HTTP / 2, yang keluar dari SPDY Google, mempertahankan premis dasar dan paradigma HTTP:

  • model permintaan-respons melalui TCP
  • sumber daya dan kata kerja
  • Skema URL https:// dan https://

Tetapi bagian opsional dari HTTP 1.1 telah dihapus.

Untuk mengatasi protokol negosiasi karena skema URL bersama, ada tajuk pemutakhiran. Juga, di sini adalah kejutan bagi Anda: protokol HTTP / 2 adalah biner! Jika Anda berada di sekitar protokol internet maka Anda tahu bahwa protokol tekstual dianggap sebagai raja karena mereka lebih mudah bagi manusia untuk memecahkan masalah dan menyusun permintaan secara manual. Namun, dalam praktiknya, kebanyakan server saat ini menggunakan enkripsi dan kompresi. Framing biner berjalan jauh ke arah mengurangi kompleksitas penanganan frame di HTTP 1.1.

Namun, peningkatan besar dari HTTP / 2 adalah bahwa ia menggunakan aliran multipleks. Koneksi TCP / 2 TCP tunggal dapat mendukung banyak aliran dua arah. Aliran ini dapat disisipkan (tidak ada antrian), dan beberapa permintaan dapat dikirim pada saat yang bersamaan tanpa perlu membuat sambungan TCP baru untuk masing-masing. Selain itu, server sekarang dapat mendorong pemberitahuan kepada klien melalui koneksi yang ditetapkan (HTTP / 2 push).

Pesan vs. Sumber dan Verba

REST adalah API yang menarik. Ini dibangun sangat erat di atas HTTP. Itu tidak hanya menggunakan HTTP sebagai transportasi, tetapi merangkul semua fitur dan membangun kerangka konseptual yang konsisten di atasnya. Secara teori, kedengarannya bagus. Dalam praktiknya, sangat sulit untuk menerapkan REST dengan benar.

Jangan salah — REST telah dan sangat berhasil, tetapi sebagian besar implementasi tidak sepenuhnya mematuhi filosofi REST dan hanya menggunakan sebagian prinsipnya. Alasannya adalah bahwa itu sebenarnya cukup menantang untuk memetakan logika dan operasi bisnis ke dunia REST yang ketat.

Model konseptual yang digunakan oleh gRPC adalah memiliki layanan dengan antarmuka yang jelas dan pesan terstruktur untuk permintaan dan tanggapan. Model ini diterjemahkan langsung dari konsep bahasa pemrograman seperti antarmuka, fungsi, metode, dan struktur data. Ini juga memungkinkan gRPC untuk secara otomatis menghasilkan pustaka klien untuk Anda.

Streaming vs. Request-Response

REST hanya mendukung model permintaan-respons yang tersedia di HTTP 1.x. Tetapi gRPC mengambil keuntungan penuh dari kemampuan HTTP / 2 dan memungkinkan Anda mengalirkan informasi secara konstan. Ada beberapa jenis streaming.

Streaming Sisi Server

Server mengirim balik aliran tanggapan setelah mendapatkan pesan permintaan klien. Setelah mengirim kembali semua tanggapannya, detail status server dan metadata tambahan yang diperlukan dikirim kembali untuk diselesaikan di sisi server. Klien selesai setelah memiliki semua tanggapan server.

Streaming Sisi Klien

Klien mengirim aliran beberapa permintaan ke server. Server mengirim balik satu tanggapan, biasanya tetapi tidak harus setelah menerima semua permintaan klien, bersama dengan detail statusnya dan metadata tambahan yang opsional.

Streaming dua arah

Dalam skenario ini, klien dan server mengirim informasi satu sama lain dalam bentuk bebas cukup banyak (kecuali klien memulai urutan). Akhirnya, klien menutup koneksi.

Mengetik Kuat vs Serialisasi

Paradigma REST tidak mengamanatkan struktur apa pun untuk payload yang ditukar. Biasanya JSON. Konsumen tidak memiliki mekanisme formal untuk mengoordinasikan format permintaan dan tanggapan. JSON harus diserialkan dan diubah menjadi bahasa pemrograman target baik di sisi server dan sisi klien. Serialisasi adalah langkah lain dalam rantai yang memperkenalkan kemungkinan kesalahan serta overhead kinerja.

Kontrak layanan gRPC telah sangat mengetik pesan yang dikonversi secara otomatis dari representasi Protobuf mereka ke bahasa pemrograman pilihan Anda baik di server dan pada klien.

JSON, di sisi lain, secara teoritis lebih fleksibel karena Anda dapat mengirim data dinamis dan tidak harus mengikuti struktur yang kaku.

Gateway gRPC

Dukungan untuk gRPC di browser belum matang. Saat ini, gRPC digunakan terutama untuk layanan internal yang tidak terkena langsung ke dunia.

Jika Anda ingin mengkonsumsi layanan gRPC dari aplikasi web atau dari bahasa yang tidak didukung oleh gRPC, maka gRPC menawarkan gerbang API REST untuk mengekspos layanan Anda. Plugin gateway gRPC menghasilkan server API REST penuh dengan dokumentasi reverse proxy dan Swagger.

Dengan pendekatan ini, Anda kehilangan sebagian besar manfaat gRPC, tetapi jika Anda perlu menyediakan akses ke layanan yang ada, Anda dapat melakukannya tanpa menerapkan layanan Anda dua kali.

Kesimpulan

Di dunia microservices, gRPC akan menjadi dominan segera. Manfaat kinerja dan kemudahan pengembangan terlalu bagus untuk dilewatkan. Namun, jangan salah, REST akan tetap ada untuk waktu yang lama. Ini masih unggul untuk API yang terbuka untuk umum dan untuk alasan kompatibilitas mundur.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.