Memahami gRPC, OpenAPI, dan REST serta kapan menggunakannya dalam perancangan API (2020)

Manajemen API

gRPC dan REST: memahami gRPC, OpenAPI, dan REST dalam perancangan API serta kapan menggunakannya

• Model perancangan API: Dalam perancangan API, umumnya digunakan dua model, yaitu RPC dan REST. Sebagian besar API modern diimplementasikan berdasarkan protokol HTTP.
• gRPC: Teknologi implementasi API RPC yang menggunakan HTTP 2.0 sebagai protokol transport. Google dan lainnya banyak menggunakan API yang menggabungkan gagasan RPC dan HTTP.
• Tiga cara utama menggunakan HTTP:
  1. REST: Klien menggunakan URL yang disediakan server apa adanya, tanpa perlu memahami format URL.
  2. gRPC: Menggunakan HTTP/2, tetapi HTTP tidak diekspos kepada perancang API.
  3. OpenAPI: Klien memanggil API dengan menggunakan templat jalur URL.

REST

• Karakteristik: Klien tidak perlu memahami format URL, dan URL bukan bagian dari spesifikasi API.
• Kelebihan: Memiliki keunggulan web seperti stabilitas, konsistensi, dan universalitas. Model yang berorientasi entitas lebih sederhana dan lebih mudah dipahami.

gRPC

• Karakteristik: Menggunakan HTTP/2, tetapi detail HTTP disembunyikan. Klien menggunakan API dengan memanggil prosedur dan mengirimkan parameter.
• Kelebihan: Pustaka pemrograman sisi klien dapat dibuat dengan mudah, dan performanya baik.

OpenAPI

• Karakteristik: API dipanggil menggunakan templat jalur URL, sehingga klien harus memahami format URL.
• Kelebihan: API dapat diakses hanya dengan teknologi HTTP standar. Pustaka pemrograman sisi klien juga dapat dibuat.

Perbandingan gRPC dan OpenAPI

• Kesamaan: Keduanya dapat digunakan sebagai bahasa definisi antarmuka RPC (IDL).
• Perbedaan: gRPC menyembunyikan detail HTTP, sedangkan OpenAPI mengekspos detail HTTP.

Kelebihan REST

• Model berorientasi entitas: Lebih sederhana, lebih mudah dipahami, dan tetap stabil seiring waktu.

Cara menggunakan OpenAPI

• Definisi jalur: API didefinisikan menggunakan jalur dan metode HTTP.

Kelebihan dan kekurangan OpenAPI

• Kelebihan: Mirip dengan model RPC sehingga terasa familier bagi programmer. Dapat dipetakan ke permintaan HTTP.
• Kekurangan: Membutuhkan banyak upaya untuk merancang detail HTTP.

Kelebihan gRPC

• Implementasi sederhana: Implementasi sisi server sederhana, dan pustaka sisi klien dapat dibuat dengan mudah.
• Performa: Efisien karena menggunakan payload biner.

Kekurangan gRPC

• Memerlukan perangkat lunak khusus: Baik klien maupun server memerlukan perangkat lunak khusus.
• Keterbatasan fungsi proxy: Berbeda dari API HTTP, sulit memperluas atau memodifikasi fungsi di proxy.

Kesimpulan

• Pemilihan rancangan API: Harus dipilih dengan mempertimbangkan kelebihan dan kekurangan REST, OpenAPI, dan gRPC.
• Hal yang perlu dipertimbangkan saat menggunakan gRPC: Cocok untuk API internal atau ketika klien tidak harus mengadopsi teknologi gRPC.

[GN⁺]

Pendapat Hacker News

• Ada penyesalan karena seharusnya tidak mempelajari gRPC. Terlalu banyak waktu habis untuk debugging dan penyesuaian konfigurasi

  • Katanya gRPC menyembunyikan kompleksitas internal, tetapi pada praktiknya justru membutuhkan banyak debugging dan penyesuaian konfigurasi
  • Banyak waktu terbuang karena plugin Maven, masalah kompatibilitas dengan HTTP2, masalah firewall, dan sebagainya
  • Dokumentasinya kurang baik, dan sulit membuat pesan error bisa diamati dengan jelas

• Sudah lama membangun API, dan pernah menggunakan gRPC maupun HTTP/REST

  • Menganggap aneh membedakan OpenAPI dan REST seolah keduanya hal yang berbeda secara langsung
  • OpenAPI adalah cara untuk mendokumentasikan perilaku HTTP API, dan bisa mengekspresikan RESTful API
  • gRPC adalah mekanisme RPC yang bertukar protocol buffer
  • gRPC efisien, tetapi tidak sekuat library HTTP

• Pernah bekerja di FAANG, dan menganggap gRPC berguna untuk routing layanan internal

  • Protokol RPC memungkinkan pekerjaan dilakukan dalam skala besar dan kecepatan tinggi
  • Namun, untuk pelanggan atau web, ia tidak akan menggunakan gRPC

• Kecuali melakukan bidirectional streaming, gRPC dianggap buang-buang waktu

  • Saat melakukan pemanggilan RPC antar layanan yang diimplementasikan dalam berbagai bahasa, dibutuhkan banyak middleware

• Dalam proyek yang memakai gRPC, teknologi ini diadopsi karena alasan performa, tetapi akhirnya beralih ke JSON API

  • Pengalaman dengan gRPC kurang memadai, dan proyek gagal karena berbagai masalah

• Saat menggunakan connectrpc, beberapa masalah gRPC terasa teratasi

  • Melalui buf.build, file proto pihak ketiga bisa diimpor dengan mudah
  • Fitur pembuatan SDK otomatis sangat berguna

• gRPC dianggap memiliki pengalaman pengembangan yang lebih buruk dibanding REST

  • Membutuhkan tool tambahan, dan kode klien yang dihasilkan rumit

• Roy Fielding menyebut bahwa REST API hanya perlu mengetahui URI awal dan media type yang terstandarisasi

• Tidak suka menggunakan gRPC di dalam data center

  • Performanya tidak terlalu tinggi, dan kualitas klien open source rendah
  • Untuk API berbasis web, keterbacaan JSON lebih disukai, meski ada masalah ketidakcocokan tipe

• gRPC terasa sulit diakses di luar Google

  • Klien gRPC JS berat dan tidak transparan
  • Dibandingkan kesederhanaan REST, implementasinya dianggap keliru