HTTP QUERY: 25 Yıl Sonra Gelen Yeni Metot ve POST-for-Query Döneminin Sonu

HTTP QUERY: 25 Yıl Sonra Gelen Yeni Metot ve POST-for-Query Döneminin Sonu

HTTP'nin ortaya çıkışının üzerinden çeyrek asır geçti. Bu süre içinde web sayfaları, API'ler, mikro servisler ve edge ağlar tamamen değişti. Ama temel HTTP metotları neredeyse aynı kaldı: GET, POST, PUT, DELETE. Haziran 2026'da IETF, bu dörtlüye yeni bir arkadaş kazandırdı: QUERY. RFC 10008 ile standartlaşan bu metot, teknik olarak GET'in body eksikliği ile POST'un yanlış semantiği arasındaki boşluğu dolduruyor. Pratikte ise yıllardır yaptığımız bir "mimari hileyi" resmileştiriyor.

HTTP metotları neden bu kadar yavaş evriliyor? Çünkü internetin temel protokollerinde yapılan her değişiklik, milyarlarca istemci, sunucu, proxy, tarayıcı ve kütüphaneyi etkiliyor. Geriye dönük uyumluluk (backward compatibility) olmadan yeni bir metot kabul görmez. Bu yüzden QUERY'nin yolculuğu yıllar süren taslak aşamalarından, topluluk tartışmalarından ve CDN devlerinin desteğinden geçerek Haziran 2026'da nihai standarda ulaştı.

Geliştiriciler olarak karmaşık arama, filtreleme veya sorgulama işlemlerini body üzerinden göndermemiz gerektiğinde ne yapıyorduk? POST kullanıyorduk. Elasticsearch sorgularında, MongoDB find işlemlerinde, GraphQL endpoint'lerinde durum böyleydi. Semantik olarak okuma yapıyor olmamıza rağmen, body taşıyabilen tek yol POST'tu. Bu yazıda QUERY'nin neden bu kadar geç kaldığını, neyi değiştirdiğini, nasıl çalıştığını ve CDN'ler için ne anlama geldiğini inceliyoruz.

Neden GET Yeterli Değildi?

GET, HTTP'nin en doğal sorgu metodu. Safe, idempotent ve varsayılan olarak cache'lenebilir. Ama GET'in tek bir büyük kısıtlaması var: tüm sorgu parametreleri URL'ye sığmalı. RFC 9110 göre HTTP uygulamaları en az 8000 oktet uzunluğundaki URI'leri desteklemeli. Ancak bu bir zorunluluk değil, tavsiye. Gerçek dünyada tarayıcılar, proxy'ler, yük dengeleyiciler ve log sistemleri çok daha kısa sınırlarla çalışıyor.

Bir e-ticaret sitesinde onlarca filtre, bir analiz panelinde karmaşık JSON filtre objesi veya bir GraphQL sorgusu düşünün. Bu verileri URL'ye sığdırmak hem verimsiz hem de riskli. URL'ler log dosyalarına yazılır, tarayıcı geçmişinde kalır, paylaşılabilir hale gelir. Hassas içerikleri sorgu parametresi olarak göndermek istemeyiz. Ayrıca her farklı sorgu kombinasyonu, protokol seviyesinde ayrı bir kaynak gibi görünür. Bu da cache yönetimini ve kaynak modellemesini zorlaştırır.

GET'in body taşıması teknik olarak yasak değil. RFC 9110, GET isteğinde body'nin "tanımlanmış bir semantiği olmadığını" söyler. Gönderirseniz gönderirsiniz ama proxy'ler, cache'ler ve sunucular onu göz ardı edebilir. Bu belirsizlik, GET-with-body desenini üretimde kullanılamaz kılar. Bir isteğin payload'ının yolda kaybolup kaybolmayacağını bilmek isteyen geliştirici, buna güvenemez.

Bu sınırlar, özellikle AI ve veri yoğun uygulamalarda daha belirgin hale geldi. Kurumsal yerel LLM deployment rehberimizde de vurguladığımız gibi, modern altyapıda her kilobayt ve her ek istek maliyetli. GET'in URL sınırları, büyük sorgular göndermeyi imkansız kılmıyor ama güvenilir ve ölçeklenebilir yapmıyor.

