HTML formlarında neden PUT ve DELETE yöntemleri yok?

HTML4 / XHTML1, formlarda yalnızca GET ve POST’lara izin verir, şimdi HTML5’in de aynısını yapacak gibi görünüyor. Bu ikisini eklemek için bir öneri var ama çekiş kazanıyor gibi görünmüyor. HTML5 şartname taslağına PUT ve DELETE dahil edilmemesi için teknik veya politik nedenler nelerdi?

Bu büyüleyici bir soru. Buradaki diğer cevapların tümü spekülatif, bazı durumlarda ise yanlış anlaşılıyor. Bunun yerine burada fikrimi yazma, aslında biraz araştırma yaptım ve neden görüşmek özgün kaynaklar bulundu silmek ve satım HTML5 formu standardın bir parçası değildir.

Sonradan anlaşıldı ki, bu yöntemler edildi dahil birçok erken HTML5 taslaklar (!), Ama daha sonra çıkarıldı sonraki taslaklar . Mozilla da bunu bir Firefox beta sürümünde uygulamıştı .

Bu yöntemleri taslaktan çıkarmanın mantığı neydi? W3C bu konuyu 10671 hata raporunda tartıştı . Mike Amundsen bu desteğin lehine savundu:

XmlHttpRequest nesnesini kullanan modern Web tarayıcıları için, kaynak sunucudaki kaynakları değiştirmek üzere PUT ve DELETE öğelerini çalıştırmak oldukça basittir. Betiksiz tarayıcı etkileşimleri için bu o kadar basit değil. [...]

Bu model, sıklıkla kullanılan çeşitli Web çerçevelerinin / kütüphanelerinin "yerleşik" bir çalışma ortamı yarattığı sıklıkta gereklidir. [...]

Diğer hususlar:

• POST'u PUT / DELETE kullanmak yerine tünel olarak kullanmak, yanlış eşleşmeleri önbelleğe almaya neden olabilir (örneğin POST yanıtları önbelleklenebilir , PUT yanıtları (6) değil, DELETE yanıtları (7))
• Belirsiz bir işlem (PUT / DELETE) gerçekleştirmek için bağımsız olmayan bir yöntemin (POST) kullanılması, ağ arızalarından dolayı kurtarmayı karmaşıklaştırır (örneğin, "Bu işlemi tekrarlamak güvenli midir?").
• [...]

Tüm görevini okumaya değer.

Tom Wardrop da ilginç bir noktaya değindi:

HTML, ayrılmaz bir şekilde HTTP'ye bağlanmıştır. HTML, HTTP'nin insan arayüzüdür. Bu nedenle, HTML'nin HTTP şartnamesindeki tüm ilgili yöntemleri desteklemediği otomatik olarak sorgulanabilir. Makineler neden PUT ve DELETE kaynaklarını kullanabilir, ancak insanlar yapamaz? [...]

Semantik biçimlendirmeyi sağlamak için HTML çok uzun sürerken, semantik HTTP isteklerini sağlamak için bu kadar çaba harcamamış olması çelişkilidir.

Hata sonunda , aşağıdaki gerekçeyle, Ian Hickson tarafından Won't Fix olarak kapatıldı :

Form yöntemi olarak PUT anlamsız, bir form yükü PUT istemezsiniz. DELETE yalnızca yük taşımadığında mantıklıdır, bu nedenle formlarla da pek anlamlı olmaz.

Ancak, bu hikayenin sonu değil! Sorun W3C hata izleyicide kapatıldı ve HTML Çalışma Grubu sorun izleyicisine yükseltildi :

https://www.w3.org/html/wg/tracker/issues/195

Bu noktada, bu yöntemlere destek olmamanın asıl sebebinin, basitçe kimsenin bunun için kapsamlı bir şartname yazmak için zaman harcamamış olduğu anlaşılıyor.

GET ve POST açık bir içerik nötr mantığına sahiptir. GET, bir URL'nin içeriğini tekrarlamanın ve muhtemelen önbelleğin güvenli olacağı bir şekilde almaktır. POST, tekrarlamak, spekülatif bir şekilde yürütmek veya önbelleklemek güvenli olmayan bir şey yapmaktır.

PUT veya DELETE için benzer bir mantık yoktu. Her ikisi de tamamen POST kapsamındadır. Bir kaynak oluşturmak veya yok etmek, tekrarlanması güvenli olmayan, spekülatif olarak yürütülemeyen ve önbelleğe alınmaması gereken işlemlerdir. Onlar için özel bir anlambilim gerekmez.

Yani temelde faydası yoktur.

Bu, 2010 yılında Bug 10671'de PUT ve DELETE için form yöntemleri olarak destek eklenmesinin göz önünde bulundurulmasıyla yükseltildi .

Bu "özellik" ve biraz el sıkıntısı için ılımlı bir itiş vardı, ancak sonuçta bu Çalışma Grupları hata izleyicisinde iki sorun olarak yükseltildi:

• SAYI-195: http isteği formlarını formlardan geliştir
• ISSUE-196: Kullanıcı aracısı http yanıt işleme davranışını tanımlayın

