HTTP protokolünde GET ve POST gibi yöntemlere ne gerek var?


17

HTTP protokolünü yalnızca bir istek gövdesi ve bir yanıt gövdesi kullanarak uygulayamıyor muyuz?

Örneğin URL, sunucu tarafında programlama diline bağlı olarak bir işlevle eşleştirilecek bir istek içerecektir, buna göre bir Servlet ve yanıt olarak HTML ve JavaScript yanıtı gönderilecektir.

HTTP protokolünde neden yöntem kavramı var?

Cevaplardan, yöntem kavramının neden orada olduğunu biraz anladım ... Bu, ilgili başka bir soruya yol açar:

Örneğin gmail oluşturma bağlantısında PUT / POST isteği ve verileri gönderilir. Tarayıcı hangi yöntemi kullanacağını nasıl öğrenir? Sunucu tarafından gönderilen gmail sayfası, gmail oluşturma isteği çağrılırken kullanılacak yöntem adını içeriyor mu? www.gmail.com dediğimizde, GET yöntemini kullanıyor olmalı, tarayıcı bu yöntemin kullanılacağını nasıl biliyor?

Not : Cevaplar hakkında yorum yapmak için yeterli kredim yok, bu yüzden bu sorunun arkasındaki niyetle ilgili insanların dile getirdiği birçok soru hakkında yorum yapamıyorum.

Bazı cevapların söylediği gibi, DELETE yönteminde yeni kullanıcılar oluşturabiliriz, daha sonra bu, http protokolündeki yöntem kavramının arkasındaki niyeti sorgular, çünkü günün sonunda, tamamen bir URL'yi eşlemek istedikleri işlev sunuculara bağlıdır . İstemci neden sunuculara bir URL için kullanılacak yöntemleri söylemelidir.


Evet ve hayır. HTTP kullanmadan HTTP isteklerini nasıl yapacağınızı bilmek istediğinizi söylediğinizde sorunuz kendisiyle çakışıyor, ancak yapmaya çalıştığınız şeyi aldım. Yani, bir tarayıcı kullanmadan ancak programlı bir şekilde yapmadan verileri alın ve POST yapın. Bu doğru mu?
Rob

4
Acaba, HTTP'nin metodlar olmadan tanımlanıp tanımlanamayacağını mı soruyorsunuz, yani onlar için tarihsel mantık; veya şu anda olduğu gibi protokol onlar olmadan kullanılabilir, yani bırakma yöntemleri mevcut şartname içinde olurdu?
ilkkachu

@ilkkachu: İstemcinin neden sunucuya bir şeyin nasıl yürütüleceğini anlatması gerekiyor. İstemci yalnızca bir URL ve URL kullanarak istekte bulunur, örneğin sunucu bunu sunucu uygulaması diyelim bir işlevle eşleyebilir ve yanıtı geri verebilir. Neden müşteri bir şeyin nasıl yürütüleceğini sağlamalıdır?
user104656

1
@ user104656, Bu sorumun cevabı ise, orijinal tasarım mı yoksa mevcut durum mu demek istediğinizden emin değilim. (İhtiyaç duymadığını veya gerekmediğini söylemedim.)
ilkkachu

@Mars ve Diğerleri: Örneğin gmail oluşturma bağlantısında PUT / POST isteği ve verileri gönderilir. Tarayıcı hangi yöntemi kullanacağını nasıl öğrenir? Sunucu tarafından gönderilen gmail sayfası, gmail oluşturma isteği çağrılırken kullanılacak yöntem adını içeriyor mu? www.gmail.com dediğimizde, GET yöntemini kullanıyor olmalı, tarayıcı bu yöntemin kullanılacağını nasıl biliyor?
BioLogic

Yanıtlar:


33

Bu cevabın ilk yazıldığı için sorunun değiştiğini / açıklandığını lütfen unutmayın . Sorunun en son yinelemesine bir başka yanıt, ikinci yatay kuraldan sonradır

HTTP protokolünde GET ve POST gibi yöntemlere ne gerek var?

Başlık biçimleri, başlıkların ve gövdelerin nasıl ayrıldığına ilişkin kurallar gibi birkaç başka şeyle birlikte HTTP protokolünün temelini oluştururlar

HTTP protokolünü yalnızca bir istek gövdesi ve bir yanıt gövdesi kullanarak uygulayamıyor muyuz?

Hayır, çünkü o zaman oluşturduğunuz her şey HTTP protokolü olmaz

Örneğin URL, sunucu tarafında programlama diline bağlı olarak bir işlevle eşleştirilecek bir istek içerecektir, buna göre bir Servlet ve yanıt olarak HTML ve JavaScript yanıtı gönderilecektir.

Tebrikler, yeni bir protokol icat ettiniz! Şimdi, sürmek ve bakımını yapmak, geliştirmek vb. İçin bir standart gövde oluşturmak istiyorsanız, bir gün HTTP'yi geçebilir

