İstek gövdesi ile HTTP GET

Uygulamamız için yeni bir RESTful web hizmeti geliştiriyorum.

Belirli varlıklar için bir GET yaparken müşteriler varlığın içeriğini isteyebilir. Bazı parametreler eklemek istiyorlarsa (örneğin, bir listeyi sıralamak gibi) bu parametreleri sorgu dizesine ekleyebilirler.

Alternatif olarak, insanların bu parametreleri istek gövdesinde belirleyebilmesini istiyorum. HTTP / 1.1 bunu açıkça yasaklıyor gibi görünmüyor. Bu, daha fazla bilgi belirtmelerine olanak tanır, karmaşık XML istekleri belirtmeyi kolaylaştırabilir.

Sorularım:

• Bu tamamen iyi bir fikir mi?
• HTTP istemcilerinin bir GET isteği içinde istek gövdelerini kullanma konusunda sorunları olacak mı?

http://tools.ietf.org/html/rfc2616

Roy Fielding'in GET isteği olan bir organı dahil etme hakkındaki yorumu .

Evet. Başka bir deyişle, herhangi bir HTTP istek iletisinin bir ileti gövdesi içermesine izin verilir ve bu nedenle iletileri bu düşünceyle ayrıştırması gerekir. Bununla birlikte, GET için sunucu semantiği, eğer varsa, bir gövdenin istek için anlamsal bir anlamı olmayacak şekilde sınırlandırılmıştır. Ayrıştırma ile ilgili gereksinimler, yöntem semantiği ile ilgili gereksinimlerden ayrıdır.

Yani, evet, bir vücudu GET ile gönderebilirsiniz ve hayır, bunu yapmak asla yararlı değildir.

Bu, teknik özellik bölümlere ayrıldıktan sonra tekrar işlenecek olan katmanlı HTTP / 1.1 tasarımının bir parçasıdır (devam eden çalışma).

.... Roy

Evet, GET ile bir istek gövdesi gönderebilirsiniz, ancak bunun bir anlamı olmamalıdır. Sunucuda ayrıştırarak ve içeriğine göre yanıtınızı değiştirerek bir anlam verirseniz , HTTP / 1.1 spesifikasyonu, bölüm 4.3'te bu öneriyi göz ardı ediyorsunuz :

[...] istek yöntemi, bir varlık-gövde için tanımlanmış anlambilim içermiyorsa, istek işlenirken ileti gövdesi göz ardı EDİLMELİDİR .

HTTP / 1.1 spesifikasyonu, bölüm 9.3'teki GET yönteminin açıklaması :

GET yöntemi, İstek URI'sı tarafından tanımlanan bilgileri ([...]) almak anlamına gelir.

istek gövdesinin, bir GET isteğindeki kaynağın tanımlamasının bir parçası olmadığını, yalnızca istek URI'sını belirtir.

Güncelleme "HTTP / 1.1 spec" olarak adlandırılan RFC2616 artık kullanılmamaktadır. 2014 yılında yerini RFC 7230-7237 aldı. Alıntı "ileti işlenirken ileti gövdesi yok sayılmalıdır" silindi. Şimdi sadece "İstek çerçeveleme yöntem semantiğinden bağımsızdır, yöntem bir ileti gövdesi için herhangi bir kullanım tanımlamasa bile" 2. tırnak "GET yöntemi, İstek-URI tarafından tanımlanmış her türlü bilgiyi almak anlamına gelir ... silindi. - Bir yorumdan

Eğer iken olabilir bunu insanların bu şekilde çalışmaya şeyler beklemeyin çünkü, açıkça HTTP spesifikasyonu tarafından engel teşkil etmez sürece, bunu kaçınarak öneriyoruz. Bir HTTP istek zincirinde birçok aşama vardır ve bunlar HTTP özelliğine "çoğunlukla" uymakla birlikte, emin olduğunuz tek şey, bunların web tarayıcıları tarafından geleneksel olarak kullanıldıklarıdır. (Şeffaf vekiller, hızlandırıcılar, A / V araç takımları vb. Şeyleri düşünüyorum.)

Bu, Sağlamlık İlkesi'nin arkasındaki ruhtur, kabaca "kabul ettiğiniz şeyde liberal olun ve gönderdiğiniz şeyde muhafazakar olun", bir şartnamenin sınırlarını iyi bir sebep olmaksızın zorlamak istemezsiniz.