Neden POST Yanlış Bir Tercihti?

GET yetmediğinde geliştiriciler doğal olarak POST'a yöneldi. POST body taşıyabilir, herkes bunu bilir. Ama POST'un semantiği "bu istek bir kaynak oluşturabilir veya durum değiştirebilir" demektir. Bu varsayım, altyapının her katmanında karşımıza çıkar.

İlk problem cache. POST yanıtları varsayılan olarak cache'lenmez. Cache'lenebilse bile genellikle sadece gelecekteki GET veya HEAD istekleri için saklanabilir. Yani CDN'ler, arama sonuçlarını POST ile gelen istekler için otomatik olarak cache'leyemez. İkinci problem retry. POST idempotent değildir. Ağ kesintisinde istemci "bu isteği tekrar göndersem yanlışlıkla iki kez kayıt mı oluştururum?" diye düşünmek zorunda kalır. Otomatik retry mekanizmaları POST için güvenli değildir.

Üçüncü ve en derin problem protokol seviyesindeki belirsizlik. Biz bir endpointin "sadece okuma" yaptığını belgelere yazabiliriz. Ama HTTP katmanı bunu bilmiyor. Yük dengeleyici read-only bir kopyaya yönlendiremez, monitoring araçları okuma/yazma ayrımını otomatik yapamaz, audit log'ları "bu POST'un sorgu olduğu" şeklinde yorumlamak zorunda kalır. POST-for-query deseni yıllardır işe yaradı, ama her zaman bir kırbaçlama (workaround) olarak kaldı.

Bu desenin bir başka yan etkisi, kullanıcı deneyimiydi. Bir arama formunu POST ile gönderip sonuç sayfasına geldiğinizde, sayfayı yenilediğinizde tarayıcı "formu tekrar göndermek istiyor musunuz?" uyarısı verir. Çünkü tarayıcı POST'un idempotent olup olmadığını bilemez. QUERY ile bu uyarl ortadan kalkar; yenileme güvenli bir okuma işlemidir.

QUERY Ne Değiştiriyor?

RFC 10008, QUERY'yi şöyle tanımlıyor: "QUERY, hedef kaynağın içeriği güvenli ve idempotent bir şekilde işlemesini ve işlemenin sonucunu yanıt olarak döndürmesini ister." Bu cümle teknik olarak şu anlama geliyor: QUERY, body taşıyabilen bir GET.

QUERY'nin dört temel özelliği var. Safe: Hedef kaynak üzerinde önemli bir durum değişikliği beklenmez. Idempotent: Aynı isteği bir kez veya beş kez göndermek aynı sonucu verir. Cache'lenebilir: Ara sunucular ve CDN'ler yanıtları saklayabilir. Body taşıyabilir: Sorgu içeriği istek gövdesinde gönderilir, URL sınırlarına takılmazsınız.

RFC'nin yazarları da ilginç. RFC 10008'in yazarları arasında Julian Reschke (greenbytes), James M. Snell (Cloudflare) ve Mike Bishop (Akamai) bulunuyor. Yani bu spesifikasyonu yazanlar arasında hem CDN devleri hem de HTTP alanındaki en deneyimli isimler var. Bu, QUERY'nin sadece bir kağıt üzerindeki yenilik olmadığını, altyapı sağlayıcılarının da desteğini aldığını gösteriyor.

Reschke, HTTP uzantıları ve WebDAV gibi konularda uzun yıllardır yazılan spesifikasyonlara katkıda bulunuyor. Snell, Cloudflare'de HTTP ve edge teknolojileri üzerine çalışıyor. Bishop ise Akamai'de HTTP/2 ve HTTP/3 gibi protokollerde önemli roller üstlenmiş bir isim. Bu üçlü, QUERY'nin hem teori hem de pratik açıdan sağlam temellere oturduğunu gösteriyor.

Bir QUERY isteği şöyle görünebilir:

QUERY /search HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "filters": {
    "category": "electronics",
    "price_min": 100,
    "price_max": 500
  },
  "sort": "price_asc",
  "limit": 50
}

Sunucu 200 OK ile sonuçları dönebileceği gibi, 303 See Other ile sonuçların bulunduğu bir kaynağı işaret edebilir. İkinci durumda istemci, Location header'ındaki URI'ye GET yaparak sonuçlara erişir. Bu özellikle CDN'ler için kullanışlıdır; çünkü sonuçlar normal bir GET kaynağı gibi cache'lenebilir.

RFC ayrıca Accept-Query header'ını tanımlıyor. Sunucu, bu header ile hangi sorgu formatlarını kabul ettiğini bildirebilir. Örneğin Accept-Query: application/graphql, application/json gibi bir yanıt, istemciye sunucunun hangi içerik türleriyle QUERY kabul ettiğini söyler. Bu da API keşfini ve istemci-sunucu anlaşmasını kolaylaştırır.

GET, POST ve QUERY Karşılaştırması

Aşağıdaki karşılaştırma, üç metodun neden farklı senaryolar için tasarlandığını özetliyor. QUERY'nin GET ve POST'un en iyi yanlarını bir araya getirdiğini görebilirsiniz.

Karşılaştırmaya baktığımızda GET'in semantik olarak mükemmel ama body taşıyamadığı, POST'un body taşıyabildiği halde safe ve idempotent olmadığı net şekilde görülüyor. QUERY ise bu ikisinin eksik kaldığı noktada duruyor. Tabii bu, QUERY'nin her POST'u veya GET'i yerini alacağı anlamına gelmiyor. CREATE, UPDATE, DELETE işlemleri için POST, PUT, PATCH, DELETE hâlâ doğru adres. Ama okuma amaçlı sorgular için artık daha doğru bir seçenek var.

CDN'ler ve Altyapı Etkisi

Başlı başına bir yenilik olan QUERY'nin en büyük etkisini muhtemelen CDN katmanında göreceğiz. Hacker News'teki tartışmada da belirtildiği gibi, mevcut cache motorları URL + header kombinasyonuna göre cache key oluşturur. QUERY ile birlikte cache key'inin body'i de içermesi gerekiyor. Bu, teknik olarak zor bir geçiş.

Cache key olarak body kullanmanın iki temel zorluğu var. Birincisi, body'nin bit düzeyinde karşılaştırılması gerekebilir. Kullanıcı boşluk, satır sonu veya sıralama farklılıklarıyla her seferinde farklı bir body gönderirse cache isabet oranı düşer. İkincisi, bazı medya türlerinde (örneğin form-encoded veriler) parametre sırası anlamsızken, bazılarında (örneğin GraphQL sorguları) önemli olabilir. Cache motorlarının body'leri normalize etmesi, güvenlik açıklarına yol açabilecek hassas bir işlem.

Ancak bu zorluklar çözülemez değil. CDN sağlayıcıları body'yi hashleyerek (örneğin SHA-256) cache key oluşturabilir. RFC, cache key oluşturma için anlamsız farklılıkların normalize edilebileceğini de belirtiyor. James Snell'in Cloudflare'de, Mike Bishop'ın Akamai'de olması, bu iki devin QUERY desteğini erken aşamada değerlendirdiğini gösteriyor. Cloudflare, Fastly ve CloudFront gibi platformların QUERY yanıtlarını cache'lemeye başladığı dönem, arama odaklı backend sistemlerinin maliyet ve performans eğrisini değiştirecek.

Bu noktada Vercel Eve agent framework incelememizde de dokunduğumuz bir konu öne çıkıyor: web altyapısındaki her yeni standart, framework'lerden önce CDN ve edge katmanında hayat buluyor. QUERY için de benzer bir süreç beklemek mantıklı.

Ekonomik etkiyi abartmamak lazım. QUERY, ani bir maliyet devrimi değil. Ama yüksek sorgu hacimli sistemlerde cache isabet oranını artırmak, origin'e düşen yükü azaltmak ve otomatik retry ile uptime'ı iyileştirmek anlamına gelir. Uzun vadede, arama motorları, analiz panelleri ve AI tabanlı sorgu API'leri için önemli bir optimizasyon olacaktır.

