POST'u ne zaman ve GET'i ne zaman kullanıyorsunuz?


343

Toplayabildiğim kadarıyla üç kategori var:

  1. Asla kullanma GETve kullanmaPOST
  2. Asla kullanma POSTve kullanmaGET
  3. Hangisini kullandığınız önemli değil.

Bu üç vakayı varsayar mıyım? Eğer öyleyse, her vakadan bazı örnekler nelerdir?


1
Aslında bu kesinlikle doğru değil. GET ve POST aynı derecede görünür, tarayıcınız tarafından gönderilen başlıklara bakarsanız, gönderdiğiniz anahtar / değer çiftlerinin bir listesini görürsünüz
Velimir Tchatchevsky


1
Sorgu dizelerine ad -> değer çiftlerinden daha fazlasını kodlamanın standart bir yolu yoktur, bu nedenle istekleriniz çok temel olmadığı sürece (yani, diziler veya iç içe veri yapıları yok), yalnızca kodlama formatlarıyla kullanabileceğiniz bir gövde alanı sağlayan POST'u düşünmelisiniz. (JSON, XML vb.).
themihai

Yanıtlar:


376

Tarayıcınızın adres çubuğundaki POSTbir POSTeyleme erişemediğiniz için oluşturma (ironiyi biliyorum), düzenleme ve silme gibi yıkıcı eylemler için kullanın . GETBir kişinin bir eylemi çağırmasına izin vermek güvenli olduğunda kullanın . Yani şöyle bir URL:

http://myblog.org/admin/posts/delete/357

Öğeyi silmek yerine sizi bir onay sayfasına götürmelidir. Kazaları bu şekilde önlemek çok daha kolay.

POSTGETbir URL'ye bilgi yapıştırmamanızdan da daha güvenlidir . Bu nedenle , bir şifre veya diğer hassas bilgileri toplayan bir HTML formu GETiçin methodfor kullanmak en iyi fikir değildir.

Son bir not: POSTdaha büyük miktarda bilgi iletebilir GET. 'POST' iletilen veriler için herhangi bir boyut kısıtlamasına sahip değildir, 'GET' ise 2048 karakterle sınırlıdır.


82
GET isteklerine verilen yanıtlar engellenebilir. POST'lara verilen yanıtlar olmamalıdır.
mkoeller

31
URL'ye bilgi yapıştırmak onu nasıl daha güvenli hale getirir? (Btw, sahte bir güvenlik duygusunun, güvenliğe sahip olmamaktan daha tehlikeli olduğuna inananlardan biriyim).
ePharaoh

42
@ ePharaoh: Kullanıcıların adres çubuğundaki omzuna bakarak şifreleri okumasını durdurur.
Quentin

35
@ePharaoh: "Sıradan bir gözlemciye biraz daha az veri maruz bırakmak" muhtemelen "daha güvenli" olmaktan daha iyi bir formülasyon olabilir - URL'ler günlükler, yönlendirmeler, önbellekler gibi birçok yere neden olabilir. Elbette, sağ, bu güvenlik artmaz edilir - ama kötü güvensiz uygulamaları (ayrıca bkz: sınırlayan thedailywtf.com/Articles/The_Spider_of_Doom.aspx )
Piskvor bina bıraktı

24
@David Dorward: Veya daha yaygın adı: omuz krizi
Idan K

206

Kısaca

  • İstekler GETiçin kullanınsafe andidempotent
  • İstekler POSTiçin kullanınneither safe nor idempotent

Ayrıntılarda Her biri için uygun bir yer var. RESTful prensiplerine uymasanız bile , REST ve kaynak odaklı bir yaklaşımın nasıl işlediği hakkında çok şey öğrenilebilir.

Her use GETsikisi de operasyonlar için RESTful bir uygulama olacaktır safe and idempotent.

Bir safeoperasyon etmeyen bir işlemdir not change the dataistedi.

Bir idempotentoperasyon sonucu alacağı biridir be the sameistediğinzde kaç kez önemli.

GET'ler güvenli operasyonlar için kullanıldıklarından , otomatik olarak aynı zamanda idempotent olmalarının da mantıklıdır . Tipik olarak bir GET, bir kaynağı (örneğin bir soru ve bunun yığın taşmasıyla ilgili cevapları) veya kaynakların toplanması için kullanılır.

RESTful bir uygulama PUTsolan işlemler için kullanacaktır not safe but idempotent.

Sorunun GET ve POST ile ilgili olduğunu biliyorum, ancak bir saniyede POST'a döneceğim.

