Bir HTTP GET isteğinde, parametreler sorgu dizesi olarak gönderilir :

http://example.com/page ? parametre = değer & ayrıca = başka

Bir HTTP POST isteğinde, parametreler URI ile birlikte gönderilmez.

Değerler nerede? İstek başlığında mı? İstek gövdesinde? Nasıl görünüyor?

Değerler, istek gövdesinde, içerik türünün belirttiği biçimde gönderilir.

Genellikle içerik türü application/x-www-form-urlencoded, bu nedenle istek gövdesi sorgu dizesiyle aynı biçimi kullanır:

parameter=value&also=another

Formda bir dosya yükleme kullandığınızda, multipart/form-databunun yerine farklı bir biçime sahip olan kodlamayı kullanırsınız. Daha karmaşık, ancak genellikle neye benzediğini umursamanıza gerek yok, bu yüzden bir örnek göstermeyeceğim, ancak var olduğunu bilmek iyi olabilir.

İçerik HTTP başlıklarının arkasına yerleştirilir. HTTP POST formatı, HTTP üstbilgilerini, ardından boş bir satır ve ardından istek gövdesini içermektir. POST değişkenleri gövdede anahtar / değer çiftleri olarak saklanır.

Bunu, aşağıda gösterilen bir HTTP Postasının ham içeriğinde görebilirsiniz:

POST /path/script.cgi HTTP/1.0
From: frog@jmarshall.com
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32

home=Cosby&favorite+flavor=flies

Bunu , tel üzerinden gönderilen ham HTTP isteğini ve yanıt yüklerini izlemek için kullanabileceğiniz Fiddler gibi bir araç kullanarak görebilirsiniz .

Kısa cevap: POST isteklerinde, değerler isteğin "gövdesinde" gönderilir. Web formlarında, büyük olasılıkla bir medya türü application/x-www-form-urlencodedveya ile gönderilir multipart/form-data. Dil veya genellikle istekleri ile "Doğruyu ™" yapmak ve (gibi kolay kolay deşifre değerlere erişmenizi sağlamayı sap web istekleri için tasarlanmıştır çerçeveler Programlama $_REQUESTveya $_POSTPHP veya cgi.FieldStorage(), flask.request.formPython).

Şimdi biraz fark edelim, bu farkı anlamaya yardımcı olabilir;)

Arasındaki fark GETve POSTisteklerine büyük ölçüde semantik bulunmaktadır. Ayrıca farklı şekillerde kullanılırlar, bu da değerlerin nasıl aktarıldığındaki farkı açıklar.

GET ( ilgili RFC bölümü )

Bir GETistek yürütürken , sunucudan bir veya bir dizi varlık istersiniz. İstemcinin sonucu filtrelemesine izin vermek için URL'nin "sorgu dizesi" ni kullanabilir. Sorgu dizesi, öğesinden sonraki bölümdür ?. Bu, URI sözdiziminin bir parçasıdır .

Bu nedenle, uygulama kodunuzun ( isteği alan kısım) bakış açısından, bu değerlere erişmek için URI sorgu bölümünü incelemeniz gerekecektir.

Anahtarların ve değerlerin URI'nin bir parçası olduğunu unutmayın. Tarayıcılar URI uzunluğu için bir sınır getirebilir . HTTP standardı sınır olmadığını belirtir. Ama bu yazının yazıldığı anda, çoğu tarayıcı yok URI'ları (ı belirli değerleri yok) sınırlar. GETistekleri gerektiğini asla sunucuya yeni bilgi göndermek için kullanılabilir. Özellikle büyük belgeler değil. POSTVeya kullanmanız gereken yer burası PUT.

POST ( ilgili RFC bölümü )

Bir POSTistek yürütülürken , istemci gerçekte uzak ana bilgisayara yeni bir belge gönderiyor . Bu nedenle, bir sorgu dizesi (anlamsal olarak) mantıklı değildir. Bu yüzden uygulama kodunuzda bunlara erişemezsiniz.

POSTbiraz daha karmaşık (ve bir yol daha esnek):

