gRPC, OpenAPI ve REST’i Anlamak ve API Tasarımında Ne Zaman Kullanmak Gerekir (2020)

API yönetimi

gRPC ve REST: API tasarımında gRPC, OpenAPI ve REST’i anlama ve kullanım zamanı

• API tasarım modelleri: API tasarımında başlıca iki model kullanılır: RPC ve REST. Modern API’lerin çoğu HTTP protokolü temelinde uygulanır.
• gRPC: HTTP 2.0’ı taşıma protokolü olarak kullanan bir RPC API uygulama teknolojisidir. Google gibi şirketler, RPC ile HTTP fikirlerini birleştiren API’leri yaygın olarak kullanır.
• HTTP’nin üç ana kullanım biçimi:
  1. REST: İstemci, sunucunun sağladığı URL’leri olduğu gibi kullanır ve URL biçimini anlamak zorunda değildir.
  2. gRPC: HTTP/2 kullanır, ancak HTTP API tasarımcısına görünmez.
  3. OpenAPI: İstemci, API’yi çağırmak için URL yol şablonlarını kullanır.

REST

• Özellikler: İstemcinin URL biçimini anlaması gerekmez ve URL, API spesifikasyonunun bir parçası değildir.
• Avantajlar: Kararlılık, tutarlılık ve evrensellik gibi web’in avantajlarını taşır. Varlık odaklı model daha basit ve anlaşılması daha kolaydır.

gRPC

• Özellikler: HTTP/2 kullanır, ancak HTTP’nin ayrıntıları gizlenir. İstemci, prosedürleri çağırıp parametreler geçirerek API’yi kullanır.
• Avantajlar: İstemci tarafı programlama kütüphaneleri kolayca üretilebilir ve performansı yüksektir.

OpenAPI

• Özellikler: API’yi çağırmak için URL yol şablonları kullanılır ve istemcinin URL biçimini anlaması gerekir.
• Avantajlar: API’ye yalnızca standart HTTP teknolojileriyle erişilebilir. İstemci tarafı programlama kütüphaneleri üretilebilir.

gRPC ve OpenAPI karşılaştırması

• Benzerlikler: Her ikisi de RPC arayüz tanımlama dili (IDL) olarak kullanılabilir.
• Farklar: gRPC, HTTP ayrıntılarını gizler; OpenAPI ise HTTP ayrıntılarını açığa çıkarır.

REST’in avantajları

• Varlık odaklı model: Daha basit, anlaşılması daha kolay ve zaman içinde daha kararlıdır.

OpenAPI nasıl kullanılır

• Yol tanımı: API, yollar ve HTTP metotları kullanılarak tanımlanır.

OpenAPI’nin avantajları ve dezavantajları

• Avantajlar: RPC modeline benzer olduğu için programcılara tanıdıktır. HTTP isteklerine eşlenebilir.
• Dezavantajlar: HTTP ayrıntılarını tasarlamak için çok çaba gerekir.

gRPC’nin avantajları

• Basit uygulama: Sunucu tarafı uygulaması basittir ve istemci tarafı kütüphaneleri kolayca üretilebilir.
• Performans: İkili payload kullandığı için verimlidir.

gRPC’nin dezavantajları

• Özel yazılım gereksinimi: Hem istemci hem de sunucu özel yazılıma ihtiyaç duyar.
• Proxy işlevi sınırlamaları: HTTP API’lerden farklı olarak, proxy üzerinde işlevleri genişletmek veya değiştirmek zordur.

Sonuç

• API tasarımı seçimi: REST, OpenAPI ve gRPC’nin her birinin avantajları ve dezavantajları değerlendirilerek seçim yapılmalıdır.
• gRPC kullanırken dikkat edilmesi gerekenler: İstemcilerin gRPC teknolojisini benimsemek zorunda olmadığı durumlarda, iç API’ler için avantajlıdır.

[GN⁺]

Hacker News görüşleri

• gRPC öğrenmemiş olmayı dilediğine dair bir pişmanlık var. Hata ayıklama ve yapılandırma ayarları için çok zaman harcanmış

  • gRPC iç ayrıntıları gizlediğini söylese de, pratikte çok fazla hata ayıklama ve yapılandırma ayarı gerektirmiş
  • Maven eklentisi, HTTP2 ile uyumluluk sorunları, güvenlik duvarı sorunları gibi nedenlerle çok zaman boşa gitmiş
  • Dokümantasyon zayıftı ve hata mesajlarını gözlemlenebilir hale getirmek zordu

• Uzun süredir API geliştiriyor ve hem gRPC hem de HTTP/REST kullanmış

  • OpenAPI ile REST arasındaki farkı ayırmanın tuhaf olduğunu düşünüyor
  • OpenAPI, bir HTTP API’nin nasıl çalıştığını belgeleme yöntemidir ve RESTful API’leri ifade edebilir
  • gRPC, Protocol Buffers alıp veren bir RPC mekanizmasıdır
  • gRPC verimlidir, ancak HTTP kütüphaneleri kadar güçlü değildir

• FAANG’da çalışma deneyimi var ve dahili servis yönlendirmesinde gRPC’nin faydalı olduğunu düşünüyor

  • RPC protokolleri büyük ölçekte ve yüksek hızda çalışmayı mümkün kılar
  • Ancak müşteri ya da web odaklı kullanımda gRPC tercih etmeyeceğini söylüyor

• Çift yönlü streaming yapılmadığı sürece gRPC’nin zaman kaybı olduğunu düşünüyor

  • Farklı dillerde yazılmış servisler arasında RPC çağrıları yaparken çok fazla middleware gerekiyor

• gRPC kullanılan bir projede performans gerekçesiyle bu teknoloji benimsenmiş, ancak daha sonra JSON API’ye geçilmiş

  • gRPC konusunda deneyim eksikliği vardı ve proje çeşitli sorunlar nedeniyle başarısız oldu

• connectrpc kullanarak gRPC’nin sorunlarını çözüyor

  • buf.build sayesinde 3rd party proto dosyaları kolayca alınabiliyor
  • SDK otomatik üretim özelliği çok faydalı

• gRPC’nin geliştirici deneyiminin REST’ten daha kötü olduğunu düşünüyor

  • Ek araçlar gerekiyor ve üretilen istemci kodu karmaşık

• Roy Fielding, bir REST API için yalnızca başlangıç URI’sini ve standartlaştırılmış medya tiplerini bilmenin yeterli olduğunu söylüyor

• Veri merkezi içinde gRPC kullanmayı sevmiyor

  • Performansı çok yüksek değil ve açık kaynak istemcilerin kalitesi düşük
  • Web tabanlı API’lerde JSON’un okunabilirliğini tercih ediyor, ancak tip uyuşmazlığı sorunları var

• gRPC’nin Google dışındaki dünyada erişilmesi zor olduğunu hissetmiş

  • gRPC JS istemcisi ağır ve opak
  • REST’in sadeliğine kıyasla bunun yanlış bir yönelim olduğunu düşünüyor