Ancak, iyi bir nedeniniz varsa, bunun için gidin.

Önbelleğe alma özelliğinden yararlanmaya çalışırsanız muhtemelen sorunlarla karşılaşırsınız. Proxy'ler, parametrelerin yanıt üzerinde bir etkisi olup olmadığını görmek için GET gövdesine bakmayacaktır.

Ne restclient ne de REST konsolu bunu desteklemez ancak curl bunu desteklemez.

HTTP şartname bölümünde 4.3 diyor

İstek yönteminin (bölüm 5.1.1) belirtimi, isteklerde varlık gövdesi gönderilmesine izin vermiyorsa, ileti gövdesi bir istekte BULUNMAMALIDIR.

Bölüm 5.1.1 , çeşitli yöntemler için bizi bölüm 9.x'e yönlendirir. Hiçbiri bir mesaj gövdesinin dahil edilmesini açıkça yasaklamamaktadır. Ancak...

Bölüm 5.2 diyor

İnternet isteği tarafından tanımlanan kesin kaynak, hem İstek-URI'sı hem de Ana Bilgisayar üstbilgisi alanı incelenerek belirlenir.

ve Bölüm 9.3 diyor ki

GET yöntemi, İstek-URI'si tarafından tanımlanan herhangi bir bilgiyi (varlık biçiminde) almak anlamına gelir.

Hangi birlikte bir GET isteği işlenirken, bir sunucu istek-URI ve ana bilgisayar üstbilgi alan başka bir şey incelemek için gerekli değildir öneririz .

Özetle, HTTP spesifikasyonu GET ile bir ileti gövdesi göndermenizi engellemez, ancak tüm sunucular tarafından desteklenmiyorsa beni şaşırtmayacak kadar belirsizlik vardır.

Elasticsearch, bir kuruluşla GET isteklerini kabul eder. Hatta bu tercih edilen yol gibi görünüyor: Elasticsearch kılavuzu

Bazı istemci kitaplıkları (Ruby sürücüsü gibi) geliştirme modunda stdout'a cry komutunu kaydedebilir ve bu sözdizimini yoğun bir şekilde kullanır.

Ulaşmaya çalıştığınız şey, çok daha yaygın bir yöntemle ve GET ile bir yük kullanımına dayanmayan bir yöntemle uzun zamandır yapıldı.

Özel arama aralığınızı oluşturabilir veya daha RESTful olmak istiyorsanız, OpenSearch gibi bir şey kullanın ve sunucunun söylediği / arama gibi talimat verilen URI'ye POST isteği gönderin. Sunucu daha sonra arama sonucunu oluşturabilir veya son URI'yi oluşturabilir ve bir 303 kullanarak yeniden yönlendirebilir.

Bu, geleneksel PRG yöntemini takip etme avantajına sahiptir, önbellek aracılarının sonuçları önbelleğe almasına vb. Yardımcı olur.

Bununla birlikte, URI'ler ASCII olmayan herhangi bir şey için yine de kodlanır ve bu nedenle application / x-www-form-urlencoded ve multipart / form-data da öyle. Amacınız ReSTful senaryolarını desteklemekse, başka bir özel json formatı oluşturmak yerine bunu kullanmanızı tavsiye ederim.

Bir bedenle bir GET gönderebilir veya bir POST gönderebilir ve RESTish dindarlığından vazgeçebilirsiniz (o kadar da kötü değil, 5 yıl önce bu inancın sadece bir üyesi vardı - yorumları yukarıda bağlantılı).

Büyük kararlar da yoktur, ancak bir GET gövdesi göndermek bazı istemciler ve bazı sunucular için sorunları önleyebilir.

POST yapmanın bazı RESTish çerçevelerinde engeller olabilir.

Julian Reschke yukarıda "SEARCH" gibi standart olmayan bir HTTP üstbilgisi kullanılmasını önerdi.

Yukarıdakilerin her birini yapabilen ve yapamayan müşterileri listelemek en verimli olabilir.

Vücut ile bir GET gönderemeyen müşteriler (bildiğim):

• İstek Kemancı

Gövde ile bir GET gönderebilen müşteriler:

• çoğu tarayıcı