Bir POST isteği alırken, her zaman bir "yararlı yük" veya HTTP terimleriyle bir ileti gövdesi beklemelisiniz . İleti gövdesi, standart (anlayabildiğim kadarıyla. Belki application / octet-stream?) Formatı olmadığı için oldukça işe yaramaz . Gövde biçimi Content-Typebaşlık tarafından tanımlanır . İle bir HTML FORMöğesi kullanıldığında method="POST", bu genellikle olur application/x-www-form-urlencoded. Dosya yüklemelerini kullanıyorsanız , çok yaygın olan başka bir tür de çoklu bölüm / form verisidir. Ama olabilir şey arasında değişen text/plainüzerinde, application/jsonhatta özel application/octet-stream.

Her durumda, uygulama tarafından işlenemeyen bir POSTistek yapılırsa, Content-Typebir 415durum kodu döndürmelidir .

Çoğu programlama dilleri (ve / veya web çerçeveler) de bir yol sunar / kodlamak gelen / en yaygın türlerinden (benzerine mesaj gövdesi application/x-www-form-urlencoded, multipart/form-dataya da application/json). Yani bu kolay. Özel türler potansiyel olarak biraz daha fazla çalışma gerektirir.

Örnek olarak standart bir HTML formu kodlu belge kullanarak, uygulama aşağıdaki adımları gerçekleştirmelidir:

1. Content-TypeAlanı okuyun
2. Değer desteklenen medya türlerinden biri değilse, 415durum koduyla bir yanıt döndürün
3. aksi takdirde mesaj gövdesindeki değerleri deşifre edin.

Yine, PHP gibi diller veya diğer popüler diller için web çerçeveleri muhtemelen bunu sizin için halledecektir. Bunun istisnası 415hatadır. Hiçbir çerçeve, uygulamanızın hangi içerik türlerini desteklemeyi ve / veya desteklememeyi seçtiğini tahmin edemez. Bu size kalmış.

PUT ( ilgili RFC bölümü )

Bir PUTistek, bir istekle hemen hemen aynı şekilde ele alınır POST. En büyük fark, POSTsunucunun yeni bir kaynağın nasıl oluşturulacağına (ve eğer varsa) karar vermesine izin veren bir isteğin bulunmasıdır. Tarihsel olarak (artık kullanılmayan RFC2616'dan itibaren, talebin gönderildiği URI'nin "alt" (alt öğesi) olarak yeni bir kaynak oluşturmaktı).

PUTBuna karşılık bir talebin, kaynağı tam olarak bu URI'ye ve tam olarak bu içeriğe "yatırması" beklenir . Ne fazla ne az. Fikir müşteri "PUTting" önce tüm kaynağı oluşturmak için sorumlu olmasıdır. Sunucu , verilen URL'de olduğu gibi kabul etmelidir .

Sonuç olarak, POSTgenellikle varolan bir kaynağın yerini almak için bir istek kullanılmaz . Bir PUTistek yapmak hem oluşturabilir ve değiştirin.

Kenar notu

Ayrıca uzaktan kumandaya ek veri göndermek için kullanılabilecek " yol parametreleri " vardır, ancak çok nadirdir, burada çok fazla ayrıntıya girmeyeceğim. Ancak, referans olarak, RFC'den bir alıntı:

Hiyerarşik yollardaki nokta segmentlerinin yanı sıra, bir yol segmenti genel sözdizimi tarafından opak olarak kabul edilir. URI üreten uygulamalar genellikle şemaya özgü veya kayıttan çıkarılma özelliğine özgü alt bileşenleri sınırlandırmak için bir segmentte izin verilen ayrılmış karakterleri kullanır. Örneğin, noktalı virgül (";") ve eşittir ("=") ayrılmış karakterler genellikle bu segment için geçerli olan parametreleri ve parametre değerlerini sınırlamak için kullanılır. Virgül (",") ayrılmış karakteri genellikle benzer amaçlar için kullanılır. Örneğin, bir URI üreticisi "name" in 1.1 versiyonuna bir referansı belirtmek için "name; v = 1.1" gibi bir segment kullanabilir, diğeri ise bunu belirtmek için "name, 1.1" gibi bir segment kullanabilir. Parametre türleri şemaya özel anlambilim ile tanımlanabilir,

Doğrudan tarayıcı URL çubuğuna yazamazsınız.

