URL sorgu parametreleri ile HTTP POST - iyi bir fikir mi değil mi? [kapalı]

Ben HTTP üzerinden gitmek için bir API tasarlıyorum ve HTTP POST komutunu kullanarak merak ediyorum, ama sadece URL sorgu parametreleri ve hiçbir istek gövdesi ile gitmek için iyi bir yoldur.

hususlar:

• "İyi Web tasarımı", POST yoluyla idempotent olmayan eylemlerin gönderilmesini gerektirir. Bu idempotent olmayan bir eylemdir.
• URL'de istek parametreleri bulunduğunda bu uygulamayı geliştirmek ve hatalarını ayıklamak daha kolaydır.
• API yaygın kullanıma yönelik değildir.
• Görünüşe göre, hiçbir gövdeden bir POST isteği yapmak biraz daha fazla iş gerektirmeyecektir, örneğin bir Content-Length: 0başlık açıkça eklenmelidir.
• Bana öyle geliyor ki, gövdesi olmayan bir POST, çoğu geliştiricinin ve HTTP çerçevesinin beklentilerine karşı biraz karşıdır.

İstek gövdesi yerine, URL sorgusu üzerinden bir POST isteğinde parametre göndermenin başka tuzakları veya avantajları var mı?

Düzenleme: Bu göz önünde bulundurulmasının nedeni, operasyonlar idempotent değildir ve alma dışında yan etkileri olmasıdır. HTTP spesifikasyonuna bakın :

Özellikle, GET ve HEAD yöntemlerinin geri alım dışında bir işlem yapmanın önemine sahip OLMAMASI gerektiği anlaşılmıştır. Bu yöntemler "güvenli" olarak değerlendirilmelidir. Bu, kullanıcı aracılarının POST, PUT ve DELETE gibi diğer yöntemleri özel bir şekilde temsil etmesini sağlar, böylece kullanıcı muhtemelen güvenli olmayan bir eylemin istendiğinden haberdar edilir.

...

Yöntemler "idempotence" özelliğine de sahip olabilir (hata veya son kullanma sorunlarının yanı sıra) N> 0 özdeş isteklerin yan etkileri tek bir istekle aynıdır. GET, HEAD, PUT ve DELETE yöntemleri bu özelliği paylaşır. Ayrıca, OPTIONS ve TRACE yöntemlerinin yan etkileri OLMAMALIDIR ve bu nedenle doğası gereği idempotenttir.

Eyleminiz idempotent değilse, kullanmanız GEREKİRPOST . Eğer yapmazsan, sadece hattan sorun istiyorsun. GET, PUTVe DELETEyöntemler vardır gerekli İdempotent olması. İstemci, GEThizmetiniz için olası her isteği önceden getiriyorsa uygulamanızda ne olacağını hayal edin - bu, istemcinin göreceği yan etkilere neden olursa, bir sorun var demektir.

Ben POSTbir sorgu dizesi ile ama bir gövde olmadan gönderme garip görünüyor, ama bazı durumlarda uygun olabileceğini düşünüyorum.

Bir URL'nin sorgu bölümünü, geçerli isteğin kapsamını sınırlamak için kaynağa bir komut olarak düşünün. Tipik olarak, sorgu dizeleri bir GETisteği (gibi ?page=1&sort=title) sıralamak veya filtrelemek için kullanılır, ancak bir POSTkapsamı (belki de gibi ?action=delete&id=5) sınırlamak için de mantıklı olduğunu varsayalım .

Herkes haklı: idempotent olmayan talepler için POST'a sadık kalın.

Hem bir URI sorgu dizesi hem de istek içeriği kullanmaya ne dersiniz? Peki geçerli HTTP (not 1'e bakınız), neden olmasın ?!

Ayrıca tamamen mantıklıdır: Sorgu dizesi parçaları da dahil olmak üzere URL'ler kaynakları bulmak içindir . HTTP yöntemi fiilleri (POST - ve isteğe bağlı istek içeriği) eylemleri veya kaynaklarla ne yapılacağını belirtmek içindir . Bunlar dik kaygılar olmalıdır. (Ancak, ContentType = application / x-www-form-urlencoded özel durumu için güzel dikey endişeler değildir, aşağıdaki not 2'ye bakın.)

Not 1: HTTP belirtimi (1.1), sorgu parametrelerinin ve içeriğinin POST veya PUT isteklerini kabul eden bir HTTP sunucusu için birbirini dışladığını belirtmez. Yani herhangi bir sunucu her ikisini de kabul etmekte özgürdür. Yani sunucuyu yazarsanız, her ikisini de kabul etmeyi durduracak hiçbir şey yoktur (belki esnek olmayan bir çerçeve hariç). Genellikle, sunucu sorgu dizelerini istediği kurallara göre yorumlayabilir. Hatta onları İçerik Türü gibi diğer başlıklara atıfta bulunan Not 2'ye götüren koşullu mantıkla da yorumlayabilir:

Not 2: Bir web tarayıcısı , kullanıcıların web uygulamanıza erişmesinin birincil yoluysa ve application / x-www-form-urlencoded , yayınladıkları İçerik Türü ise, o İçerik Türü için kuralları izlemeniz gerekir . Ve application / x-www-form-urlencoded için kurallar çok daha spesifiktir (ve açıkçası, olağandışı): bu durumda URI'yi bir kaynak konumu olarak değil, bir parametre kümesi olarak yorumlamanız gerekir. [Bu Powerlord'un kullandığı aynı kullanışlılık noktasıdır; sunucunuza içerik göndermek için web formlarını kullanmanın zor olabileceğini unutmayın. Sadece biraz farklı açıkladım.]

Not 3: Sorgu dizeleri orijinal olarak ne içindir? RFC 3986, HTTP sorgu dizelerini, kaynağı bulmanın hiyerarşik olmayan bir yolu olarak çalışan bir URI parçası olarak tanımlar.

Bu soruyu soran okuyucuların iyi RESTful mimarisinin ne olduğunu sormak istemeleri durumunda: RESTful mimari modeli URI şemalarının belirli bir şekilde çalışmasını gerektirmez. RESTful mimarisi, kaynakların önbelleğe alınabilirliği, kaynakların kendilerinin tasarımı (davranışları, yetenekleri ve temsili) ve idempotence'in karşılanıp karşılanmadığı gibi sistemin diğer özellikleriyle ilgilidir. Başka bir deyişle, HTTP protokolü ve HTTP yöntemi fiil kümesiyle son derece uyumlu bir tasarım elde etmek. :-) (Diğer bir deyişle, RESTful mimari kaynakları nasıl çok presciptive değildir bulunan .)

Son not: bazen sorgu parametreleri, kaynakları bulmayan veya içeriği kodlamayan diğer şeyler için kullanılır. Hiç 'PUT = true' veya 'POST = true' gibi bir sorgu parametresi gördünüz mü? Bunlar, PUT ve POST yöntemlerini kullanmanıza izin vermeyen tarayıcılar için geçici çözümlerdir. Bu tür parametreler (tel üzerinde) URL sorgu dizesinin bir parçası olarak görülmekle birlikte, onlar ruhu içinde URL sorgusunun bir parçası olmadığını iddia ediyorum .

Sebep mi istiyorsun? Işte bir tane:

Web formu, GET ve POST karışımı kullanan bir sayfaya istek göndermek için kullanılamaz. Formun yöntemini GET olarak ayarlarsanız, tüm parametreler sorgu dizesinde bulunur. Formun yöntemini POST olarak ayarlarsanız, tüm parametreler istek gövdesinde olur.

Kaynak: HTML 4.01 standardı, bölüm 17.13 Form Gönderme

Programlı bir bakış açısından, müşteri için parametreleri paketliyor ve bunları url'ye ekliyor ve bir GET'e karşı bir POST yürütüyor. Sunucu tarafında, gönderilen baytlar yerine sorgu dizesinden gelen parametreleri değerlendirir. Temel olarak, bir yıkama.

Avantajların / dezavantajların olabileceği yerlerde, belirli istemci platformlarının ağ yığınlarındaki POST ve GET yordamlarıyla nasıl çalıştığı ve web sunucusunun bu isteklerle nasıl başa çıktığı olabilir. Uygulamanıza bağlı olarak, bir yaklaşım diğerinden daha verimli olabilir. Bunu bilmek burada kararınızı yönlendirecektir.

Bununla birlikte, bir programcının bakış açısından, vücuttaki tüm parametrelerle bir POST'ye veya url'deki tüm parametrelerle bir GET'e izin vermeyi ve herhangi bir POST isteği ile url parametrelerini açıkça görmezden gelmeyi tercih ederim. Karışıklığı önler.

İçerik yükü POST gövdesi ile sınırlı tutarken URL üzerindeki kaynağı tanımlayan sorgu argümanlarına sahip olmanın hala oldukça RESTful olabileceğini düşünürdüm. Bu, "Ne gönderiyorum?" "Kime gönderiyorum?"

DİNLENME kamp biz HTTP fiiller kullanma şeklinizi standardize için kullanabileceği bazı yol gösterici ilkeler vardır. Bu, yaptığınız gibi RESTful API'leri oluştururken yardımcı olur.

Özetle: GET Salt Okunur olmalıdır, yani sunucu durumu üzerinde hiçbir etkisi yoktur. POST, sunucuda bir kaynak oluşturmak için kullanılır. PUT, bir kaynağı güncellemek veya oluşturmak için kullanılır. DELETE bir kaynağı silmek için kullanılır.

Başka bir deyişle, API eyleminiz sunucu durumunu değiştirirse, REST bize POST / PUT / DELETE kullanmanızı sağlar, ancak GET kullanmamamızı önerir.

Kullanıcı aracıları genellikle birden fazla POST yapmanın kötü olduğunu ve buna karşı uyaracağını anlar, çünkü POST'un amacı sunucu durumunu değiştirmek (örn. Kasada mallar için ödeme yapmak) ve muhtemelen bunu iki kez yapmak istemezsiniz!

İstediğiniz sıklıkta yapabileceğiniz bir GET ile karşılaştırın (idempotent).

Kabul ediyorum - verileri yalnızca URL'ye değil, URL'ye geçiriyorsanız bir GET isteği kullanmak daha güvenlidir. Tüm POST + GET konseptiyle ilgili bazı ek görüşler için bu benzer soruya bakın .