Bunun yanakta biraz dil olduğunu takdir ediyorum, ancak internet, TCP / IP veya sunucular ve istemciler arasında devam eden iletişim hakkında büyülü bir şey yok. Bir bağlantı açar ve telden aşağıya bazı kelimeler göndererek bir konuşma oluşturursunuz. Eğer talepler anlaşılacaksa ve makul yanıtlar verilecekse, görüşmenin her iki uçta bazı onaylanmış spesifikasyonlara uyması gerekir. Bu, dünyadaki herhangi bir diyalogdan farklı değildir. İngilizce konuşuyorsunuz, komşunuz Çince konuşuyor. Umarım elinizi sallayarak, işaret eden ve yumruk sallayarak, arabasını evinizin önünde park etmesini istemediğiniz mesajınızı iletmek için yeterli olacaktır.

Tekrar internette, HTTP uyumlu bir web sunucusuna soket açarsanız ve aşağıdakileri gönderirseniz:

EHLO
AUTH LOGIN

(SMTP e-posta iletiminin başlangıcı) o zaman mantıklı bir cevap alamazsınız. En mükemmel SMTP uyumlu istemciyi oluşturabilirsiniz, ancak web sunucunuz onunla konuşmayacaktır, çünkü bu konuşma tamamen paylaşılan protokolle ilgilidir - paylaşılan protokol yok, neşe yok.

Bu nedenle HTTP protokolünü uygulamadan HTTP protokolünü uygulayamazsınız; yazdıklarınız protokole uymuyorsa, sadece protokol değildir - başka bir şeydir ve protokolde belirtildiği gibi çalışmaz

Örneğinizle bir an için çalışırsak; burada istemci bağlanır ve sadece bir URL gibi görünen bir şey belirtir .. Ve sunucu onu anlar ve sadece HTML / JS (bir web sayfası) gibi görünen bir şey gönderir, o zaman işe yarayabilir. Yine de ne kurtardın? GET dememek için iki bayt var mı? Bu sinir bozucu başlıklardan kurtulmak için biraz daha .. Sunucu da biraz kaydetti - ama size ne gönderdiğini çözemezseniz? JPEG ile biten bir URL istediyseniz ve size resim oluşturan bazı baytlar gönderdiyse, ancak PNG'de mi? Bu konuda eksik bir PNG. Keşke biz kaç bayt söyledi kafayla vardı gidiyorgöndermek için, aldığımız bayt sayısının gerçekte tüm dosya olup olmadığını biliriz. Sunucu, bant genişliğinden tasarruf etmek için yanıtı sıkıştırdı, ancak size söylemediyse ne olurdu? Gönderdiği şeyi çözmeye çalışmak için hatırı sayılır bir hesaplama gücü harcayacaksınız.

Günün sonunda, metainformasyona ihtiyacımız var - bilgi hakkında bilgi; başlıklara ihtiyacımız var; isimlere, uzantılara, oluşturulan tarihlere sahip dosyalara ihtiyacımız var. İnsanların doğum günlerine ihtiyacı vardır, lütfen ve teşekkür ederim vb. - Dünya, bağlam hakkında protokol ve bilgi parçalarıyla doludur, bu yüzden her zaman her şeyi sıfırdan oturmak zorunda kalmazız. Biraz depolama alanına mal olur, ancak kolayca buna değer


Çeşitli HTTP yöntemlerinin uygulanması gerçekten gerekli mi?

Muhtemelen, belirtilen protokolün tamamını uygulamak zorunda değildir ve bu genellikle her şey için geçerlidir. İngilizce dilindeki her kelimeyi bilmiyorum; Çinli komşum da bir yazılım geliştiricisi ama farklı bir endüstride ve İngilizceyi bırakmadan endüstrimde kullanılan bazı terimler için Çince bile bilmiyor. İyi olan şey, ikisinin de HTTP uygulamasıyla ilgili bir belge alabiliriz, sunucuyu yazabilir ve istemciyi farklı mimarilerde farklı programlama dillerinde yazabilirim ve protokole bağlı oldukları için hala çalışırlar.

Kullanıcılarınızın hiçbirinin bir GET isteği dışında hiçbir şey yayınlamaması, kalıcı bağlantılar kullanmaması, gövde olarak JSON dışında bir şey göndermemesi veya metin / düz dışında herhangi bir şeyi kabul etmesi gerekmeyebilir. sadece istemci tarayıcısının çok sınırlı taleplerini karşılayan gerçekten ayrıştırılmış bir web sunucusu yazın. Ancak, keyfi olarak HTTP'nin "bir soketten geçen bazı metinleri" yapan temel kuralları ortadan kaldırmaya karar veremezdiniz; isteğin aşağıdaki gibi bir dize olacağı temel fikrinden vazgeçemezsiniz:

VERB URL VERSION
header: value

maybe_body

Ve yanıtın bir sürümü, durum kodu ve belki üstbilgileri olacaktır. Bunlardan herhangi birini değiştirirseniz - artık HTTP değil - başka bir şeydir ve yalnızca onu anlamak için tasarlanmış bir şeyle çalışır. HTTP, bu tanımlara göre ne olduğundan, onu uygulamak istiyorsanız, tanımları takip etmeniz gerekir


Güncelleme

Sorunuz biraz gelişti, işte sorduğunuz sorulara yanıt:

HTTP protokolünde neden yöntem kavramı var?