Genellikle bir PUT bir kaynağı düzenlemek için kullanılır (örneğin, yığın taşmasıyla ilgili bir soru veya cevap düzenleme).

A POSTolan herhangi bir işlem için kullanılır neither safe or idempotent.

Tipik olarak bir POST, örneğin yeni bir SO sorusu oluşturmak için yeni bir kaynak oluşturmak için kullanılır (ancak bazı tasarımlarda bunun için bir PUT da kullanılır).

POST'u iki kez çalıştırırsanız, iki yeni soru oluşturacaksınız.

Ayrıca bir DELETE işlemi var, ama bunu orada bırakabileceğimi tahmin ediyorum :)

Tartışma

Pratik terimlerle modern web tarayıcıları genellikle GET ve POST'u güvenilir bir şekilde destekler (tüm bu işlemleri javascript aramalarıyla gerçekleştirebilirsiniz, ancak formlara veri girme ve gönder'e basma konusunda genellikle iki seçeneğiniz vardır). RESTful uygulamasında POST genellikle PUT ve DELETE çağrılarını sağlamak için geçersiz kılınır.

Ancak, RESTful ilkelerini izlemeseniz bile, bilgileri almak / görüntülemek için GET'i ve bilgi oluşturmak / düzenlemek için POST'u düşünmek yararlı olabilir.

Verileri değiştiren bir işlem için GET'i asla kullanmamalısınız. Bir arama motoru kötü operasyonunuza veya müşteri yer işaretlerine bir bağlantı tararsa, büyük sorunlara yol açabilir.


Eğer seçim yapacak giriş için APIREST kaynağı oluşturacaksanız, bu güvenli ve idempotent, ben misafir.
jhonny lopez

1
Güvenli bir alım otomatik olarak idempotent değildir. Sonuç kümesi, aynı tahribatsız sorgu ile farklı olabilir.
RichieHH

1
Yazdığınız şekilde, "ŞİMDİ GET AL" gibi bir şey yanlış olur çünkü idempotent değildir (tekrarlanan sorguların farklı sonuçlar üretebileceği anlamında); aslında sorgulanan her şey zaman içinde değişebilir. Bu yüzden , sorgulamanın kendisinin yan etkileri açısından değil, idempotence ifade edilmelidir . Sadece şimdiki zamanı sormanın hiçbir yan etkisi olmadığından , bu - beklendiği gibi - POST için değil, GET için mükemmel bir adaydır.
Hagen von Eitzen

79

Tekrarlanan isteğin bir sakıncası yoksa GET işlevini kullanın (Durum değiştirmez).

İşlem sistemin durumunu değiştirirse POST'u kullanın.


1
Bir form sistemin durumunu değiştirdiğinden, HTML form etiketinin varsayılan yöntemi neden GET'tir?
ziiweb

3
@ user248959 Arama kutusu görünür durumu değiştirir mi? Varsayılan, uzun zaman önce, muhtemelen neredeyse kazara ayarlandı. Nokta formlarında bir seçenek olup olmadığını POST bir seçenek olup olmadığını bilmek için tarihe girmedim.
Douglas Leeder

@ziiweb <form> kullanım örneklerinin çoğunluğu POST olsa bile, küstahlığı "zararsız" bir GET olarak tanımlamak daha iyidir. Bu, günlük dosyalarında vb. Açığa çıkan verilere yol açtığında bir güvenlik açısından saçma görünebilir, ancak sunucu tarafı verileriyle ilgili olarak arıza korumalıdır (hizmet, bir GET üzerindeki verileri değiştirmemelidir). Sanırım, bugün odak farklı olacak (tercihen herhangi bir temerrüde düşme ve methodzorunlu hale getirme )
Hagen von Eitzen

Bir dosyayı giriş olarak kabul eden, dosya üzerinde bazı işlemler yapan (örnek - normal ifadeye dayalı verileri ayıkla) ve JSON verilerini döndüren bir uç noktam olduğunu varsayalım, sonra sunucuya bir dosya yüklemek için GET isteğini kullanabilir miyim. Yoksa POST isteğini mi kullanmalıyım?
değişken

67

Kısa versiyon

GET: Genellikle gönderilen arama istekleri veya kullanıcının tam sayfayı tekrar alabilmesini istediğiniz herhangi bir istek için kullanılır.

GET'in avantajları:

  • URL'ler güvenli bir şekilde yer imlerine eklenebilir.
  • Sayfalar güvenli bir şekilde yeniden yüklenebilir.

GET'in dezavantajları:

POST: Veritabanını değiştirmek veya başkalarının yer işareti koymasını istemediğiniz bir sayfanın kullanılabileceği daha yüksek güvenlik istekleri için kullanılır.