Bir gövdeyi GET'ten alabilen sunucular ve kütüphaneler:

• Apaçi
• PHP

Bir gövdeyi GET'ten ayıran sunucular (ve proxy'ler):

• ?

Bu soruyu IETF HTTP WG'ye sordum. Roy Fielding'in (1998'deki http / 1.1 belgesinin yazarı) yorumu

“... bir uygulama, alındığı takdirde bu organı ayrıştırmak ve atmaktan başka bir şey yapamazdı”

RFC 7213 (HTTPbis) şunları belirtir:

"Bir GET istek mesajındaki bir yükün tanımlanmış bir anlam bilgisi yoktur;"

Niyetin GET istek organları üzerindeki anlamsal anlamın yasak olduğu açıktır, bu da istek organının sonucu etkilemek için kullanılamayacağı anlamına gelir.

GET'te bir gövde eklerseniz, isteğinizi kesinlikle çeşitli şekillerde kıracak proxy'ler var .

Özet olarak, yapma.

Hangi sunucu onu yoksayacak? - fijiaaron 30 '12, 21:27

Örneğin, Google bunu görmezden gelmekten daha kötü yapıyor, bir hata olarak kabul edecek !

Basit bir netcat ile kendiniz deneyin:

$ netcat www.google.com 80
GET / HTTP/1.1
Host: www.google.com
Content-length: 6

1234

(1234 içeriğinin ardından CR-LF gelir, bu nedenle toplam 6 bayttır)

ve alacaksınız:

HTTP/1.1 400 Bad Request
Server: GFE/2.0
(....)
Error 400 (Bad Request)
400. That’s an error.
Your client has issued a malformed or illegal request. That’s all we know.

Ayrıca AkamaiGhost tarafından sunulan Bing, Apple, vb ... 400 Kötü İstek alırsınız.

Bu yüzden bir vücut varlığı ile GET isteklerini kullanmanızı tavsiye etmem.

Gönderen RFC 2616, bölüm 4.3 , "Mesaj Gövdesi":

Bir sunucu, herhangi bir istek üzerine bir ileti gövdesini okumalı ve iletmelidir; istek yöntemi varlık gövdesi için tanımlanmış anlambilim içermiyorsa, istek işlenirken ileti gövdesi göz ardı EDİLMELİDİR.

Yani, sunucular her zaman ağdan sağlanan herhangi bir istek gövdesini okumalıdır (İçerik Uzunluğunu kontrol edin veya yığınlanmış bir gövde vb. Okuyun). Ayrıca, vekil sunucuların bu tür talep organlarını iletmeleri gerekir. Daha sonra, RFC, verilen yöntem için gövdeye ilişkin anlambilim tanımlarsa, sunucu aslında istek gövdesini bir yanıt oluştururken kullanabilir. RFC Ancak, gelmez vücut için anlambilim tanımlamak, sunucu bunu görmezden gerekir.

Bu, yukarıdaki Fielding'in alıntısı ile uyumludur.

Bölüm 9.3 , "GET", GET yönteminin anlambilimini açıklar ve istek kuruluşlarından bahsetmez. Bu nedenle, sunucu bir GET isteğinde aldığı istek gövdesini yok saymalıdır.

XMLHttpRequest'e göre, geçerli değil. Gönderen standardı :

4.5.6 send()Yöntem

client . send([body = null])

İsteği başlatır. İsteğe bağlı argüman istek gövdesini sağlar. İstek yöntemi GETveya ise, bağımsız değişken yoksayılır HEAD.

Bir Atar InvalidStateErrorya devlet değilse istisna açılmış veya send()bayrak ayarlanır.

Yöntem şu adımları çalıştırmak gerekir:send(body)

1. Durum açılmazsa , bir InvalidStateErroristisna atın .
2. Eğer send()bayrak ayarlanırsa, bir atmak InvalidStateErroristisna.
3. İstek yöntemi GETveya ise HEAD, gövdeyi null olarak ayarlayın .
4. Eğer vücut null, bir sonraki adıma geçin.

Bununla birlikte, olması gerektiğini düşünmüyorum çünkü GET isteğinin büyük vücut içeriğine ihtiyacı olabilir.

Bu nedenle, bir tarayıcının XMLHttpRequest öğesine güveniyorsanız, muhtemelen çalışmaz.

Gerçekten web uygulamasına cacheble JSON / XML gövdesi göndermek istiyorsanız, verilerinizi koymak için tek makul yer RFC4648 ile kodlanmış sorgu dizesi : URL ve Dosya Adı Güvenli Alfabesi ile Temel 64 Kodlama . Tabii ki sadece JSON urlencode ve put URL parametresi değerindedir, ancak Base64 daha küçük sonuç verir. URL boyutu kısıtlamaları olduğunu unutmayın, bkz . Farklı tarayıcılarda bir URL'nin maksimum uzunluğu nedir? .

Base64'ün dolgu =karakterinin URL'nin param değeri için kötü olabileceğini düşünebilirsiniz , ancak öyle görünmüyor - bu tartışmaya bakın: http://mail.python.org/pipermail/python-bugs-list/2007-Şubat/037195.html . Ancak, dolgulu kodlanmış dize boş değere sahip param anahtarı olarak yorumlanacağı için, param adı olmadan kodlanmış verileri koymamalısınız. Gibi bir şey kullanırdım ?_b64=<encodeddata>.

Bunu tavsiye etmem, standart uygulamalara aykırıdır ve karşılığında çok fazla şey sunmaz. Vücudu seçenekler için değil içerik için saklamak istiyorsunuz.

Uygun olmayan base64 kodlu üstbilgilere ne olacak? "SOMETHINGAPP-PARAMS: sdfSD45fdg45 / aS"

Uzunluk kısıtlamaları hm. POST işlemelerinizin anlamlarını ayırt etmesini sağlayamaz mısınız? Sıralama gibi basit parametreler istiyorsanız, bunun neden bir sorun olacağını anlamıyorum. Sanırım endişelendiğin kesinlik.

Protokol OOP desteklemiyor gibi REST üzgünüm ve Getyöntem kanıttır. Çözüm olarak, bir DTO'nuzu JSON'a serileştirebilir ve ardından bir sorgu dizesi oluşturabilirsiniz. Sunucu tarafında, sorgu dizesini DTO'nun serisini kaldırabilirsiniz.

Bir göz atın:

• ServiceStack'ta ileti tabanlı tasarım
• WCF ile RESTful Mesaj Tabanlı Web Servisleri Oluşturma

İleti tabanlı yaklaşım, yöntem kısıtlamasını almanızı çözmenize yardımcı olabilir. İstek gövdesinde olduğu gibi herhangi bir DTO gönderebilirsiniz

Nelibur web hizmeti çerçevesi kullanabileceğiniz işlevsellik sağlar

var client = new JsonServiceClient(Settings.Default.ServiceAddress);
var request = new GetClientRequest
    {
        Id = new Guid("2217239b0e-b35b-4d32-95c7-5db43e2bd573")
    };
var response = client.Get<GetClientRequest, ClientResponse>(request);

as you can see, the GetClientRequest was encoded to the following query string

http://localhost/clients/GetWithResponse?type=GetClientRequest&data=%7B%22Id%22:%2217239b0e-b35b-4d32-95c7-5db43e2bd573%22%7D

Örneğin, Curl, Apache ve PHP ile çalışır.

PHP dosyası:

<?php
echo $_SERVER['REQUEST_METHOD'] . PHP_EOL;
echo file_get_contents('php://input') . PHP_EOL;

Konsol komutu:

$ curl -X GET -H "Content-Type: application/json" -d '{"the": "body"}' 'http://localhost/test/get.php'

Çıktı:

GET
{"the": "body"}

IMHO sadece JSONkodlanmış (yani. encodeURIComponent) Gönderebilir URL, bu şekilde HTTPözellikleri ihlal JSONve sunucu almak.

GET ile bir istek gövdesi kullanmaktan çok daha iyi seçeneklerin bir listesine sahipsiniz.

Her bir kategori için kategorileriniz ve öğeleriniz olduğunu varsayalım. Her ikisi de bir id ile tanımlanmalıdır (bu örnek için "catid" / "itemid"). Belirli bir "sırayla" başka bir "sortby" parametresine göre sıralamak istiyorsunuz. "Sortby" ve "order" için parametreleri iletmek istiyorsunuz:

Yapabilirsin:

1. Sorgu dizeleri kullanın, ör. example.com/category/{catid}/item/{itemid}?sortby=itemname&order=asc
2. Yollar için mod_rewrite (veya benzeri) kullanın: example.com/category/{catid}/item/{itemid}/{sortby}/{order}
3. İstekle ilettiğiniz tek tek HTTP başlıklarını kullanma
4. Bir kaynağı almak için farklı bir yöntem kullanın, örneğin POST.

Hepsinin dezavantajları vardır, ancak bir vücut ile bir GET kullanmaktan çok daha iyidir.

Popüler bir araç bunu kullansa bile, bu sayfada sıkça belirtildiği gibi, spesifikasyon tarafından yasaklanmamış olmasına rağmen, çok egzotik olmak hala oldukça kötü bir fikir olduğunu düşünüyorum.

Birçok ara altyapı bu tür talepleri reddedebilir.

Örneğin olarak, bu gibi web sitesinde önünde bulunan CDN bazılarını kullanarak unutun one :

Bir görüntüleyici GETisteği bir gövde içeriyorsa, CloudFront görüntüleyiciye bir HTTP durum kodu 403 (Yasak) döndürür.

Ve evet, istemci kitaplıklarınız da bu yorumda bildirildiği gibi bu tür isteklerin gönderilmesini desteklemeyebilir .

Spring framework's RestTemplate'i istemci programımda kullanıyorum ve sunucu tarafında bir Json gövdesi ile bir GET isteği tanımladım. Birincil amacım sizinkilerle aynı: istek çok sayıda parametreye sahip olduğunda, bunları vücuda koymak, onları uzun süreli URI dizesine koymaktan daha düzenli görünüyor. Evet?

Ancak, ne yazık ki, çalışmıyor! Sunucu tarafı aşağıdaki istisnayı attı:

org.springframework.http.converter.HttpMessageNotReadableException: Gerekli istek gövdesi eksik ...

Ancak ileti gövdesinin istemci kodum tarafından doğru bir şekilde sağlandığından eminim, bu yüzden sorun nedir?

RestTemplate.exchange () yöntemini izledim ve aşağıdakileri buldum:

// SimpleClientHttpRequestFactory.class
public class SimpleClientHttpRequestFactory implements ClientHttpRequestFactory, AsyncClientHttpRequestFactory {
    ...
    protected void prepareConnection(HttpURLConnection connection, String httpMethod) throws IOException {
        ...
        if (!"POST".equals(httpMethod) && !"PUT".equals(httpMethod) && !"PATCH".equals(httpMethod) && !"DELETE".equals(httpMethod)) {
            connection.setDoOutput(false);
        } else {
            connection.setDoOutput(true);
        }
        ...
    }
}

// SimpleBufferingClientHttpRequest.class
final class SimpleBufferingClientHttpRequest extends AbstractBufferingClientHttpRequest {
    ...
    protected ClientHttpResponse executeInternal(HttpHeaders headers, byte[] bufferedOutput) throws IOException {
        ...
        if (this.connection.getDoOutput() && this.outputStreaming) {
            this.connection.setFixedLengthStreamingMode(bufferedOutput.length);
        }

        this.connection.connect();
        if (this.connection.getDoOutput()) {
            FileCopyUtils.copy(bufferedOutput, this.connection.getOutputStream());
        } else {
            this.connection.getResponseCode();
        }
        ...
    }
}

Lütfen executeInternal () yönteminde, 'bufferedOutput' giriş bağımsız değişkeninin kodum tarafından sağlanan ileti gövdesini içerdiğine dikkat edin. Hata ayıklayıcıdan gördüm.

Ancak, preparConnection () nedeniyle, executeInternal () öğesindeki getDoOutput () yöntemi her zaman false değerini döndürür, bu da bufferedOutput öğesini tamamen yok sayılır! Çıkış akışına kopyalanmaz.

Sonuç olarak, sunucu programım ileti gövdesi almadı ve bu özel durumu attı.

Bu, Bahar çerçevesinin RestTemplate'i hakkında bir örnektir. Mesele şu ki, ileti gövdesi artık HTTP spec tarafından yasaklanmış olmasa bile, bazı istemci veya sunucu kitaplıkları veya çerçeveleri hala eski spesifikasyona uyup mesaj gövdesini GET isteğinden reddedebilir.