Tarihsel olarak, komut dosyalarının mevcut olmadığı ve hatta sayfaların dinamik olabileceği, bellekte oluşturulduğu ve bunun yerine soketin aşağı itildiği düşüncesinde bile, tasarım ve uygulamalarında çok daha esnek olmayan şeyleri takdir etmelisiniz. diskte istemci tarafından istenen ve soketi okuyup aşağı iten statik bir dosya olma durumu yoktu. Web'in diğer sayfalara bağlantılar içeren statik sayfalar kavramının etrafında toplandığı gibi, disk ve navigasyondaki tüm sayfalar çoğunlukla URL'lerdeki sayfalar için GET istekleri yapan terminal tarafından olurdu, sunucu eşleştirebilirdi url'yi diskteki bir dosyaya gönderin ve gönderin. Birbirleriyle bağlantılı olan ve başka bir yere giden belge ağının gelişen olması gerektiği düşüncesi de vardı,

Bu, yöntemler için bazı tarihsel bağlamlar verir - bir zamanlar URL esnek olmayan bitti ve basitçe diskteki sayfalara atıfta bulundu, bu nedenle yöntem yararlıydı çünkü istemcinin dosya ve sunucu için ne niyetini tanımlamasına izin verdi. yöntemi değişken bir şekilde işleyin. Gerçekte bir hipermetnin (ve yalnızca Metin'di) bir web sitesinin orijinal vizyonunda anahtarlama veya eşleme için kullanılan URL'lerin gerçekte olduğu fikri yoktu.

Bu cevabın, tarihlerin ve tam olarak bir şeyler değişmeye başladığında atıfta bulunulan referansları içeren tarihsel kaydın bir dokümanı olmasını istemiyorum - bunun için muhtemelen Wikipedia'yı okuyabilirsiniz - ancak zamanla daha fazla momentum elde etmek ve sunucu-istemci bağlantısının her iki ucunda zengin bir multimedya deneyimi yaratma fırsatını genişletiyoruz. Tarayıcılar, içeriği biçimlendirmek için büyük bir etiket çoğalmasını destekledi, her biri uygulamak için gereken medya zenginliği özellikleri ve şeylerin şık görünmesini sağlamanın yeni yolları.

Komut dosyası oluşturma, istemci tarayıcısına ve eklentilere ve tarayıcı uzantılarına ulaştı ve hepsi tarayıcıyı her şeyin büyük ölçüde yetenekli bir güç merkezine dönüştürmeyi amaçladı. Sunucu sonunda algoritmalara veya veritabanı verilerine dayanan aktif içerik üretimi büyük bir itişti ve muhtemelen diskte daha az dosya olduğu ölçüde gelişmeye devam ediyor - elbette, bir resim veya komut dosyasını bir dosya olarak tutuyoruz web sunucusuna sahip olun ve tarayıcıyı edinin, ancak giderek artan şekilde tarayıcının gösterdiği resimler ve çalıştırdığı komut dosyaları dosya gezginde açabileceğiniz dosyalar değil, isteğe bağlı olarak yapılan bazı derleme işlemlerinin çıktısı olan içerik üretiliyor , Bitmap piksel dizisi yerine piksellerin nasıl çizileceğini açıklayan SVG veya TypeScript gibi daha üst düzey bir komut dosyasından yayılan JavaScript

Modern çok megabaytlık sayfalar oluştururken, muhtemelen bunun sadece bir kısmı artık bir diskteki içeriktir; veritabanı verileri, tarayıcının tüketeceği html olarak biçimlendirilir ve biçimlendirilir ve sunucu tarafından, URL tarafından bir şekilde referans verilen birden fazla farklı programlama rutine yanıt olarak yapılır.

Sorunun yorumlarında biraz daire gibi olduğunu söyledim. Bilgisayarlar yüz binlerce ve dolu odalara mal olduğunda, birden fazla kullanıcının yüzlerce aptal terminal aracılığıyla bir süper güçlü merkezi ana çerçeveyi kullanmasına izin vermek yaygındı - bir klavye ve fare, yeşil bir ekran, bazı metinler göndermek, bazılarını almak dışarı metin. Bilgi işlem gücü arttıkça ve fiyatlar düştükçe, insanlar erken ana bilgisayarlardan daha güçlü masa bilgisayarları ve güçlü uygulamaları yerel olarak çalıştırma yeteneği ile sona erdi ve böylece ana bilgisayar modeli modası geçmiş oldu. Yine de hiç gitmedi, çünkü işler diğer yöne kaydırmak için evrildi ve kullanışlı uygulama işlevselliğinin çoğunu ve ekranda çizmek dışında çok az şey yapan yüz istemci bilgisayarı sağlayan merkezi bir sunucuya geri döndü, ve sunucuya / sunucudan veri gönderip alabilirsiniz. Bilgisayarınızın kendi kelime ve görünüm kopyasını aynı anda çalıştıracak kadar akıllı olduğu bu ara dönem, tarayıcınızın ekranda resim çizmek ve belge / e-postayı düzenlemek için bir cihaz olduğu çevrimiçi ofise tekrar yol verdi. sunucuda yaşayan bir şey olarak yazmak, orada saklanır, tarayıcının sadece başka bir yerde yaşayan bu şeyin herhangi bir zamanında kısmi bir görünüm sağlayan bir kabuk olduğu düşüncesi olarak gönderilir ve diğer kullanıcılarla paylaşılır.

Cevaplardan, yöntem kavramının neden orada olduğunu biraz anladım ... Bu, ilgili başka bir soruya yol açar:

Örneğin gmail oluşturma bağlantısında PUT / POST isteği ve verileri gönderilir. Tarayıcı hangi yöntemi kullanacağını nasıl öğrenir?

Bir URL yazdığınızda ve geri dönüş yaptığınızda varsayılan olarak GET kullanır, çünkü kural / spec

Sunucu tarafından gönderilen gmail sayfası, gmail oluşturma isteği çağrılırken kullanılacak yöntem adını içeriyor mu?

Bu, yukarıdaki yorumlarda bahsettiğim en önemli şeylerden biri. Modern web'de artık sayfalarla ilgili değil. Sayfalar diskteki dosyalar olduğunda, tarayıcı GET olacaktır. Daha sonra, verileri bir şablona yerleştirerek ağırlıklı olarak dinamik olarak oluşturulan sayfalar oldular. Ancak yine de "sunucudan yeni bir sayfa talep et, bir sayfa al, sayfayı göster" işlemini içeriyordu. Sayfa değiştirme gerçekten kayganlaştı; yüklediklerini ve yeniden boyutlandırdıklarını ve düzenlerini sarsmadıklarını görmediniz, böylece daha pürüzsüz bir hal aldı, ancak yine de bir sayfanın tamamını veya sayfanın bir kısmını başka bir sayfayla değiştiren tarayıcıydı

İşleri yapmanın modern yolu tek sayfalık bir uygulama ile; tarayıcının bellekte belirli bir şekilde görüntülenen bir belgeye sahip olması, thebservr çağrılarını komut dosyası haline getirmesi ve bir miktar nugget geri alması ve belgeyi, sayfanın bir kısmının yeni bilgileri göstermek için görsel olarak değişeceği şekilde değiştirir. tarayıcı yeni bir sayfa daha yüklüyor; sadece bir bölümünün kelime veya görünüm gibi tipik bir istemci uygulaması gibi güncellendiği bir kullanıcı arayüzü haline gelir. Yeni öğeler diğer öğelerin üstünde görünür ve iletişim pencerelerini simüle etmek için sürüklenebilir. Tüm bunlar Tarayıcı komut dosyası altyapısı, geliştiricinin istediği http yöntemini kullanarak istek gönderir, verileri geri alır ve tarayıcının çizdiği belgeye atar. Modern tarayıcının, tüm işletim sistemi veya sanal bilgisayar gibi parlak bir cihaz olduğunu düşünebilirsiniz; Ekranda bir şeyler çizme, ses çalma, kullanıcı girişini yakalama ve işleme için gönderen oldukça standartlaştırılmış bir yolu olan programlanabilir bir cihaz. UI'nizi çizmek için yapmanız gereken tek şey, bir UI yapan bazı html / css sağlamak ve ardından tarayıcının çizimini değiştirmek için sürekli olarak html'yi ayarlamaktır. Heck, insanlar adres çubuğunun değişimini görmek / bunu bir niyet yönü olarak kullanmak için çok kullanıldı, hiçbir gezinme (tüm yeni sayfaları talep eden) yapılmasa bile tek bir sayfa uygulaması url'yi programlı olarak değiştirecek UI'nizi çizmek için yapmanız gereken tek şey, bir UI yapan bazı html / css sağlamak ve ardından tarayıcının çizimini değiştirmek için sürekli olarak html'yi ayarlamaktır. Heck, insanlar adres çubuğunun değişimini görmek / bunu bir niyet yönü olarak kullanmak için çok kullanıldı, hiçbir gezinme (tüm yeni sayfaları talep eden) yapılmasa bile tek bir sayfa uygulaması url'yi programlı olarak değiştirecek UI'nizi çizmek için yapmanız gereken tek şey, bir UI yapan bazı html / css sağlamak ve ardından tarayıcının çizimini değiştirmek için sürekli olarak html'yi ayarlamaktır. Heck, insanlar adres çubuğunun değişimini görmek / bunu bir niyet yönü olarak kullanmak için çok kullanıldı, hiçbir gezinme (tüm yeni sayfaları talep eden) yapılmasa bile tek bir sayfa uygulaması url'yi programlı olarak değiştirecek

www.gmail.com dediğimizde, GET yöntemini kullanıyor olmalı, tarayıcı bu yöntemin kullanılacağını nasıl biliyor?

Doğru. Çünkü belirtilmiş. İlk istek, tarihsel olarak her zaman olduğu gibi - bir UI çizmek için bazı başlangıç ​​html'lerini ALIN, sonra sonsuza kadar dürtün ve manipüle edin ya da duyarlı bir reaktif UI dürten ve manipüle eden ve yapan diğer komut dosyasıyla başka bir sayfa alın.

Bazı cevapların söylediği gibi, DELETE yönteminde yeni kullanıcılar oluşturabiliriz, daha sonra bu, http protokolündeki yöntem kavramının arkasındaki niyeti sorgular, çünkü günün sonunda, tamamen bir URL'yi eşlemek istedikleri işlev sunuculara bağlıdır . İstemci neden sunuculara bir URL için kullanılacak yöntemleri söylemelidir.

Tarih. Legacy. Teorik olarak tüm http yöntemlerini yarın dışarı atabiliriz; URL'lerin, verileri kaydetmek istediğiniz sunucuya işaret eden anahtarlama mekanizması olabileceği ölçüde işlenebildiği için yöntemlerin eski olduğu bir programlama karmaşıklığı düzeyindeyiz. gövde taslak e-posta olarak veya taslak silme - sunucuda / e-postalar / taslak / kaydet / 1234 dosyası yok - sunucu bu url'yi ayırmaya ve gövde veri kaydetme ile ne yapacağını bilmeye programlandı 1234 kimliği altında taslak e-posta olarak

Bu nedenle, çevrelerinde büyüyen eski uyumluluk ağırlığı hariç, yöntemlerle ortadan kaldırmak kesinlikle mümkündür. Onları sadece ihtiyacınız olan şey için kullanmak, ancak büyük ölçüde görmezden gelmek ve bunun yerine işinizi yapmak için ihtiyacınız olan her şeyi kullanmak daha iyidir. Hala belirtildiği gibi yöntemlere ihtiyacımız var, çünkü bunların tarayıcı ve sunucuya, uygulamalarımızı oluşturduğumuz sunucu için bir şey ifade ettiğini hatırlamanız gerekiyor. İstemci tarafı komut dosyası veri göndermek için temel tarayıcıyı kullanmak istiyor, tarayıcının istediği gibi yapmasını sağlayacak bir yöntem kullanması gerekiyor - muhtemelen bir POST, çünkü GET tüm değişken bilgilerini url'ye paketliyor ve uzunluk sınırı var birçok sunucuda. İstemci sunucudan uzun bir yanıt istiyor - HEAD kullanmayın, çünkü yanıt organları olması gerekmez.


1
"Yazdığınız şey protokole uymuyorsa, o zaman sadece protokol değildir" den bir oyuncu aldım. "Bu ilginç bir oyun, ama bu kurallar olmadan" satranç "değil dedim. Oyunun kurallarını değiştirin ve artık aynı oyun değil.
Monty Harder

4
Yöntemler veya üstbilgiler olmadan mevcut HTTP'nin nasıl olmayacağı hakkında daireler yazdınız (soru üstbilgilerle ilgili hiçbir şey söylemese de), ancak yöntemlerin ne için olduğunu ve bir protokolün yöntemsiz aynı amaçlar için çalışıp çalışmayacağını asla söylemezsiniz - sorunun konusu neydi?
aaa

1
Neden yöntemlerin "ne için" olduğunu söylemem gerekiyor? Bunun için özel bir belge var. HTTP sihirli bir şey değil, FTP veya SMTP veya RTMP de değil - hepsi sadece bir sokete inen baytlar, ancak baytların protokole uygun olmasını sağlayan sıra, sunum, kurallar (protokol). dır-dir. Soruda bir şey okumadım, ama sorunuzu cevaplamaktan da sakıncası yok: biri yöntemsiz bir protokol yapabilir mi? - gerçekten değil, ama yöntemlerle ne demek istediğinize bağlı. HTTP, HTTP yöntemlerine sahip tek protokoldür, ancak düşünebildiğim tüm protokoller ..
Caius Jard

..bir yöntem olarak anlatacağım etkileşim kalıpları; onlar olmadan bir protokol olmazlar ve güvenilir süreçler arası / sistemler arası iletişimi sağlayamazlardı.
Caius Jard

Aslında, yöntemlerin "ne" olduğunu söylemek için özel bir belge olduğunu söyledim - bu mutlaka doğru değildir; yöntemlerin hiçbir şey için "olması" gerekmez; bir GET'e yanıt olarak şeyleri silen ve bir DELETE'e yanıt olarak yeni kullanıcılar oluşturan bir web hizmeti oluşturabiliriz. Bir yöntemin zorunlu davranışı yoktur, yalnızca belirtildikleri için vardır. Sistemler protokollerin üzerine inşa edilmiştir, çünkü bazı zor işleri alır (bir protokolü ve bunu kullanan bir sistemi icat etmemiz gerekmez), ancak her iki tarafı da kontrol ettiğimizde, protokolün hangi yönleri kullanılır ( için) oldukça keyfi
Caius Jard

12

HTTP, Uzaktan Yordam Çağrısı'nın genel ilkelerinin belirli bir örneği olarak düşünülebilir: sunucuya istekte bazı değişken alanlarla ne istediğinizi söylersiniz, sunucu buna göre yanıt verir. Şimdiye kadar, 'Web 2.0'ın karmaşık etkileşimi nedeniyle, aynı özellikler istek üzerine her alanda itilmektedir: URL, başlıklar, gövde - ve her bir uygulama sunucusu ve uygulama bunları kendi yollarıyla anlar. Bununla birlikte, başlangıçta web daha basitti, statik sayfalar kullandı ve HTTP yöntemlerinin yeterli etkileşim düzeyi için sağlandığı düşünülüyordu. Özellikle, HTTP nadiren kullanılan pek çok yönteme sahiptir, hiç değilse, bazıları REST sayesinde sadece ışığı görür. Örneğin PUT ve DELETE, REST'ten önce can çekiyordu ve TRACE ve PATCH hala görülemeyen afaik. Paket, HTTP'nin RPC modelinin

REST, PUT ve DELETE geri getirilirse, HTTP yöntemlerinin çoğu uygulamanın tipik CRUD kullanım örneklerine hizmet ettiğini belirterek, teklif ettiğiniz şeyin tam tersini yaptı.

Ayrıca HTTP yöntemlerinin kendilerine atanan ve proxy sunucuları gibi ara katman yazılımları tarafından onanan semantiklere sahip olduğunu unutmayın: POST, PUT, DELETE ve PATCH istekleri yan etkilere sahip olabilir ve muhtemelen idempotent olmayabilir, bu nedenle istemci tarafı uygulamaları ve ara katman yazılımı dikkatli olur bu istekleri kullanıcıdan açık bir işlem yapmadan başlatmamak. Uygulamada, kötü tasarlanmış web uygulamaları güvenli olmayan işlemler için GET'i kullandı ve örneğin Google Web Accelerator önceden getirici , bu tür sitelerdeki bir sürü veriyi silerek sorun yarattı , bu nedenle beta sürümü lansmandan hemen sonra askıya alındı.

Bu yüzden, 'yapabilir miyiz' sorusunu cevaplamak için: elbette, sunucu uygulamasına hangi eylemi gerçekleştirmek istediğinizi söyleyecek bir protokol üzerinde anlaşmanız gerekir ve ardından argümanları URL / gövdede bir yere koyabilirsiniz. eylem için hedef öğe. Eylem kümesi yalnızca belirli uygulamalarla sınırlıdır, bu nedenle genişletilebilir bir protokole ihtiyacınız vardır. Ancak, istemci uygulamalarına hangi isteklerin güvenli olduğunu bildirmeniz ve muhtemelen önbellek kontrolü gibi diğer nüansları dikkate almanız gerekir.


4
"PUT ve DELETE, REST'ten önce can çekiyordu" Doğru değil. Sizce WebDAV nasıl çalıştı?
Patrick Mevzek

3
@PatrickMevzek Evet ama WebDav, koma yerine canlı olarak düşünmek için yeterli kişi tarafından kullanıldı mı? ^^
Frank Hopkins

1
@PatrickMevzek WebDAV pratik olarak HTTP'den ayrı bir protokoldür.
duskwuff

@duskwuff tools.ietf.org/html/rfc4918 "Web Dağıtılmış Yazma ve Sürüm Oluşturma için HTTP Uzantıları (WebDAV)". O kadar ayrı değil, açıkça üstündedir.
Patrick Mevzek

1
PATCH, REST tarafından kısmi bir değişikliği belirtmek için kullanılır (diğer adıyla güncelleme).
jmoreno

7

Bir geliştirici olarak kişisel bakış açımdan, API uç noktaları oluşturmayı çok daha kolay hale getirebilir. Örneğin, bir web sitesinde ürünleri yöneten bir denetleyici yazarsam, birden çok farklı işlem yapmak için aynı URL'yi kullanabilirim.

Örnekler:

GET https://example.com/api/products/1234

Bu, 1234 ürününün ayrıntılarını getirecektir.


POST https://example.com/api/products/1234

Bu, istek gövdesindeki verileri kullanarak 1234 numaralı bir ürün oluşturur.


PUT https://example.com/api/products/1234

Bu, 1234 ürününü talep gövdesindeki verilerle güncelleyecektir.


DELETE https://example.com/api/products/1234

Bu, 1234 numaralı bir ürünü silecektir.


Her işlem için farklı son noktalar yapabilirim, ancak bu işlemi karmaşıklaştıracak ve diğer geliştiriciler için daha az anlaşılabilir hale getirecektir.


1
Bu, kesin soruyu diğerleri kadar tam olarak (veya belki de değil) cevaplamaz, ancak bireysel yöntemlerin sürekli kullanımı için modern bir gerekliliktir. +1
TCooper

6

HTTP protokolünde GET ve POST gibi yöntemlere ne gerek var?

Görünüşe göre HTTP sunucularının sadece dosya sunmak için orada olduğu eski günleri unuttun ; komut dosyası, CGI çalıştırmamak veya bu tür bir dinamik içerik oluşturmak değil.

İstek yöntemleri temel standart üzerinde fiiller kümesi ne yapacağını o dosyalara ile ...

  • GET indirme anlamına gelir
  • HEAD, bilgi almak anlamına gelir
  • PUT yükleme anlamına gelir
  • DELETE, kaldır anlamına gelir
  • POST, veri göndermek anlamına gelir
  • SEÇENEKLER bana ne yapabileceğimi söylemek anlamına gelir

HTTP / 0.9 gün, talep hattı protokol talep bacak tek şey; istek üstbilgisi yok, yanıt üstbilgisi yok. Sadece yazın , basın , sunucu yanıt gövdesini (yani HTML içeriği) döndürecek ve tamam teşekkürler güle (yani bağlantıyı kapatın).GET /somefileEnter

Sadece neden bu şekilde tasarlandığını sormak istiyorsan ? Cevabım, o zamanlar mevcut olan içerik alışverişi türünü işlemek için yazılmış olması , yani kullanıcıların isteği üzerine statik HTML dosyaları sunması.

Ancak, bu anlambilimin modern uygulama sunucusunda nasıl ele alınacağını sormak istediyseniz ...

HTTP protokolünü yalnızca bir istek gövdesi ve bir yanıt gövdesi kullanarak uygulayamıyor muyuz?

Çeşitli HTTP yöntemlerinin uygulanması gerçekten gerekli mi?

Cevabım şudur: ne yapmak isterseniz yapın, ancak uygulama mantığını protokolün beklentilerini karşılayacak şekilde uygulamamanız gerektiğini unutmayın : GET gibi beklentiler verileri değiştirmemelidir (ya da çok gevşek, en azından idempotent sonuç almalıdır) ), HEAD GET ile aynı sonuca sahip olmalıdır, ancak yanıt gövdesi olmadan PUT, hedef URI'nin içeriğini kullanılabilir hale getirmelidir (başarılı olursa).