Bir diğer fayda, gözlemlenebilirlik. QUERY ile bir isteğin okuma amaçlı olduğu protokol seviyesinde belli. Logları, metrikleri ve alarm kurallarını buna göre ayarlamak kolaylaşır. Read-only replica'lara yönlendirme, sorgu yoğunluğuna göre auto-scaling ve maliyet ayrıştırma gibi işlemler için QUERY, POST'a kıyasla çok daha net sinyaller verir.

Gerçek Dünya Kullanım Alanları

QUERY'nin faydasını en net göreceğimiz alanlardan biri GraphQL. Bugün GraphQL, hem okuma hem yazma işlemlerini tek endpoint üzerinden POST ile gönderiyor. Bu, GraphQL'in esnekliğinin bedeli. QUERY standartlaştıktan sonra GraphQL Foundation, okuma işlemlerini QUERY'ye taşıma konusunda temiz bir yola sahip. Sorgu dili değişmeyecek, sadece taşıyıcı protokol daha doğru hale gelecek.

Elasticsearch, OpenSearch ve benzer arama motorlarında sorgular genellikle JSON body içinde gönderilir. Bugün bu istekler POST ile yapılıyor. QUERY'ye geçiş, bu sistemlerin yanıtlarının HTTP katmanında cache'lenmesini mümkün kılar. MongoDB find işlemleri, REST API'lerdeki karmaşık filtreleme endpoint'leri, SQL-over-HTTP sorguları da aynı şekilde QUERY'nin hedef alanında.

Pratik bir örnek üzerinden gidelim. Bir SaaS ürününün raporlama ekranında kullanıcı, 20'den fazla filtre seçiyor ve sonuçları çeşitli metriklere göre sıralıyor. Bu sorguyu GET ile göndermek imkansıza yakın. POST ile göndermek ise aynı raporu tekrar açtığınızda sunucuya yeniden yük bindirir. QUERY ile hem büyük body gönderebilirsiniz hem de sonuçlar CDN'de saklanabilir. Kullanıcı aynı raporu birkaç kez açtığında, ilk açılıştan sonraki istekler edge'den dönebilir.

Yazılım geliştirmede performans ve doğruluk arasındaki denge sürekli değişiyor. Kimi K2.7 Code analizimizde de gördüğümüz gibi, küçük bir protokol veya mimari iyileştirme, büyük ölçekte ciddi kazanımlar yaratabiliyor. QUERY de tam olarak bu türden bir iyileştirme: tek başına devrim değil, ama birikmiş bir verimsizliği ortadan kaldırıyor.

Benimseme Süreci Ne Kadar Hızlı Olacak?

RFC yayınlandı diye yarın sabah tüm API'ler QUERY'ye dönmeyecek. Benimseme, yığından yukarıya doğru ilerleyecek. İlk hamleyi muhtemelen curl, OpenSSL ve edge proxy'ler yapacak. curl gibi araçlar yeni metodu desteklediğinde, test ve entegrasyon işleri kolaylaşacak. Ardından Nginx, Apache, HAProxy gibi sunucu ve proxy'ler, sonra da Express, FastAPI, Django, Spring gibi framework'ler güncellenecek.

Tarayıcı tarafı daha yavaş olacak. fetch() API'sinin QUERY'yi desteklemesi için WHATWG'de çalışma gerekiyor. Ayrıca QUERY, CORS safelisted metotlar listesinde değil. Bu yüzden cross-origin QUERY istekleri preflight OPTIONS isteği gerektirecek. Bu da frontend'den doğrudan kullanımı biraz yavaşlatacak bir faktör.

CDN tarafı ise kritik. Cloudflare ve Akamai'in spec'te yer alması, bu iki şirketin desteği erken değerlendirdiğinin işareti. Fastly, CloudFront ve diğerleri muhtemelen piyasa baskısı ve müşteri talebiyle takip edecek. Arama ve sorgulama yoğun uygulamaların maliyetleri düşecek, özellikle edge cache isabet oranı yüksek senaryolarda latency gözle görülür şekilde azalabilir.

