# REST vs gRPC

Adres: https://softwaredictionary.org/tr/karsilastirma/rest-vs-grpc
Son güncelleme: 2026-09-30

Kısaca: REST kaynakları HTTP üzerinden, genelde JSON ile sunar; gRPC ise tipli uzak fonksiyonları HTTP/2 ile ikili mesajlarla çağırır: daha hızlı ama tarayıcıda zor.

## REST ile gRPC arasındaki fark nedir?

REST, istemcilerin URL'lerdeki kaynakları HTTP metotlarıyla okuyup değiştirdiği, genellikle `JSON` alışverişi yaptığı bir mimari tarzdır. gRPC ise aslen Google'da geliştirilmiş bir uzak yordam çağrısı (RPC) framework'üdür; servisleri ve mesajları bir `.proto` dosyasında tanımlarsınız, istemci ve sunucu kodu bundan üretilir, böylece uzak bir servisi çağırmak yerel bir fonksiyonu çağırmak gibi görünür.

Fark, hedeflerinden gelir. REST sadeliği ve erişilebilirliği öne çıkarır: herhangi bir HTTP istemcisi, tarayıcı ya da komut satırı aracı onu çağırabilir ve yanıtlar insan tarafından okunabilir. gRPC verimliliği ve katı sözleşmeleri öne çıkarır: Protocol Buffers kompakt bir ikili biçimdir, HTTP/2 birçok çağrının tek bağlantıyı paylaşmasını sağlar ve iki yönlü akış (streaming) yerleşiktir.

Birçok sistem ikisini de kullanır. Yaygın bir kalıp, tarayıcılar ve üçüncü taraflar için uçta REST ya da GraphQL, hız ve tipli sözleşmelerin en çok önem taşıdığı dahili mikroservisler arasında ise gRPC kullanmaktır. Ağ geçitleri REST çağrılarını gRPC'ye de çevirebilir; böylece tek bir servis her iki tür istemciye hizmet verebilir.

Sık yapılan bir yanlış, gRPC'nin sadece daha iyi bir REST olduğu düşüncesidir. Tarayıcılar yerel gRPC'yi doğrudan çağıramaz ve gRPC-Web gibi bir çeviri katmanına ihtiyaç duyar, ikili mesajları hata ayıklarken incelemek daha zordur ve birçok genel API için REST'in erişilebilirliği ve sadeliği ham hızdan daha önemlidir.

| Özellik | REST API | gRPC |
| --- | --- | --- |
| Tarz | URL'lerdeki kaynaklar, HTTP metotlarıyla işlem görür | Tipli bir servis üzerinde çağrılan uzak fonksiyonlar |
| Sözleşme | İsteğe bağlı; çoğunlukla OpenAPI ile belgelenir | İstemci ve sunucu kodunu üreten zorunlu .proto dosyası |
| Yük biçimi | Genellikle JSON metni, insanlar için okunması kolay | Protocol Buffers ikili biçimi, daha küçük ve ayrıştırması daha hızlı |
| Taşıma | Herhangi bir HTTP sürümü: HTTP/1.1, HTTP/2 ya da HTTP/3 | HTTP/2; birçok çağrı tek bağlantıyı paylaşır |
| Akış (streaming) | İstek-yanıt; akış ek teknikler gerektirir | Yerleşik istemci, sunucu ve iki yönlü akış |
| Tarayıcı desteği | Her tarayıcıda yerel olarak çalışır | Arada gRPC-Web ya da bir ağ geçidi gerekir |
| En uygun olduğu yer | Genel API'ler, web ön yüzleri ve basit entegrasyonlar | Hızlı, yüksek hacimli dahili servisler arası çağrılar |

## REST API şu durumlarda doğru seçim

- API'niz herkese açık ya da doğrudan tarayıcılardan çağrılıyor.
- İnsanların standart araçlarla okuyup hatalarını ayıklayabileceği yanıtlar istiyorsunuz.
- HTTP önbellekleme, CDN'ler ya da kolay üçüncü taraf entegrasyonlarına güveniyorsunuz.

## gRPC şu durumlarda doğru seçim

- Dahili servisler birbirini çok sık çağırıyor ve gecikme önemli.
- Birkaç dil arasında paylaşılan, katı ve üretilmiş sözleşmeler istiyorsunuz.
- Bir ya da iki yönde akışa ihtiyacınız var.
- Mobil ya da IoT bağlantılarında olduğu gibi bant genişliği sınırlı.

## Sık sorulan sorular

**gRPC, REST'ten daha mı hızlı?**

Servisler arası çağrılarda genellikle evet; çünkü ikili Protocol Buffers JSON'dan küçüktür ve HTTP/2 bağlantıları yeniden kullanır. Fark en çok yüksek çağrı hacimlerinde önemlidir; tipik bir web isteğinde ağ gecikmesi baskındır.

**Tarayıcılar gRPC kullanabilir mi?**

Doğrudan kullanamaz. Tarayıcılar gRPC'nin ihtiyaç duyduğu alt düzey HTTP/2 denetimini sunmaz; bu yüzden web uygulamaları gRPC-Web ya da JSON'lu HTTP ile gRPC arasında çeviri yapan bir ağ geçidi kullanır.

**gRPC HTTP kullanır mı?**

Evet. gRPC, HTTP/2 üzerinde çalışır; ama HTTP'yi kaynak URL'leri gibi REST kurallarını izlemek yerine ikili mesajlar için bir taşıma katmanı olarak kullanır.

---

Software Dictionary: https://softwaredictionary.org/tr · https://softwaredictionary.org/tr/llms.txt