Beklentilerini dikkatlice düşünmeden beklentilere karşı giderseniz , hoş olmayan şeyler olur, örneğin ...

  • Veri gönderme kullanımına GET yöntemini kullandığınızda, sunucu yüzünüzde 414 " URI Çok Uzun " hatası verebilir.
  • GET yöntemini veri değiştirme kullanımına soktuğunuzda, bazen kullanıcı önbelleğe alma proxy'sinin arkasındayken değişiklik yapılmadığını veya kullanıcı URL'yi yer işaretinden geri çağırdığında (veya web tarayıcıları ona ulaştığında) beklenmedik değişiklikler yapılacağını görürsünüz. .
  • HEAD yöntemine yanlış yanıt verdiğinizde, otomatik site kontrol araçlarınızın (örn. wget --spider) Sitenizde kefaletini görürsünüz .
  • İçerik indirmeye POST yöntemini eklediğinizde, yer işaretlemenin veya URL'yi tarayıcıya girmenin işe yaramayacağını görürsünüz.
  • Ve daha fazlası...

" Acemi kuralları biliyor ama gaziler istisnaları biliyor. "

Her neyse, bazı dar kullanım durumları için bazı kurallara karşı çıkmak için bazı geçerli mazeretler bulabilirsiniz; ancak araştırmanızı yaptığınızdan ve tüm olasılıkları göz önünde bulundurduğunuzdan emin olun. Aksi takdirde, birlikte çalışabilirliği baltalayacak ve "kullanıcı deneyimlerini" mahvedeceksiniz.