Kurumsal ortamlarda geçiş daha yavaş olur. Mevcut API'lerin dönüştürülmesi, istemci kütüphanelerinin güncellenmesi ve test süreçleri gerektirir. Çoğu ekip, önce yeni endpoint'lerde QUERY'yi deneyip sonra mevcut POST-for-query uç noktalarını taşıyacaktır. Geriye dönük uyumluluk (backward compatibility) yıllarca sürebilir.

Eleştiriler ve Dikkat Edilmesi Gerekenler

Her yeni standart gibi QUERY'nin de eleştirileri var. En yaygın endişe, body tabanlı cache key'lerinin kötüye kullanılabilir olması. Bir saldırgan, her isteğin body'sini biraz değiştirerek cache'i doldurabilir. Bu nedenle CDN'lerin sorgu body'lerini normalleştirirken dikkatli olması ve sınırlar koyması gerekir.

Bir diğer konu canonicalization. JSON gibi formatlarda whitespace farklılıkları anlamsızdır, ama GraphQL sorgularında yorumlar veya alias'lar farklı sonuçlara yol açabilir. Cache motoru hangi farklılıkları yok saymalı, hangilerini dikkate almalı? Bu sorunun genel bir cevabı yok; her uygulama kendi medya tipine göre karar vermeli.

Çok katı bir canonicalization politikasi, farklı sorguların aynı cache key'e düşmesine ve yanlış sonuç dönülmesine yol açabilir. Çok gevşek bir politika ise cache isabet oranını düşürür. Bu dengeyi kurmak, CDN sağlayıcılarının ve API geliştiricilerinin ortak çalışmasını gerektirecek.

Bir diğer göz ardı edilmemesi gereken nokta, güvenlik. QUERY safe olsa da, sunucu tarafında hâlâ ağır sorgular işletilebilir. Bir kullanıcı, kötü tasarlanmış bir QUERY body'siyle veritabanını zorlayabilir. Bu yüzden rate limiting, sorgu süresi sınırları ve erişim kontrolleri QUERY için de geçerli.

Son olarak, QUERY'nin GET'in yerini almayacağını tekrar etmekte fayda var. Basit sorgular hâlâ GET ile çok daha uygundur. URL'ye sığan, paylaşılabilir, bookmark edilebilir sorgular için GET hâlâ kral. QUERY, GET'in yetmediği yerlerde devreye giren bir tamamlayıcı.

Sonuç: Protokol, Pratiği Takip Eder

HTTP QUERY, 25 yıl sonra gelen yeni bir metottan çok daha fazlası. Yıllardır geliştiricilerin POST ile çözmek zorunda kaldığı bir sorunu protokol seviyesinde çözüyor. Safe, idempotent, cacheable ve body taşıyabilen bir metot, Elasticsearch'ten GraphQL'e, MongoDB'den REST arama endpoint'lerine kadar birçok sistemi etkileyecek.

Asıl dönüşüm, CDN'lerin QUERY yanıtlarını cache'lemeye başladığı gün gerçekleşecek. O gün, arama sonuçlarının büyük kısmı edge'den dönecek ve origin sunucuları sadece cache miss'leri işlemek zorunda kalacak. Cloudflare, Akamai, Fastly ve CloudFront gibi sağlayıcıların desteği, arama odaklı backend'lerin maliyet ve performans eğrisini değiştirebilir. Bu geçiş birkaç haftada bitmeyecek, ama yön belli. Geliştiriciler olarak şimdilik yapabileceğimiz en iyi şey, RFC'yi okumak, mevcut POST-for-query endpoint'lerini not etmek ve framework desteğini takip etmek.

Siz QUERY'yi ne zaman kullanmaya başlamayı düşünüyorsunuz? Mevcut POST ile çalışan arama endpoint'lerinizi değiştirmek için bir planınız var mı? Yorumlarda veya sosyal medyada düşüncelerinizi paylaşabilirsiniz. Daha fazla sistem tasarımı, altyapı ve AI içeriği için blog ana sayfasını takip edebilirsiniz.