GRPC'nin bu açıklamasını okuyorum ve bu şema ilgi çekici:
Taşıma katmanı nasıl çalışır? Ağ üzerindeyse ... neden buna RPC deniyor? Daha da önemlisi, bu, hizmet katmanı için bir API uygulayan REST'ten (istemcideki sınıf, http isteği yapan yöntemlere sahip) nedir?
Yanıtlar:
Taşıma katmanı, TCP / IP'nin üstünde HTTP / 2 kullanarak çalışır. İstemciden sunucuya tek bir bağlantıdan yararlanabilen daha düşük gecikmeli (daha hızlı) bağlantılara olanak tanır (bu, bağlantının daha verimli kullanılmasını sağlar ve sunucu kaynaklarının daha verimli kullanılmasıyla sonuçlanabilir.
HTTP / 2 ayrıca çift yönlü bağlantıyı ve eşzamansız bağlantıyı da destekler. Böylelikle sunucunun mesaj göndermek için istemciyle verimli bir şekilde iletişim kurması (eşzamansız yanıt / bildirimler vb.)
Hem REST hem de gRPC, istemci / sunucu saplamaları oluşturabilirken (REST için swagger gibi bir şey kullanarak), REST, sınırlı bir birincil 'işlev' çağrısı (veya fiil) kümesine sahiptir:
+ ----------- + ---------------- + | HTTP Fiili | CRUD | + ----------- + ---------------- + | GET | Oku | | PUT | Güncelle / Değiştir | | YAMA | Güncelle / Değiştir | | SİL | Sil | + ----------- + ---------------- +
gRPC ise senkron / asenkron, tek yönlü / çift yönlü (akışlar) vb. dahil her türlü fonksiyon çağrısını tanımlayabilirsiniz.
GRPC kullanarak istemci yerel bir yönteme çağrı yapar. Programcıya yerel bir arama yapıyormuşsunuz gibi görünür, ancak temel katman (otomatik oluşturulan istemci saplaması) aramayı sunucuya gönderir. Sunucuya, yöntemi yerel olarak çağrılmış gibi görünüyor.
gRPC, temeldeki tüm tesisatla ilgilenir ve programlama paradigmasını basitleştirir. Ancak, kendini adamış bazı REST uzmanları için bu, aşırı bir karmaşıklık gibi görünebilir. YMMV
REST, JSON veya HTTP / 1.1 gerektirmez
HTTP / 2 üzerinden protobuf mesajları (veya her neyse) gönderen bir RESTful hizmeti basit bir şekilde oluşturabilirsiniz.
HTTP / 2 üzerinden JSON gönderen RESTful hizmetleri oluşturabilirsiniz.
HTTP / 1.1 üzerinden protobuf mesajları gönderen RESTful hizmetleri oluşturabilirsiniz.
RESTful hizmetleri, HTTP / xx'in üstünde bir "hack" değildir, HTTP'nin herhangi bir sürümünü başarılı kılan temel mimari ilkeleri izleyen hizmetlerdir (GET isteklerinin önbelleğe alınabilirliği ve PUT isteklerinin tekrar oynatılabilirliği gibi).
gRPC, SOAP, vb. diğerleri daha çok hacks gibidir - HTTP üzerinden RPC tarzı hizmetleri tünellemek, güvenlik duvarı ve ara kutu kısıtlamalarını yönlendirmek için HTTP'nin üstüne hackler. Bu mutlaka kötü bir şey değil. Bazen bir REST yerine RPC tarzı bir hizmet isteyebilirsiniz ve orta kutuların değiştirilmesinin zor olduğu bir dünyada yaşamak zorundayız.
REST'in gerçek tanımını okumak için zamanınız yoksa: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Her zaman TLDR vardır; wikipedia'daki sürüm:
https://en.wikipedia.org/wiki/Representational_state_transfer
RPC tarzı bir hizmete ihtiyacınız varsa, elbette, gRPC harika. İnternette yaşamak istiyorsanız veya RESTful tarzı bir hizmetle birlikte gelen tüm avantajlardan yararlanmak istiyorsanız, o zaman bir RESTful tarzı hizmet oluşturun. Ayrıca, dinlendirici hizmetinizde verileri JSON biçiminde serileştirmek / seri durumdan çıkarmak çok yavaşsa, protobuf veya her neyse kullanmak tamamen uygundur.
GRPC herhangi bir şeyin 2. sürümü ise, bu SOAP'ın 2. sürümüdür. SABUN gibi korkunç olmayan bir tane.
Ve hayır, GET isteğinizde "herhangi bir işlevi arayamazsınız" ve bir RESTful hizmetine sahip olamazsınız.
Son bir şey: Eğer bir RESTful hizmeti üzerinden protobuf kullanacaksanız, lütfen içerik türü başlıklarını vb. Kullanarak doğru yapın. Bununla hem JSON hem de protobuf'u kolayca destekleyebilirsiniz.
SABUN kutumdan şimdi aşağı iniyorum ..;)
GRPC'nin REST'e göre en büyük avantajı, büyükbaba HTTP 1.1'e göre HTTP / 2'yi desteklemesidir. O zaman HTTP / 2'nin HTTP 1.1'e göre en büyük avantajı, 'HTTP / 2 sunucunun içeriği "itmesine" izin verir "...
Her zaman gRPC ve REST'in kesinlikle iki farklı şey olduğunu hissediyorum.
REST, kaynak odaklı hizmetler için en iyisidir. aksi takdirde yüksek performans için gRPC kullanabiliriz.
REST internet seviyesidir, servisimizle son kullanıcı konuşması içindir. gRPC intranet seviyesidir, dahili hizmetlerin birbirleriyle konuşması içindir.
REST, takip etmek için uygulama semantiğine sahiptir. gRPC hiçbir şey sağlamadı, her şeyi sıfırdan inşa etmelisiniz.