Kullanıcıların her zaman test ettiğiniz genel ad marka istemcileri / kullanıcı aracılarının en son parlak sunumunu kullanmaları garanti edilmez. İhtiyaçlarına göre uyarlanmış yerel bir marka (ben dahil), yandaki özel dükkandan sipariş ettikleri özel bir markayı veya bir depodan çıkardıkları eski bir markayı kullanabilirler. Tüm bunlarla bile, sitelerinizin hala makul bir hizmet vermesi bekleniyor. Standartlarımızın olmasının bir nedeni budur.

Standardı dikkatsizce kırmak, kullanıcılarınıza ayrımcılık uyguladığınız anlamına da gelir .


3

Teoride, her yerde get'i kullanabileceğimiz doğrudur ve bu bir çeşit iştir. Bazı yazılımlar bile istek gövdesi ile GET kullanın (size elasticsearch / kibana bakıyorum). Bu elbette korkunç bir şey.

Bunun en önemli nedeni, farklı yöntemlerin farklı semantiğe sahip olmasıdır. Bazıları güvende, bazıları idempotent. Bazıları da. Hangisinin hangisi olduğunu görün

Bu, örneğin diğer uygulamalarla etkileşime girerken önemlidir. GET uç noktalarının yan etkileri olması gerekmez. Google tarafınızı tararken bu önemlidir. PUT'un idempotent olması gerekiyor, bu da istemcinin bir arıza durumunda tekrar denemekte özgür olduğu anlamına geliyor. POST için durum böyle değildir, bu nedenle bir gönderi isteğinde f5 tuşuna basarsanız tarayıcıların çirkin bir onay kutusu olması gerekir.