POST'un Avantajları:

  • Ad-değer çiftleri url'de görüntülenmiyor. (Güvenlik + = 1)
  • POST ile sınırsız sayıda isim-değer çifti geçirilebilir. Referans.

POST'un dezavantajları:

  • POST verisi kullanılan sayfa yer işareti olamaz. (İsterseniz.)

Daha Uzun Versiyon

Doğrudan Köprü Metni Aktarım Protokolü'nden - HTTP / 1.1 :

9.3 ALIN

GET yöntemi, İstek-URI'si tarafından tanımlanan herhangi bir bilgiyi (varlık biçiminde) almak anlamına gelir. İstek URI'sı bir veri üretme sürecine atıfta bulunursa, bu metin sürecin çıktısı olmazsa, sürecin kaynak metni olarak değil yanıtta varlık olarak döndürülecek olan üretilen verilerdir.

İstek iletisi bir If-Modified-Since, If-Mododified-Since, If-Match, If-None-Match veya If-Range üstbilgisi alanı içeriyorsa, GET yönteminin semantiği "koşullu GET" olarak değişir. Koşullu bir GET yöntemi, kuruluşun yalnızca koşullu başlık alanları tarafından tanımlanan koşullar altında aktarılmasını ister. Koşullu GET yöntemi, önbelleğe alınan varlıkların birden fazla istek gerekmeden veya istemci tarafından zaten tutulan verileri aktarmadan yenilenmesine izin vererek gereksiz ağ kullanımını azaltmayı amaçlamaktadır.

İstek iletisi bir Aralık üstbilgisi alanı içeriyorsa, GET yönteminin anlam bilgisi "kısmi GET" olarak değişir. Kısmi bir GET, bölüm 14.35'te açıklandığı gibi, işletmenin sadece bir kısmının aktarılmasını talep eder. Kısmi GET yönteminin, kısmen alınan varlıkların zaten istemci tarafından tutulan veriler aktarılmadan tamamlanmasına izin vererek gereksiz ağ kullanımını azaltması amaçlanmıştır.

Bir GET isteğine yanıt, yalnızca ve yalnızca 13. bölümde açıklanan HTTP önbelleğe alma gereksinimlerini karşılıyorsa önbelleğe alınabilir.

Formlar için kullanıldığında güvenlikle ilgili konular için bkz. Bölüm 15.1.3.

9.5 SONRASI

POST yöntemi, kaynak sunucunun, istekte yer alan varlığı İstek Satırında İstek-URI'si tarafından tanımlanan kaynağın yeni bir alt öğesi olarak kabul etmesini istemek için kullanılır. POST, aşağıdaki işlevleri kapsayan tek tip bir yönteme izin verecek şekilde tasarlanmıştır:

  • Mevcut kaynaklara ek açıklama;

  • Bülten tahtasına, haber grubuna, posta listesine veya benzer bir makale grubuna mesaj gönderme;

  • Veri işleme sürecine bir form göndermenin sonucu gibi bir veri bloğunun sağlanması;

  • Veritabanını ekleme işlemi ile genişletme.

POST yöntemi tarafından gerçekleştirilen gerçek işlev sunucu tarafından belirlenir ve genellikle İstek URI'sına bağlıdır. Gönderilen varlık, bir dosyanın kendisini içeren bir dizine tabi olduğu şekilde bu URI'ye bağlıdır, bir haber makalesi gönderildiği bir haber grubuna veya bir kayıt bir veritabanına bağlıdır.

POST yöntemi tarafından gerçekleştirilen eylem, bir URI tarafından tanımlanabilecek bir kaynakla sonuçlanmayabilir. Bu durumda, yanıtın sonucu tanımlayan bir varlık içerip içermediğine bağlı olarak, 200 (Tamam) veya 204 (İçerik Yok) uygun yanıt durumudur.


2
"Yazı verilerini kullanan sayfalara yer işareti konamaz": bu bir avantaj, değil mi? Muhtemelen veri değiştiren sorgunuzun yer işaretinin alınmasını istemezsiniz.
Piskvor binadan

Sanırım her gönderi kullanıldığında, güvenlik odaklı bir amaç için kullanıyorduysanız, bu bir avantaj olurdu. Genellikle öyledir, ancak GET'te bu uzunluk sınırı vardır. Belki birileri güvenlikle ilgili olmayan bir ton veri geçiriyor ve sayfanın yer işareti koyulmasını istiyor? Kim bilir ...
Cimplicity