ISSUE-196 sorunu , HTML spesifikasyonu şu anda POST taleplerine verilen yanıtların nasıl ele alınacağını kısıtlamadığından spesifikasyonda herhangi bir değişiklik yapmama kararıyla sonuçlandı. Bu özel sorunun POST yönlendirme modellerini yaygın olarak kullanımda bir araya getirme girişimi ve ReSTful sunucuların genellikle tarayıcıda işlenecek bir şey yerine kısa mesajlarla 2xx yanıtları sağlama biçiminde ortaya çıktığını düşünüyorum.

Sorun ISSUE-195 sandalyelere sunuldu. Cameron Jones, 18 Ocak 2012'de , 29 Mayıs 2014'te ilk çalışma taslağı olarak sunacağı bir değişiklik teklifi yazma konusunda gönüllü olmaya başladı . Taslak, W3C önerileri sürecinden geçecek .

Şansınız varsa, bu yakında bir W3C önerisi olacak ve tarayıcı satıcıları tarafından uygulanacak ve birleştirilmiş, anlamsal ve tarayıcı dostu ReSTful hizmetleri üretmek için engelleyicileri kaldırma konusunda büyük bir adım olacaktır. Bunun hizmet modellerinde ilginç bir gelişime yol açacağını hayal ediyorum. Jon Moore'un izlemeye değer olan Hypermedia API'leri ile güzel bir konuşması var, bu ilgimi çekti ancak ilk engelden düştü (bu).

Anladığım kadarıyla tarayıcılar bir PUT veya DELETE gönderdiklerinde ne yapacaklarını bilmezler. Bir POST genellikle uygun bir sayfaya yönlendirir, ancak PUT ve DELETE genellikle yapmaz. Bu, ajax veya yerel bir program aracılığıyla arama yapmak için uygun olmalarını sağlar, ancak bir web tarayıcı formundan değil.

Şu an onu durduramıyorum, ama bunu tartışırken html5 posta listelerinden birini okuduğumu hatırlıyorum.

Tarih

Html formlarının RFC1866'daki ilk görünümünden bahsetmeye değer olduğunu düşünüyorum (Bölüm 8.1) . Burada yöntem özniteliği aşağıdaki gibi tanımlanır:

METHOD
        selects a method of accessing the action URI. The set of
        applicable methods is a function of the scheme of the
        action URI of the form. See 8.2.2, "Query Forms:
        METHOD=GET" and 8.2.3, "Forms with Side-Effects:
        METHOD=POST".

Daha fazla açıklama Bölüm 8.2.2 - GET ve Bölüm 8.2.3 - POST'te yer almaktadır.

HTML 2.0’ın (Kasım 1995) HTTP 1.0’dan (Mayıs 1996) önce belirtildiğini unutmayın . Böylece herkes HTTP'yi sadece GET ile (HTTP 0.9'dan itibaren) ya da POST uzantısıyla kullandı. Ancak sadece birkaç web sunucusu PUT ve DELETE destekli ( HTTP 1.0 Ekinde belirtildiği gibi ).

Düşünceler

Berners-Lee'nin semantik ağdaki gelişiminin nasıl geliştiğini düşünürseniz, gerçek sorunlardan genel bir konsepte geçtiği açıktır. İlk önce belgeleri paylaşmak istedi. Bu yüzden işaretlemeye ihtiyacı vardı. Daha sonra içerik için veritabanlarını sorgulamak istedi, bu yüzden formlara ihtiyacı vardı. Sonra veritabanına yeni veriler koymak istedi. Bu yüzden GET ve POST ile formlar kullandı. Bundan sonra uzaktaki veriler üzerinde her CRUD işlemini yapabileceğinizi fark etmiş olabilir, bu yüzden HTTP genişletildi fakat hiçbir zaman HTML olmadı çünkü çok geç kalmıştı (sadece birkaç sunucu yeni CRUD işlemlerini destekledi).

Sadece çılgınca bir tahminde bulunmak, ancak muhtemelen HTTP en iyi zamanda erişim kontrolü konusunda çok iyi değil ve herkesin ihtiyaç duyduğu son şey kötü niyetli URL'lerin kötü güvenlikli bir web sitesi ve / veya uygulamasından ödün vermesi için daha da fazla yoldur.

HTTP, sunucudan istemciye indirmekten başka dosya transferleri için iyi bir protokol değildir. FTP kullanın - veya daha iyisi, SFTP.

Al ve gönder, isteğin verilerini iletme biçimleridir.

Sanırım bir RESTFUL hizmetine başvuru formunda bulunma hakkında sorular soruyorsunuz. Ancak, http isteğinin amacını kabul etmek için http isteği standardını değiştirmek mantıklı değildir. İsteğin doldurma amacı ile ilgili bilgiler, girdi alanlarında en iyi şekilde ele alınır.

Bir adrese sahip olup alma ve gönderme, sunucunun isteği ve giriş değerlerini doğru yorumlamasını sağlar. Oradan giriş değerleri sunucuya açık uçlu istekler yapmanıza ve istediğiniz zaman yapmanıza izin verir. Örneğin, değerleri "koymak" ve "silmek" olan bir alana sahip olabilirsiniz