POST kullanmanız gereken yerlerde GET kullanırsanız neler olabileceğini görün


1
Bir vücut ile GET aslında şartnameye uygundur.
TRiG

İlginç. - 2014'te değişmiş gibi görünüyor.
Esben Skov Pedersen

1
Bir bedenle GET uymaz, sadece onu özel olarak ihlal etmez. Şimdi tanımsız, bu yüzden bazı istemciler desteklemiyor. CURL'un bir örnek olduğuna inanıyorum
Mars

2

GET, POST, vb. Aynı işlevin aşırı yüklenmesi veya hatta alıcılar ve ayarlayıcılar olarak düşünebilirsiniz.

GET_MyVar() bir girdi parametresi (İstek Gövdesi olarak da bilinir) almaz, ancak bir şey döndürür.

POST_MyVar(string blah)girdi ile bir şeyler yapar (yine istek gövdesi) ve bir şeyler döndürebilir. (Ayrıca en azından bir yanıt kodu döndürmek gerekiyor, böylece fonksiyonun çalıştığını biliyoruz!)

DELETE_MyVar() Ayrıca muhtemelen hiçbir şey almaz ve bir şey silmek bekleniyor.

Evet, hepsini aşağıdakilerle uygulayabiliriz:
MyVar(string Action, string? blah)