GET'in bir dezavantajı ile ilgili olarak, "Değişkenler URL'den ad-değer çiftleri olarak yapıştırılır", MVC yönlendirme ve sonuçta ortaya çıkan kolay URL'ler nedeniyle bu sorunu ortadan kaldırır mı?
MrBoJangles

@MrBoJangles: Güzel URL'lerin kullanılması, 'omzunun üstünden bakan kişi' söz konusu riskini engellemez. Yan not: MVC güzel URL'lerle yönlendirme gerektirmez ve güzel URL'lerle yönlendirme MVC gerektirmez; bazen birlikte kullanılırlar, ancak ayrı olarak da kullanılabilirler.
icktoofay

.NET dünyasında, tüm pratik amaçlar için, güzel url yeteneği = MVC. Bazı IIS yeniden yazma işlemleri veya bazı garip kod tabanlı olanları yapabileceğinizi düşünüyoruz, ancak daha az hoş. MVC, söylemeye gerek yok, galibiyet için.
MrBoJangles

28

İlk önemli şey, GET'in POST'a karşı anlamıdır :

  • GET için ... get kullanılmalıdır ... bazı bilgiler elde sunucusuna
  • POST bazı bilgileri göndermek için kullanılması gerekirken için sunucuya.


Bundan sonra, dikkat edilmesi gereken birkaç şey:

  • GET'i kullanarak kullanıcılarınız tarayıcılarındaki "geri" düğmesini kullanabilir ve sayfalara yer işareti koyabilir
  • GET olarak iletebileceğiniz parametrelerin boyutunda bir sınırlama vardır (yanılmıyorsam, Internet Explorer'ın bazı sürümleri için 2KB) ; sınır POST için çok daha fazladır ve genellikle sunucunun yapılandırmasına bağlıdır.


Her neyse, GET olmadan "yaşayabileceğimizi sanmıyorum: sorgu dizesindeki parametrelerle kaç URL kullandığınızı düşünün, her gün - GET olmadan, bunlar işe yaramaz ;-)


Herkes GET tarzında güzel URL'ler kullandıysa: http://example.com/var1/value1/var2/value2/var3/value3'teknik olarak' artık GET'iniz olamazdı ...
Tyler Carter

5
@ Chacha102 Bu kaynağı hala elde etmeniz gerekiyor. Neredeyse tüm sayfalar, resimler, komut dosyaları vb. GET kullanılarak web tarayıcılarına yüklenir.
Ryan

3
@ Chacha102 - Hatta www.mypage.com/contact/kullanımlar gibi bir şey için dahili olsunindex.php?url=/contact/
Thiago Belem

1
GET'in boyut sınırına vurgu! Ayrıca, GET parametreleri yer imlerine dahil edilirken POST dahil değildir. Ve kullanıcı GET tarafından istenen bir sayfayı yenileyebilir, ancak POST tarafından istenen bir sayfayı yenileyemez (bilgileri yeniden gönderme hakkında bir uyarı olmadan).
Ricket

12

Birçok web tarayıcısında uzunluk kısıtlaması farkının yanı sıra, anlamsal bir fark da vardır. GET'lerin sunucu durumunu değiştirmeyen salt okunur işlemler olmaları nedeniyle "güvenli" olmaları gerekir. POST'lar tipik olarak durumu değiştirir ve yeniden gönderimle ilgili uyarılar verir. Arama motorlarının web tarayıcıları GET yapabilir, ancak POST yapmamalıdır.

Durumu değiştirmeden verileri okumak istiyorsanız GET'i ve sunucudaki durumu güncellemek istiyorsanız POST'u kullanın.


+1. Bu, diğer her şeyin takip ettiği rfc'den temel kavramsal farktır. w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3
Frank Çiftçi

8

Genel kuralım sunucuya durumu değiştirmeyecek isteklerde bulunurken Get'i kullanmaktır. Yayınlar, durumu değiştiren sunucuya yapılan istekler için ayrılmıştır.


8

Pratik bir fark, tarayıcıların ve web sunucularının bir URL'de bulunabilecek karakter sayısı sınırlaması olmasıdır. Uygulamadan uygulamaya farklıdır, ancak varsa vurmak kesinlikle mümkündürtextarea formlarınızda .

GET'lerle başka bir gotcha - arama motorları ve diğer otomatik sistemler tarafından endekslenirler. Google bir keresinde, görüntülemekte olduğunuz sayfadaki bağlantıları önceden getirecek bir ürüne sahipti, bu nedenle bu bağlantıları tıklarsanız daha hızlı yüklenirler. İnsanların tüm sitelerini kaybettiği gibi bağlantıları olan sitelerde büyük tahribatlara neden oldu delete.php?id=1.


1
Web sunucunuzun muhtemelen bu konuda sınırları vardır.
Billy ONeal

POST için de bir sınır var.
chelmertz

1
Harika bir nokta, @BillyONeal, bunu ekledim. @Chelmertz Evet, ama istersem bunu değiştirebilirim ve çok daha yüksek. Örneğin, Apache örneklerine 1 gigabayt dosya gönderdim.
ceejayoz

Arama motorları tarafından dizine eklenen URL'leri anlıyorum. Bunun GET ile ne ilgisi olduğunu anlamıyorum. Yani bir URL sadece bir URL değil midir?
Bal

1
@Honey Arama motorları bağlantıları takip eder. Bağlantılar GET isteklerinde bulunur. Arama motorları form göndermez (eğer öyleyse, Google'ın sitenizde birkaç günde bir hesap açtığını görürsünüz) ve bu nedenle POST isteği yapmazsınız.
ceejayoz

7

URL'nin sayfanın durumunu yansıtmasını istediğinizde GET işlevini kullanın. Bu, burada görülenler gibi dinamik olarak oluşturulan sayfaları görüntülemek için kullanışlıdır. "Yanıtınızı Gönderin" düğmesini tıkladığımda olduğu gibi, veri göndermek için POST formunda kullanılmalıdır. Ayrıca, yoldan sonra bir parametre dizesi oluşturmadığından daha temiz bir URL üretir.


6

GET'ler yalnızca URL'ler olduğundan, web tarayıcısı tarafından önbelleğe alınabilir ve tutarlı bir şekilde oluşturulan resimler gibi şeyler için daha iyi kullanılabilir. (Bir Sona Erme süresi ayarlayın)

Gravatar sayfasından bir örnek: http://www.gravatar.com/avatar/4c3be63a4c2f539b013787725dfce802?d=monsterid

GET, marjinal olarak daha iyi performans gösterebilir, bazı web sunucuları işleyiciyi çağırmadan önce geçici bir dosyaya POST içeriği yazar.

Dikkate alınması gereken başka bir şey boyut sınırıdır. GET'ler URL'nin boyutuyla, standart olarak 1024 baytla sınırlıdır, ancak tarayıcılar daha fazlasını destekleyebilir.

Daha fazla veri aktarımı daha iyi tarayıcı uyumluluğu elde etmek için POST kullanmalıdır.

Bu sınırın altında bile bir sorun var, başka bir posterin yazdığı gibi, URL'deki herhangi bir şey geçmiş gibi tarayıcı arayüzünün diğer bölümlerinde ortaya çıkabilir.


4

Kendi başınıza yapamayacağınız bir şey yok. Nokta değiliz ki sözde bir HTTP GET sunucu durumunu değiştirmek için. HTTP proxy'leri, HTTP GET'in durumunu değiştirmediğinden, kullanıcının HTTP GET'i bir kez mi yoksa 1000 kez mi çağırdığını farketmediğini varsayar. Bu bilgileri kullanarak, ilk HTTP GET'in önbelleğe alınmış bir sürümünü döndürmenin güvenli olduğunu varsayarlar. HTTP spesifikasyonunu ihlal ederseniz, HTTP istemcisini ve vekil sunucuları kırma riskiniz vardır. Yapma :)


GET'in güvenli ve idempotent olmasına güvenen tarayıcılar değil: arama motoru örümcekleri ve önceden getirilmiş tarayıcılar (fastfox gibi) de buna güveniyor.
Frank Farmer

@gili, sonunda doğru cevabı olan biri. Kaç kişinin bunu yanlış yaptığına gerçekten şaşırdım. başparmak havaya!
lubos hasko

4

Bu, REST kavramına ve ağın nasıl kullanılmaya yönelik olduğuna bakmaktadır. Mükemmel bir podcast varYazılım Mühendisliği radyosunda Get ve Post kullanımı hakkında derinlemesine konuşma var.

Get, güncelleme işlemine gerek duyulmaması gereken verileri sunucudan almak için kullanılır. Buradaki fikir, aynı GET isteğini tekrar tekrar kullanabilmeniz ve aynı bilgileri iade edebilmenizdir. URL, sorgu dizesinde bilgi alma özelliğine sahiptir, çünkü diğer sistemlere ve kişilere kolayca bir şeyler bulabilecekleri bir adres gibi gönderilebilmesi amaçlanmıştır.

Postanın, sunucuya bilgi aktarmak / sunucuya bir eylem gerçekleştirmesini bildirmek için (en azından web'in temel aldığı REST mimarisi tarafından) kullanılması gerekiyordu. Örneğin: Bu verileri güncelleyin, Bu kaydı oluşturun.


"Yazılım Mühendisliği radyosunda Get ve Post kullanımı hakkında derinlemesine konuşma yapan mükemmel bir podcast var." Nerede?
yeeen

Bir bağlantı ekledim.
kemiller2002

İşte bu bağlantı: se-radio.net/2008/05/episode-98-stefan-tilkov-on-rest Yukarıdaki bağlantıyı da düzenledim, ancak düzenleme haklarına sahip değilim ve hakemliğim , vb.
MrBoJangles

Bir dosyayı giriş olarak kabul eden, dosya üzerinde bazı işlemler yapan (örnek - normal ifadeye dayalı verileri ayıkla) ve JSON verilerini döndüren bir uç noktam olduğunu varsayalım, o zaman sunucuya bir dosya yüklemek için GET isteğini kullanabilir miyim. Yoksa POST isteğini mi kullanmalıyım?
değişken

4

1.3 HTTP Seçimi için Hızlı Kontrol Listesi GETveyaPOST

Aşağıdaki durumlarda GET kullanın:

    The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).

Aşağıdaki durumlarda POST kullanın:

    The interaction is more like an order, or
    The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
    The user be held accountable for the results of the interaction.

Kaynak .


3

get olsa kullanarak bir sorun görmüyorum, ben sorgu dizesi şeyler tutmak mantıklı basit şeyler için kullanın.

Durumu güncellemek için kullanmak - delete.php?id=5bir sayfayı silmek gibi bir GET gibi - çok risklidir. İnsanlar, Google'ın web hızlandırıcısının sayfalardaki URL'leri önceden getirmeye başladığında tüm 'sil' bağlantılarına çarptığını ve insanların verilerini sildiğini öğrendi. Arama motoru örümceklerinde de aynı şey olabilir.



3

Gönderen RFC 2616 :

9.3 GET
GET yöntemi, İstek-URI'si tarafından tanımlanan herhangi bir bilgiyi (bir varlık şeklinde) almak anlamına gelir. İstek URI'sı bir veri üretme sürecine atıfta bulunursa, bu metin sürecin çıktısı olmazsa, sürecin kaynak metni olarak değil yanıtta varlık olarak döndürülecek olan üretilen verilerdir.


9.5 POST
POST yöntemi, kaynak sunucunun, istekte yer alan varlığı İstek Satırında İstek-URI'si tarafından tanımlanan kaynağın yeni bir alt öğesi olarak kabul etmesini istemek için kullanılır. POST, aşağıdaki işlevleri kapsayan tek tip bir yönteme izin verecek şekilde tasarlanmıştır:

  • Mevcut kaynaklara ek açıklama;
  • Bülten tahtasına, haber grubuna, posta listesine veya benzer bir makale grubuna mesaj gönderme;
  • Veri işleme sürecine bir form göndermenin sonucu gibi bir veri bloğunun sağlanması;
  • Veritabanını ekleme işlemi ile genişletme.

POST yöntemi tarafından gerçekleştirilen gerçek işlev sunucu tarafından belirlenir ve genellikle İstek URI'sına bağlıdır. Gönderilen varlık, bir dosyanın kendisini içeren bir dizine tabi olduğu şekilde bu URI'ye bağlıdır, bir haber makalesi gönderildiği bir haber grubuna veya bir kayıt bir veritabanına bağlıdır.

POST yöntemi tarafından gerçekleştirilen eylem, bir URI tarafından tanımlanabilecek bir kaynakla sonuçlanmayabilir. Bu durumda, yanıtın sonucu tanımlayan bir varlık içerip içermediğine bağlı olarak, 200 (Tamam) veya 204 (İçerik Yok) uygun yanıt durumudur.


2

İnsanların QueryString'i görmesini istemediğimde veya QueryString büyüdükçe POST kullanıyorum. Ayrıca, dosya yüklemeleri için POST gerekir.

GET'i kullanırken bir sorun görmüyorum, QueryString'de bir şeyler tutmanın mantıklı olduğu basit şeyler için kullanıyorum.

GET kullanılması, POST'un çalışmadığı yerlerde de mümkün olan belirli bir sayfaya bağlanmaya izin verir.


Neden dosya yüklemek için GET'i kullanamıyoruz?
değişken

1

Asıl amaç, GET'in verileri geri almak için kullanılması ve POST'un herhangi bir şey olmasıydı. Kullandığım temel kural, sunucuya bir şey gönderirsem POST kullanmamdır. Yalnızca verileri geri almak için bir URL çağırıyorsam GET kullanıyorum.


1

Wikipedia'da HTTP hakkındaki makaleyi okuyun . Protokolün ne olduğunu ve ne yaptığını açıklayacaktır:

ALMAK

Belirtilen kaynağın temsilini ister. GET'in, web uygulamalarında işlem yapmak için kullanma gibi yan etkilere neden olan işlemler için kullanılmaması gerektiğini unutmayın. Bunun bir nedeni GET'in robotlar veya tarayıcılar tarafından keyfi olarak kullanılabilmesidir, bu da bir talebin neden olması gereken yan etkileri dikkate alması gerekmez.

ve

POST İşlenecek verileri (örneğin, bir HTML formundan) tanımlanan kaynağa gönderir. Veriler isteğin gövdesine dahil edilir. Bu, yeni bir kaynak oluşturulmasına veya mevcut kaynakların veya her ikisinin güncellenmesine neden olabilir.

W3C'de URI'ler, Adreslenebilirlik ve ne zaman kullanılacağını açıklayan HTTP GET ve POST kullanımı adlı bir belge vardır . Anmak

1.3 HTTP GET veya POST Seçimi için Hızlı Kontrol Listesi

  • Aşağıdaki durumlarda GET kullanın:
    • Etkileşim daha çok bir soru gibidir (yani sorgu, okuma işlemi veya arama gibi güvenli bir işlemdir).

ve

  • Aşağıdaki durumlarda POST kullanın:
    • Etkileşim daha çok bir emir gibidir veya
    • Etkileşim, kaynağın durumunu kullanıcının algılayacağı şekilde değiştirir (örneğin, bir hizmete abonelik) veya o Kullanıcı, etkileşimin sonuçlarından sorumlu tutulur.

Bununla birlikte, HTTP GET veya POST kullanmaya ilişkin nihai karardan önce, lütfen hassas veriler ve pratik konular için de dikkate alın.

Bir HTML formu gönderdiğinizde pratik bir örnek verilebilir. Ya belirtmek yazı veya almak formu eylem için. PHP $ _GET ve $ _POST değerlerini buna göre dolduracaktır.


1

PHP'de POSTveri limiti genellikle php.ini. GETinandığım sunucu / tarayıcı ayarları ile sınırlıdır - genellikle 255bayt civarındadır.


1

Gönderen w3schools.com :

HTTP nedir?

Köprü Metni Aktarım Protokolü (HTTP), istemciler ve sunucular arasındaki iletişimi sağlamak üzere tasarlanmıştır.

HTTP, bir istemci ile sunucu arasında bir istek-yanıt protokolü olarak çalışır.

Bir web tarayıcısı istemci olabilir ve web sitesini barındıran bir bilgisayardaki bir uygulama sunucu olabilir.

Örnek: Bir istemci (tarayıcı) sunucuya bir HTTP isteği gönderir; sunucu istemciye bir yanıt döndürür. Yanıt, istekle ilgili durum bilgilerini içerir ve ayrıca istenen içeriği de içerebilir.

İki HTTP İstek Yöntemi: GET ve POST

Bir istemci ve sunucu arasında bir istek yanıtı için yaygın olarak kullanılan iki yöntem şunlardır: GET ve POST.

GET - Belirtilen bir kaynaktan veri ister POST - Belirtilen bir kaynağa işlenecek verileri gönderir

Burada büyük farkları ayırt ediyoruz:

resim açıklamasını buraya girin


1
Arama yapanların ve okuyucuların görüntünün içeriğini cevaba girmeleri çok daha iyi olur. Ayrıca, cevabın ilk kısmı soruyu cevaplamada gerçekten yardımcı olmuyor.
Dave Schweisguth

Kopyayı buradan kopyalayın - kaynağınızı doğru bir şekilde belirtmeniz ve kaynak lisansının yeniden kullanılmasına izin vermesi gerekir, ki bu da w3schools'un yapmadığını düşünmüyor. Bunun dışında, bunun diğer 25 cevapta ele alınmayan bir şey eklediğini düşünüyor musunuz?
Benjamin

1

POST GET PUT DELETE'in basit sürümü

  • GET kullanın - herhangi bir Kimliğe veya İsme dayalı veri listesi gibi herhangi bir kaynak almak istediğinizde
  • sunucuya herhangi bir veri göndermek istediğinizde POST'u kullanın. unutmayın POST ağır bir işlemdir çünkü güncelleme için POST yerine PUT kullanmalıyız POST yeni kaynak yaratacaktır
  • PUT kullanın -

4
"PUT kullan - ne zaman sen" Cümlenin geri kalanı nerede?
Pang

Birisi bu cevabın ilk iki mermisini o kadar çok sevmiş ki, son mermiyi sansını iptal ettiler haha: '-)
pooley1994

0

Önemli olan şey, gönderdiğiniz her şeyin GETURL yoluyla gösterilmesidir. İkinci olarak, Ceejayoz'un dediği gibi, bir URL için karakterlerde bir sınır vardır.


0

Diğer bir fark ise POST genellikle iki HTTP işlemi gerektirirken GET yalnızca bir tane gerektirir.

Düzenleme: Açıklığa kavuşturmak gerekir - ortak programlama kalıpları için. Genellikle bir POST'a düz bir HTML web sayfasıyla yanıt vermek, çeşitli nedenlerden dolayı şüpheli bir tasarımdır, bunlardan biri can sıkıcı "bu formu yeniden göndermeniz gerekir, bunu yapmak ister misiniz?" düğmesine basın.


2
POST, 2 http işlemi gerektirmez.
Billy ONeal

3
yönlendirme sonrası için 2 işlem gerekir: en.wikipedia.org/wiki/Post/Redirect/Get
cherouvim

1
POST, sunucuya 2 gidiş dönüş gerektirebilir - ortak bir desen, bir expect: 100-continuebaşlıkla POST yapmaktır ve yalnızca sunucu bir ile yanıt verdiğinde veri gönderir 100 CONTINUE.
Frank Farmer

Güzel makale cherouvim, desenin bir ismi olduğunu hiç bilmiyordum.
Plynx

@cherouvim: Gönderi yönlendirmesi alır, ancak düz gönderi olmaz. Aynı sonuçları alarak yönlendirme elde edebilirsiniz. Formunuzun gönderilmesi için kullandığı protokolle ilgisi yoktur.
Billy ONeal

0

Başkaları tarafından yanıtlandığı gibi, get ile url boyutunda bir sınır vardır ve dosyalar yalnızca posta ile gönderilebilir.

Ben onu eklemek istiyorum olabilir Bir yayınla eylemleri bir get bir veritabanına şeyler ekleyip gerçekleştirin. Bir komut dosyası bir gönderi veya alma aldığında, yazarın yapmasını istediği her şeyi yapabilir. Anlayış eksikliğinin, kitabın seçtiği ifadelerden veya onu nasıl okuduğunuzdan kaynaklandığına inanıyorum.

Bir komut dosyası yazar gerektiği veritabanını değiştirmek ve sadece bilginin geri alınması için olsun kullanmak yayınlarını kullanabilir.

Komut dosyası yazma dilleri, isteğe erişmek için birçok yöntem sağladı. Örneğin, PHP $_REQUESTbir gönderi veya get almak için kullanılmasına izin verir . Kişi bundan daha spesifik $_GETveya lehine kaçınmalıdır $_POST.

Web programlamasında yorum için çok daha fazla alan vardır. Orada neler biri gerektiği ve hangi biri olabilir , ama hangisi daha iyi sık sık tartışmaya açık olduğunu. Neyse ki, bu durumda, belirsizlik yoktur. Sen gerektiğini verileri değiştirmek için mesajları kullanın ve gereken bilgileri almak için olsun kullanın.


0

Gorgapor, mod_rewritehala sıklıkla kullanır GET. Sadece daha dostça bir URL'yi GETsorgu dizesi içeren bir URL'ye çevirmeye izin verir .


-1

HTTP Post verilerinin, farklı tarayıcıların GET'ler için farklı sınırları olduğu için veri miktarı üzerinde belirli bir sınırı yoktur. RFC 2068 şunları belirtmektedir:

Bazı eski istemci veya proxy uygulamaları bu uzunlukları doğru şekilde desteklemeyebileceğinden, sunucular 255 baytın üzerindeki URI uzunluklarına bağlı olma konusunda dikkatli olmalıdır.

Özellikle, ne için kullanıldıkları için doğru HTTP yapılarını kullanmalısınız. HTTP GET'lerin yan etkileri olmamalı ve HTTP Proxy'leri vb. Tarafından güvenle yenilenebilir ve saklanabilir.

Bir URL kaynağına veri göndermek istediğinizde HTTP POST'ları kullanılır.

HTTP GET kullanımı için tipik bir örnek Arama'dadır, yani Arama? Sorgu = benim + sorgu HTTP POST kullanımı için tipik bir örnek, çevrimiçi bir forma geri bildirim göndermektir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.