- Postman'ın 40 bin geliştiriciyle yaptığı araştırmadan derlenen API protokol trendleri ile artıları/eksileri
- REST, WebHooks, GraphQL, SOAP, WebSocket, gRPC vb.
REST
- Hâlâ en yaygın kullanılan yaklaşım. Son 2 yılda %92'den %86'ya geriledi
- Basitlik, ölçeklenebilirlik ve web servisleriyle kolay entegrasyon
- REST'in avantajları
- Basitlik ve standardizasyon: Standart HTTP yöntemlerini kullandığı için, HTTP'ye zaten aşina geliştiriciler tarafından kolayca benimsenebilir. Bu basitlik hızlı öğrenmeyi ve entegrasyonu teşvik eder
- Ölçeklenebilirlik: REST'in stateless yapısı nedeniyle sunucunun istekler arasında oturum verisi saklaması gerekmez. Paylaşılan sunucuya ihtiyaç duymadan instance ekleyerek yatay ölçeklemeyi kolaylaştırır
- Performans: Stateless yapı ve cache'lenebilir yanıtlar çalışma hızını artırır ve istek sayısını azaltır
- Modülerlik: RESTful servisler modüler bileşenler olarak geliştirilebilir. Bu, bağımsız güncellemeleri mümkün kılar ve bakım yapılabilirliği artırır
- Platformdan bağımsızlık: Farklı istemciler tarafından kullanılabilir. Birlikte çalışabilirlik, sistem genelinde API entegrasyonunu kolaylaştırır
- Olgun araçlar ve topluluk desteği: Çok sayıda araç, kütüphane, en iyi uygulama, sorun giderme rehberi ve topluluk kaynağı bulunur
- REST'in zorlukları
- Over-fetching ve under-fetching: İstemci verinin yalnızca bir kısmına ihtiyaç duyabilir; bu da fazla ya da yetersiz veri çekilmesine yol açabilir. Sonuç olarak performans sorunları oluşabilir ve bant genişliği boşa harcanabilir
- Birden fazla arayüz çağrısı: İlgili verileri almak için birden çok istek gerekebilir ve bu da gecikmeyi artırır. Bu ardışık çağrılar, uygulama ölçeklendikçe sorun hâline gelir
- Sürümleme sorunları: Özellikle veri yapısı veya servis işlevleri değiştiğinde REST API'nin yeni sürümünü oluşturmak zahmetli olabilir. Bu da sıklıkla geriye dönük uyumluluk sorunlarına yol açar
- Stateless ek yükü: Stateless yaklaşım ölçeklenebilirliği destekler, ancak her istekte gerekli tüm bağlamın gönderilmesi gerektiği anlamına da gelir. Özellikle istemci çok miktarda tekrarlı veri gönderiyorsa bu durum ek yük yaratabilir
- Gerçek zamanlı özellik eksikliği: REST, sohbet ya da canlı akış gibi gerçek zamanlı uygulamalar için optimize edilmemiştir. Bu kullanım senaryoları için WebSocket ve SSE daha uygundur
WebHooks
- Webhook'lar, kaynak uygulamadaki olaylarla tetiklenen özelleştirilmiş HTTP callback'leridir
- Bir olay gerçekleştiğinde kaynak uygulama, hedef uygulamanın belirttiği URI'ye bir HTTP isteği (genellikle POST) gönderir; bu da tekrarlayan polling olmadan neredeyse gerçek zamanlı olay tabanlı iletişim sağlar
- Webhook'lar giderek daha popüler hâle geliyor ve geliştiricilerin %36'sı bunları çeşitli sistemler arasında sorunsuz entegrasyon için kullanıyor
- WebHooks'un avantajları
- Gerçek zamanlı iletişim: Webhook'lar gerçek zamanlı veri aktarımı sağlar. Olay oluştuğunda ilgili veri gönderilir ve sistemler arasında güncel senkronizasyon korunur
- Verimlilik: Webhook'lar kaynak yoğun polling'i ortadan kaldırarak işlem gücü ve bant genişliğinden tasarruf sağlar
- Esneklik: Webhook'lar belirli olaylara yanıt verecek şekilde yapılandırılabilir; böylece bir uygulamadaki hangi işlem veya tetikleyicinin başka bir uygulamaya veri göndereceği özelleştirilebilir
- Basitleştirilmiş entegrasyon: HTTP yöntemlerini kullandığı için çoğu uygulamada kolayca kullanılabilir
- Ayrık mimari desteği: Webhook'lar olay temelli çalıştığı için doğal olarak event-driven veya ayrık mimarileri destekler; bu da modülerliği ve ölçeklenebilirliği artırır
- WebHooks'un zorlukları
- Hata yönetimi: Webhook alıcısı kapalıysa ya da callback işlenirken hata oluşursa veri kaybı riski vardır. Webhook kullanan sistemlerde yeniden deneme veya loglama içeren güçlü hata yönetimi mekanizmaları bulunmalıdır
- Güvenlik sorunları: Webhook'lar veriyi internet üzerinden ilettiği için verinin ele geçirilmesine veya kötü niyetli saldırılara açık olabilir. HTTPS kullanımı ve payload imzalama gibi API güvenlik önlemleri zorunludur
- Birden fazla webhook'un yönetimi: Webhook'ların yönetimi ve izlenmesi karmaşık olabilir. Özellikle uygulama büyüyüp birden fazla webhook'a bağımlı hâle geldikçe bu daha da belirginleşir. Tüm webhook'ların doğru çalışmasını sağlamak ve farklı endpoint'leri takip etmek dikkat gerektirir
- Aşırı yüklenme olasılığı: Çok sayıda eşzamanlı callback, alıcı uygulama üzerinde yük oluşturabilir; ancak rate limiting veya batching, ani artışların yönetilmesine yardımcı olabilir
GraphQL
- GraphQL, API'ler için bir sorgu dili ve veriler üzerinde tanımlanan tip sistemini kullanarak sorguları çalıştıran sunucu tarafı bir runtime'dır
- 2012'de Facebook tarafından geliştirilen ve 2015'te açık kaynak proje olarak yayımlanan GraphQL, geleneksel REST API'lere daha esnek ve verimli bir alternatif sunar
- GraphQL'in geliştiriciler arasındaki benimsenme oranı %29'a yükselmiş durumda; bu da günümüz API ortamındaki önemini gösteriyor
- İlgili verileri almak için birden fazla API endpoint'inden geçmeyi gerektiren REST'in aksine, GraphQL ile ihtiyaç duyulan tüm veriler tek bir sorguda alınabilir
- Bu özellik, veri alma süreci üzerinde daha fazla kontrol sağladığı ve daha dinamik, daha duyarlı kullanıcı arayüzleri oluşturmayı mümkün kıldığı için özellikle frontend geliştiricileri açısından faydalıdır
- GraphQL'in avantajları
- Güçlü tipli şema: GraphQL API'lerinde güçlü tipli bir şema bulunur; bu sayede geliştiriciler sorguda hangi veri ve tiplerin kullanılabildiğini tam olarak bilir
- Hassas veri alma: İstemciler ihtiyaç duydukları tam veriyi isteyebilir; bu da over-fetching ve under-fetching sorunlarını çözer, performansı artırır ve maliyeti düşürür
- Sorgu karmaşıklığı ve çeşitli kaynaklar: GraphQL, tek bir istekle birden fazla veri tipinin sorgulanmasını destekler; bu da karmaşık ve birbiriyle ilişkili veriler için ağ isteklerinin sayısını azaltır
- Subscription ile gerçek zamanlı güncellemeler: GraphQL, subscription'lar aracılığıyla gerçek zamanlı senkronizasyonu destekler; böylece istemci gerçek zamanlı güncellenir
- İntrospection: GraphQL'in self-documenting şeması, kendi kendini inceleme yeteneği sayesinde geliştirmeyi kolaylaştırır
- GraphQL'in zorlukları
- Sorgu karmaşıklığı: GraphQL'in istemciye sağladığı esnekliğin bir bedeli vardır. Aşırı karmaşık veya iç içe sorgular performansı olumsuz etkileyebilir
- Öğrenme eğrisi: Mutation ve subscription gibi yeni kavramlar nedeniyle GraphQL'in öğrenme eğrisi REST'ten daha diktir
- Sürümleme: Sorguların esnek yapısı, şema değişikliklerinin mevcut sorguları bozabileceği ve sürümlemeyi karmaşıklaştırabileceği anlamına gelir
- Kaynakların aşırı kullanım ihtimali: İstemci tek bir sorguyla birden çok kaynağı isteyebildiği için ihtiyaçtan fazla veri çekilebilir ve sunucu aşırı yüklenebilir
- Güvenlik sorunları: Kötü niyetli kullanıcılar, karmaşık sorgularla sunucuyu aşırı yüklemek için GraphQL'in esnekliğini kötüye kullanabilir
SOAP
- SOAP(Simple Object Access Protocol), web servislerini gerçekleştirmek için yapılandırılmış bilgilerin değişimini sağlayan bir protokoldür
- Mesaj formatı olarak XML kullanır ve genellikle mesaj müzakeresi ile taşıma katmanı için HTTP veya SMTP'den yararlanır
- REST ve GraphQL'den farklı olarak SOAP; ACID uyumlu işlemler, güvenlik ve mesajlaşma kalıpları gibi katı standartlara ve yerleşik özelliklere sahiptir
- Kullanım oranı geliştiricilerin yalnızca %26'sına düşmüş olsa da SOAP, belirli uygulamalar için güvenilir bir seçimdir
- SOAP'un avantajları
- Güçlü tipleme ve sözleşme: WDSL(Web Services Description Language) belgesinde tanımlanan güçlü tipleme ve katı sözleşmeler vardır
- Yerleşik güvenlik özellikleri: SOAP, WS-Security standardı üzerinden uygulanan kimlik doğrulama, yetkilendirme ve şifreleme sayesinde kapsamlı güvenlik sunar. Bu nedenle kurumsal uygulamalarda tercih edilen bir seçenektir
- ACID işlemleri: SOAP, finans veya sağlık sistemleri gibi veri bütünlüğünün kritik olduğu uygulamalar için gerekli ACID transaction desteğini sağlar
- Güvenilir mesajlaşma: SOAP, güvenilir mesaj teslimini garanti eder ve hataları iyi yönetir; bu nedenle mesaj teslim garantisinin önemli olduğu sistemler için çok uygundur
- Dil, platform ve taşıma bağımsızlığı: REST gibi SOAP servisleri de, temel programlama dili, platform ya da taşıma protokolünden bağımsız olarak XML anlayan her istemci tarafından kullanılabilir
- SOAP'un zorlukları
- Karmaşıklık ve öğrenme eğrisi: Katı standartları ve XML kullanımı nedeniyle SOAP'un uygulanması daha karmaşık olabilir; bu yüzden REST veya GraphQL gibi alternatiflere göre öğrenme eğrisi daha diktir
- Ayrıntılı mesajlar: SOAP mesaj başlıkları ciddi miktarda ek yük taşır; bu nedenle payload'lar REST ve GraphQL'deki JSON'a göre daha büyüktür. Bu durum performansı ve bant genişliği kullanımını etkileyebilir
- Sınırlı topluluk desteği: SOAP zemin kaybediyor; bu da topluluk desteğinin ve mevcut kütüphanelerin azaldığı anlamına geliyor
- Daha az esneklik: Sözleşme değiştiğinde hem istemcinin hem de sunucunun kendi implementasyonlarını güncellemesi gerekebilir; bu da dezavantaj olabilir
- Güvenlik duvarı sorunları: SOAP, HTTP/HTTPS dışındaki taşıma protokollerini kullanabilir; bu da firewall kısıtlamalarıyla karşılaşabileceği anlamına gelir. Sonuç olarak bazı dağıtım ortamlarında SOAP daha az çok yönlü olabilir
WebSocket
- WebSocket, istemci ile sunucu arasında kalıcı ve düşük gecikmeli çift yönlü bağlantı sağlayarak gerçek zamanlı veri aktarımını mümkün kılar
- HTTP'nin istek-yanıt döngüsünden farklı olarak WebSocket ile sunucu, ilk handshake sonrasında istediği anda istemciye veri gönderebilir
- Sohbet uygulamaları, çevrim içi oyunlar, işlem platformları vb. için anlık veri güncellemelerini kolaylaştırır
- Ankete göre geliştiricilerin %25'i WebSocket kullanıyor
- WebSocket'in avantajları
- Gerçek zamanlı çift yönlü iletişim: Gerçek zamanlı çift yönlü iletişim, her veri alışverişinde yeniden kurulması gereken HTTP bağlantılarına göre daha düşük gecikme sunar
- Daha düşük ek yük: İlk handshake'ten sonra bağlantı açık kaldığı için geleneksel HTTP isteklerindeki başlık ek yükü azalır
- Kaynakların verimli kullanımı: Kalıcı bağlantılar, long polling'e göre sunucu kaynaklarını daha verimli kullanır
- WebSocket'in zorlukları
- Uygulama karmaşıklığı: WebSocket implementasyonu diğer API mimarilerine göre daha karmaşık ve zaman alıcı olabilir. Özellikle WebSocket'in desteklenmediği ortamlarda fallback ihtiyacı düşünüldüğünde bu durum daha da belirginleşir
- Yerleşik özellik eksikliği: Güvenlik ve transaction için yerleşik özellikler sunan SOAP'un aksine WebSocket daha temel seviyededir; geliştiricilerin bu özellikleri kendilerinin uygulaması gerekir
- Kaynak tüketimi: Açık WebSocket bağlantıları genellikle long polling tekniklerinden daha verimli olsa da yine de sunucu kaynakları tüketir ve büyük ölçekte sorun yaratabilir
- Ağ kısıtlamaları: Bazı proxy'ler ve firewall'lar WebSocket'i desteklemez; bu da belirli ağ ortamlarında potansiyel bağlantı sorunlarına yol açabilir
gRPC
- "Google Remote Procedure Call" anlamına gelen gRPC, servisler arası iletişimi kolaylaştıran modern ve yüksek performanslı bir protokoldür
- HTTP/2 üzerine inşa edilmiştir ve servis yöntemleri ile mesaj formatlarını tanımlamak için protocol buffer'lardan yararlanır
- GET ve POST gibi standart HTTP fiillerini kullanan REST API'lerin aksine gRPC, servislerin programlama dilindeki işlevlere benzer özel metodlar sunmasına izin verir
- gRPC'nin avantajları
- Performans: HTTP/2 ve protocol buffer'lar sayesinde gRPC düşük gecikme ve yüksek throughput sağlayabilir
- Güçlü tipleme: SOAP ve GraphQL gibi gRPC de güçlü tipli bir yapıya sahiptir. Sonuç olarak tipler derleme zamanında doğrulandığı için hata sayısı azalır
- Çoklu dil desteği: gRPC; Go, Java, C# ve Node.js dahil çeşitli programlama dillerini üst düzeyde destekler
- Streaming: gRPC, akış hâlindeki istek ve yanıtları işleyebilir; bu da uzun süreli bağlantılar ve gerçek zamanlı güncellemeler gibi karmaşık kullanım senaryolarına uygun olmasını sağlar
- Bataryası içinde gelir: gRPC, load balancing, retry ve timeout gibi kritik özellikleri doğrudan destekler
- gRPC'nin zorlukları
- Tarayıcı desteği: Tarayıcıların yerel gRPC desteği hâlâ sınırlıdır; bu nedenle web uygulamalarında doğrudan istemci-sunucu iletişimi için uygun değildir
- Öğrenme eğrisi: Geliştiricilerin protocol buffer'ları, özel servis tanımlarını ve diğer gRPC özelliklerini nasıl kullanacağını öğrenmesi gerekir; bu da başlangıç verimliliğini düşürebilir
- Debug karmaşıklığı: Protocol buffer'lar insan tarafından okunabilir olmadığından gRPC API'lerini debug etmek ve test etmek, JSON API'lere göre daha zordur
Diğer API protokolleri
- MQTT : IoT gibi düşük bant genişlikli ağlar için optimize edilmiş hafif bir mesajlaşma protokolü. İstemciler broker üzerinden mesaj yayımlayabilir ve abone olabilir, ancak bazı güvenlik ve ölçeklenebilirlik özelliklerinden yoksundur
- AMQP : Güvenilir mesaj teslimi ve esnek mesaj yönlendirmesi sağlayan daha güçlü bir kurumsal mesajlaşma standardı. Ancak hafif protokollere kıyasla daha karmaşık olabilir ve daha fazla ek yük taşır
- SSE : HTTP üzerinden tek yönlü sunucudan istemciye iletişim sağlar; gerçek zamanlı güncellemeler için uygundur ancak çift yönlü yetenekten yoksundur
- EDI : Satın alma siparişleri, faturalar vb. elektronik belgeleri standartlaştırarak B2B iletişimini otomatikleştirir; ancak ilk maliyet yüksektir ve karmaşık altyapı gerektirir
- EDA : Bileşenlerin olaylara tepki verdiği event-driven mimariyi teşvik ederek ölçeklenebilir ama debug etmesi karmaşık gerçek zamanlı sistemleri mümkün kılar
Sonuç
- Geliştiriciler yeni mimarileri, protokolleri ve araçları benimsedikçe API ekosistemi gelişmeye devam ediyor
- REST, basitliği ve yaygınlığı sayesinde hâlâ baskın olsa da GraphQL ve gRPC gibi alternatifler; over-fetching ve geveze arayüzler gibi sorunlu noktaları ele alarak ilgi kazanıyor
- Ayrıca geliştiriciler, gerçek zamanlı iletişim ihtiyacı nedeniyle WebHooks ve WebSocket'e giderek daha fazla önem veriyor
- Birçok yaygın API kullanım senaryosunda REST; ölçeklenebilirlik, birlikte çalışabilirlik ve benimseme kolaylığı düşünüldüğünde sağlam bir varsayılan yaklaşım olmayı sürdürüyor. Buna ek olarak topluluk olgunluğunun avantajına da sahip
- Bununla birlikte her protokolün artıları ve eksileri var; uygulamalar daha karmaşık hâle geldikçe geliştiriciler API protokol araç setlerini GraphQL ve gRPC gibi özel çözümleri de kapsayacak şekilde akıllıca genişletiyor
- Her duruma uyan tek bir sihirli çözüm yerine, API geliştiricilerinin birden fazla protokolün güçlü ve zayıf yönlerini anlaması en iyisi
- REST, WebHook, WebSocket, GraphQL ve her biri kendine özgü avantajlar sunan diğer yaklaşımları birleştiren sistemler tasarlayarak geliştiriciler güçlü, verimli ve bakımı yapılabilir API'ler oluşturabilir
- Tek tek protokollerin popülerliği dalgalanmaya devam edecek olsa da en önemli eğilim, API ekosisteminde artan çeşitlilik
- Geliştiriciler, en uygun API çözümünü oluşturmak için bu çoklu protokol felsefesini benimsemeli
3 yorum
Güzel incelemişim :)
Sadece tek seferlik, basit bir aksiyonla biten bir iş değilse transaction zorunlu değil mi zaten? (Zorunlu olmasına rağmen REST’e ancak şimdi yönelme ironisi konusuna da katılıyorum haha)