Bu şekilde yalnızca bir çağrıyı kabul edebilir ve ardından başka bir parametreye göre ne yapacağımızı seçebiliriz.

Ancak bu yaklaşımın kolaylıklarından biri, tarayıcıların ve sunucuların bu şeylerin çalışma şeklini optimize etmelerine izin vermesidir. Örneğin, sunucu burada tüm istekleri engellemek isteyebilir Action==DELETE. Belki tarayıcılar bir şeyleri önbelleğe almak isterler, Action==GET.eğer değilse, her fonksiyonda yazmak zorundayızif (Action==Delete) {return AngryFace}

Her şeyi tam olarak protokole göre uygulamak için bir gereklilik yoktur, ancak protokol temel olarak hepimizin uymaya karar verdiği bir dizi kuraldır. Bu şekilde, sunucuyu görmemiş olsam bile sitenizin ne yapacağını kolayca tahmin edebilirim!


1

HTTP yöntemleri farklı amaçlara hizmet eder. Genel olarak, GETindirmeler içindir ve POSTyüklemeler içindir.

HTTP protokolünün bir kısmını yalnızca bir istek gövdesi ve bir yanıt gövdesi kullanarak uygulamanın tek yolu uygulamak olacaktır POST. GETistek gövdesi yok. Yalnızca üstbilgileri olan bir istek vardır, ancak gövde yoktur. Bu sadece bir dokümanın indirilmesi talebidir. POSThem istek gövdesine (dosya yükleme) hem de yanıt gövdesine (sonucu gösteren belge) sahiptir.

