Yeni HTTP QUERY metodu

 (kreya.app)
13 puan yazan awbrg789 4 시간 전 | 7 yorum | WhatsApp'ta paylaş

RFC 10008 ile yeni tanımlanan HTTP QUERY metodunun açıklaması

Mevcut RESTful API'lerde karmaşık aramaları işlerken hem GET hem de POST'un sınırları vardı; bunu çözmek için uzun süren tartışmaların ardından QUERY metodu standartlaştırıldı

GET'in sınırları

  • Karmaşık filtreler veya ilişkisel sorgular URL parametreleriyle gönderildiğinde URL aşırı uzayabilir ve tarayıcı ya da sunucunun karakter sınırına takılabilir
  • ASCII dışı karakterler veya özel karakterler için kodlama gerektiğinden istek boyutu artar
  • Dizi veya iç içe yapıların ifade biçimi standartlaştırılmamıştır (roles[]=admin vs roles=admin)
  • Sunucu/ara katman yazılımları URL parametrelerini loglara kaydettiği için hassas veri aktarımında sorun çıkarabilir
  • GET ile istek gövdesi göndermek spesifikasyonda açıkça yasaklanmış değildir, ancak proxy/güvenlik duvarı/tarayıcıya göre işleme şekli değiştiğinden pratikte kullanılamaz

POST ile aşmanın sorunları

  • İstek gövdesi gönderilebilir, ancak POST non-idempotent olarak tanımlandığı için hata durumunda otomatik yeniden deneme güvenli değildir
  • Proxy veya ara katman yazılımları bunun salt okunur bir işlem olduğunu anlayamaz; bu nedenle otomatik önbellekleme gibi optimizasyonlar mümkün olmaz
  • Anlamsal olarak kaynak oluşturma/işleme için olan POST'u arama için kullanmak RESTful tasarım ilkeleriyle uyuşmaz

QUERY metodu

  • GET gibi safe ve idempotent olup, aynı zamanda istek gövdesi içerebilen yeni bir HTTP metodudur
  • Önbelleğe alınabilir, ancak uygulamada istek gövdesinin önbellek anahtarına dahil edilmesi gerektiğinden GET'e göre önbellekleme uygulaması daha karmaşıktır
  • Özetle temel amaç, "salt okunur isteklerde POST'un yerini almak"tır

Dikkat edilmesi gerekenler

  • İstemci/proxy/sunucu tarafında QUERY desteği hâlâ sınırlıdır ve tam destek zaman alabilir
  • Basit GET sorgu parametrelerinin yeterli olduğu durumlarda değişiklik yapmak gerekmez
  • Filtrelenmiş verinin URL olarak paylaşılması veya yer imlerine eklenmesi gerekiyorsa GET hâlâ daha uygundur

İlgili okumalar

7 yorum

 
jongyeol 2 시간 전

GET ile istek gövdesi göndermek spesifikasyonda açıkça yasaklanmış değil, ancak proxy/güvenlik duvarı/tarayıcıya göre işleme biçimi değiştiği için pratikte kullanılamaz.

Ee... Proxy/güvenlik duvarı/tarayıcıların önümüzdeki yaklaşık 10 yıl boyunca QUERY metodunu da hâlâ uygulamamış olabileceği hiç düşünülmedi mi? Yoksa çok uzun vadeyi düşünerek mi yapıldı acaba.
 
tesha001 30 분 전

Muhtemelen ikincisidir.
 
click 3 시간 전

Bir şirketin servis API’sinin POST alırken URL parametreleri de birebir verilmezse çalışmadığı bir sorun yaşadığını hatırlıyorum.
Türkiye’de bile PUT ya da DELETE için “bu da ne?” denilen durumlar epey var; QUERY’nin de yerleşmesi ne kadar sürer bilmiyorum.
 
savvykang 2 시간 전

???: POST güvenlik açısından iyidir
 
sea715 3 시간 전

??? : REST’le uğraşmayın, her şeyi doğrudan POST’ta birleştirin
 
carnoxen 4 분 전

https://apidocs.bithumb.com/reference/…

Bithumb da eskiden yalnızca bilgi alınırken bile mutlaka POST kullanıyordu, ama şimdi değişmiş görünüyor.
 
ultimategamer 1 시간 전

RFC belgesi sanırım https://datatracker.ietf.org/doc/rfc10008/.
GET'in URL'nin uzaması gibi bir dezavantajı var, ama ElasticSearch'te belirli bir sorgu filtresi sonucunu paylaşmak istemek gibi durumlarda URL adresini olduğu gibi paylaşabilme avantajı da var gibi görünüyor.

GET istekleri tarayıcı adres çubuğuna yazılır varsayımıyla örtük olarak kullanılan birçok yer de olacağı için, yerleşmesi teknik desteğin ötesinde epey zaman alacak gibi görünüyor.