Örneğin , POST verilerinin Internet'te Canlı HTTP Üstbilgileri ile nasıl gönderildiğini görebilirsiniz . Sonuç böyle bir şey olacak

http://127.0.0.1/pass.php
POST /pass.php HTTP/1.1

Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://127.0.0.1/pass.php
Cookie: passx=87e8af376bc9d9bfec2c7c0193e6af70; PHPSESSID=l9hk7mfh0ppqecg8gialak6gt5
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
username=zurfyx&pass=password

Nerede söylüyor

Content-Length: 30
    username=zurfyx&pass=password

gönderi değerleri olacak.

Bir POST isteği varsayılan medya türüdür application/x-www-form-urlencoded. Bu, anahtar / değer çiftlerini kodlamak için kullanılan bir biçimdir. Anahtarlar kopyalanabilir. Her anahtar / değer çifti bir &karakterle ayrılır ve her anahtar kendi değerinden bir =karakterle ayrılır .

Örneğin:

Name: John Smith
Grade: 19

Şu şekilde kodlanır:

Name=John+Smith&Grade=19

Bu, HTTP üstbilgilerinden sonra istek gövdesine yerleştirilir.

HTTP POST'larındaki form değerleri, sorgu gövdesiyle aynı biçimde istek gövdesinde gönderilir.

Daha fazla bilgi için teknik özelliklere bakın .

Bazı web hizmetleri, istek verilerini ve meta verileri ayrı ayrı yerleştirmenizi gerektirir . Örneğin, uzak bir işlev, veriler bir HTTP gövdesinde yayınlanırken, imzalı meta veri dizesinin bir URI'ye dahil edilmesini bekleyebilir.

POST isteği anlamsal olarak şu şekilde görünebilir:

POST /?AuthId=YOURKEY&Action=WebServiceAction&Signature=rcLXfkPldrYm04 HTTP/1.1
Content-Type: text/tab-separated-values; charset=iso-8859-1
Content-Length: []
Host: webservices.domain.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)

name    id
John    G12N
Sarah   J87M
Bob     N33Y

Bu yaklaşım mantıksal olarak QueryString ve Body-Post'u Content-Typebir web sunucusu için "ayrıştırma-talimatı" olan tek bir komut kullanarak birleştirir .

Lütfen not: HTTP / 1.1 olduğu sarılı ile #32solda ve birlikte (boşluk) #10sağda (Hat besleme).

Her şeyden önce, GETvePOST

Get: Bu varsayılan HTTPsunucuya yapılır ve sonra gelen sunucu ve sorgu dizesi veri almak için kullanılan istek ?bir de URIeşsiz bir kaynak almak için kullanılır.

format bu

GET /someweb.asp?data=value HTTP/1.0

Burada data=valuegeçirilen sorgu dizesi değeri.

POST: Verileri sunucuya güvenli bir şekilde göndermek için kullanılır, böylece gereken her şey, bu bir POSTisteğin biçimidir

POST /somweb.aspHTTP/1.0
Host: localhost
Content-Type: application/x-www-form-urlencoded //you can put any format here
Content-Length: 11 //it depends
Name= somename

Neden GET üzerinden POST?

Gelen GETgenellikle sorgu dizesinde temel URL'ye eklenir sunucularına gönderilmeden değeri, şimdi bu 2 sonuçları vardır

• GETİstekleri parametrelerle tarayıcı geçmişinde kaydedilir. Böylece şifreleriniz tarayıcı geçmişinde şifrelenmeden kalır. Bu, o günlerde Facebook için gerçek bir konuydu.
• Genellikle sunucular a'nın ne kadar uzun URIolabileceği konusunda bir sınıra sahiptir . Çok fazla parametre gönderiliyorsa,414 Error - URI too long

Sonradan istek olması durumunda, alanlardaki verileriniz gövdeye eklenir. İstek parametrelerinin uzunluğu hesaplanır ve içerik uzunluğu için başlığa eklenir ve doğrudan URL'ye önemli bir veri eklenmez.

Sunuculara isteklerin nasıl yapıldığına ilişkin temel bilgileri görmek için Google Geliştirici Araçları'nın ağ bölümünü kullanabilirsiniz.

ve her zaman daha değerleri ekleyebilirsiniz Request Headersbeğendiniz Cache-Control, Origin, Accept.