- QUERY adlı yeni bir HTTP metodu öneriliyor
- İstek sırasında içerik taşımaya izin veren, güvenli ve idempotent bir istek metodu
- İstekte gönderilen veri URI içinde kodlanamayacak kadar büyük olduğunda bu yöntem kullanılabilir
- Sorgu parametreleri birkaç KB'yi aştığında birçok uygulama sınırlama koyuyor
- Bu sınırı istekten önce önceden bilmek çoğu zaman mümkün değil ve kodlama gerektiği için verimsiz
- Bu yüzden birçok uygulama, sorgu gerçekleştirmek için GET yerine POST kullanıyor
- Ancak sunucu hakkında özel bilgi yoksa, bunun güvenli ve idempotent olup olmadığı gibi konular bilinemez; bu yüzden GET ile aynı temel kısıtlar geçerli olur
- QUERY metodu, GET ve POST kullanımı arasındaki boşluğu kapatan bir çözüm sunuyor
- POST'ta olduğu gibi, sorgu işlemi için giriş verisi istek URI'sinin bir parçası olarak değil, isteğin içeriğinde taşınır
- Ancak POST'tan farklı olarak bu metot açıkça güvenli ve idempotenttir; bu sayede önbellekleme ve otomatik yeniden deneme gibi özellikler mümkün olur
Request
QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: example/query
Accept: text/csv
select surname, givenname, email limit 10
Response
HTTP/1.1 200 OK
Content-Type: text/csv
Content-Location: /contacts/responses/42
Location: /contacts/queries/17
surname, givenname, email
Smith, John, john.smith@example.org
Jones, Sally, sally.jones@example.com
Dubois, Camille, camille.dubois@example.net
7 yorum
Bunun neden protokole eklenmesi gerektiğini anlamıyorum.
Sorgu parametrelerinin birkaç KB'yi aştığı senaryolar gerçekten bu kadar fazla mı?
https://www.baeldung.com/cs/http-get-with-body
HTTP spesifikasyonu, okura kendi yorumuna alan bırakıyor ve tutarsız biçimde değiştiği için, işi yeni bir metot yaratma noktasına kadar götürüyor gibi görünüyor
İstek gövdesiyle GET
Bazı client library’lerde GET isteği gönderirken request body iletmenin bir yolu hiç yok; bu da buna bir alternatif olabilir gibi görünüyor
Kütüphane implementasyonu açısından bakarsak, aslında daha da gereksiz bir standart değişikliği önerisi değil mi?
Standart spesifikasyona göre GET bir request body’ye sahip olamazken, kütüphane keyfi olarak request body gönderiyor yani...
Öyleyse doğrudan kütüphane katmanında custom bir metod implemente etmek de sorun olmazdı, değil mi?
Gerekliliğini tamamen reddetmek zor olsa da, HTTP 1.0’dan 1.1’e geçerken ortaya çıkan PUT, PATCH, DELETE vb. ile kıyaslandığında ikna ediciliği daha zayıf görünüyor.
https://www.rfc-editor.org/rfc/rfc9110.html#name-method-definitions
https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET
https://stackoverflow.com/questions/978061/http-get-with-request-body
https://elastic.co/guide/en/…
Standart spesifikasyonda GET Method için body kısmı açıkça belirtilmemiştir; ancak body koymayın diye bir ifade de yoktur.
Bazı sunucu framework'lerinde GET Method içinde body işlenmediği durumlar olduğu için MDN, GET Method'da body kullanılmamasını öneriyor.
Elasticsearch, GET Method'da Body'yi destekler.
Spesifikasyonun kütüphane implementasyonlarına göre değiştirilmesi gerekiyorsa, bunun daha fazla değerlendirilmesi gerekmez mi diye düşünüyorum.