Yani sadece uygulayabilir POSTve yapılabilir misiniz? Sitenizin standart tarayıcılarda kullanılabilir olmasını istiyorsanız değil. Tarayıcıların gönderdiği varsayılan istek türü GET. POSTistekler genellikle yalnızca web sayfalarındaki formlar gönderildiğinde veya AJAX çağrıları için gönderilir. Yalnızca bu sunucu yalnızca AJAX çağrıları için kullanılıyorsa ve kullanıcılar tarafından görülebilen sayfalar için kullanılmıyorsa, yalnızca kurtulabilirsiniz POST.

Tarayıcılar bazen HEADbir belgenin son indirilmesinden bu yana değişip değişmediğini kontrol etmek için istekler de gönderir , bu nedenle en azından bunu da uygulamanız tavsiye edilir.

Her durumda, sitenize sıfırdan bir web sunucusu uygulamak için iyi bir neden yoktur. HTTP protokolü karmaşıktır. Çeşitli yöntemlere ek olarak, boru hattı ve yığınlanmış istekleri de uygulamanız gerekir. Web uygulamanızı sizin için HTTP protokolünü işleyen Apache, Nginx veya IIS gibi bir web sunucusunun üzerine kurmak çok daha kolaydır. Servlet'lerden bahsediyorsunuz, belki de Servlet'leri çalıştıran Tomcat veya JBoss web sunucularını kullanmalısınız.


Bence bu soru A web sitesinden daha üst seviyede. "Neden GET ve POST'u uygulamam gerekiyor" değil, "tarayıcılar neden GET ve POST'u uyguluyor"?
Mars

@Mars Bu durumda, soru bu site için konu ile ilgili değildir.
Stephen Ostermiller

Sanırım bir tarih sorusu ve tüm web sitelerini etkileyen sorunların altına girdiği anlaşılıyor (Soru Sor sayfasından). Ama OP kayboldu, bu yüzden her zaman bir gizem olacak
Mars

0

Doğru, biz sadece yapabiliriz, GET, POST, PUT vb. Sadece tarihsel sözleşmeler olsaydı, HTTP'nin sadece POST yöntemi ve başka bir şeyle geçeceğini söylesem de, GET'i ortadan kaldırmak çok büyük bir girişim olurdu, Bu yapılamadı, at zaten ona cıvatalı


1
"GET, POST, PUT vb. Sadece tarihsel sözleşmelerdir" - Onlar sözleşmeler değildir. Onlar var kesin belirlenmiş davranışları ve dahası, bunlar tam olarak belirttiğiniz farklı davranışlar.
Jörg W Mittag

Bir web API geliştiricisi olarak, GET'leri POST'lerle kolayca değiştirebilirim ve bunun tersi, cevabımın temelidir, dürüst olmak gerekirse POST'un uğraşmak için daha az sorunu vardır ve yolum olsaydı tüm API yöntemlerimi POST yöntemlerini yapsaydım
user104723

-1

Önerilen protokol korsanlara karşı önemli ölçüde daha az güvenli olacaktır.

Web sitelerinin değişkenler ve URL gibi bilgileri depolamaktan uzaklaşmasının bir nedeni vardır ve bu nedenle basittir: saldırganlara sisteminize saldırmak için çok basit bir yol sağlar. Düz metin URL bilgilerini gözlemleyerek, web sunucunuza gönderilen verilerin oluşturulma şeklini belirleyebilirler; daha sonra bu bilgileri, sunucunuza kötü amaçlı kod veya veri enjekte etmelerini sağlayan özel olarak oluşturulmuş bir URL kullanarak sunucunuza bir saldırı gerçekleştirmek için kullanabilirler.


HTTPS altında, GET'in içeriği ağda hiç düz metin değildir ... Ve saldırganlar, kötü şans, kaba kuvvet veya diğer tekniklerle kötü amaçlı kod enjekte edebilir, zaten herhangi bir şey görmelerine gerek yoktur.
Patrick Mevzek
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.