Yanıtlar:
HTTP PUT:
PUT, belirli bir URI'ye ve tam olarak bu URI'ye bir dosya veya kaynak koyar. Bu URI'de zaten bir dosya veya kaynak varsa, PUT bu dosya veya kaynağın yerini alır. Orada dosya veya kaynak yoksa PUT bir dosya oluşturur. PUT idempotenttir , ancak paradoksal olarak PUT yanıtları önbelleğe alınamaz.
HTTP POST:
POST belirli bir URI'ye veri gönderir ve o URI'deki kaynağın isteği işlemesini bekler. Bu noktada web sunucusu, belirtilen kaynak bağlamındaki verilerle ne yapılacağını belirleyebilir. POST bir yöntem değildir İdempotent ancak SONRASI tepkiler olan çok uzun sunucusunun uygun Cache-Control ayarlar ve başlıkları sona eriyor olarak önbelleğe alınabilir.
Resmi HTTP RFC POST'u şu şekilde belirtir:
POST ve PUT arasındaki fark:
RFC'nin kendisi temel farkı açıklıyor:
POST ve PUT istekleri arasındaki temel fark, İstek-URI'sinin farklı anlamına yansır. Bir POST isteğindeki URI, ekteki varlığı işleyecek kaynağı tanımlar. Bu kaynak veri kabul eden bir süreç, başka bir protokole açılan bir geçit veya ek açıklamaları kabul eden ayrı bir varlık olabilir. Buna karşılık, bir PUT isteğindeki URI, istekle birlikte gelen varlığı tanımlar - kullanıcı aracısı, URI'nin amaçlandığını bilir ve sunucunun, isteği başka bir kaynağa uygulamaması GEREKİR. Sunucu, isteğin farklı bir URI'ye uygulanmasını istiyorsa, 301 (Kalıcı Olarak Taşındı) yanıtı göndermelidir ZORUNLU; kullanıcı aracısı daha sonra isteği yeniden yönlendirip yönlendirmemeye ilişkin kendi kararını verebilir.
Ek olarak ve biraz daha kısaca, RFC 7231 Bölüm 4.3.4 PUT belirtileri (vurgu eklenmiştir),
4.3.4. KOYMAK
PUT yöntemi, hedef kaynağın durumunun
createdveyareplacedistek iletisi bilgi yükünde yer alan temsil tarafından tanımlanan durumla olmasını ister .
Doğru yöntemi kullanarak, ilgisiz bir kenara:
REST ROA ve SOAP'ın bir yararı, HTTP REST ROA kullanırken, HTTP fiillerinin / yöntemlerinin doğru kullanımını teşvik etmesidir. Örneğin, PUT'u yalnızca o konumda bir kaynak oluşturmak istediğinizde kullanabilirsiniz. Ve hiçbir zaman bir kaynak oluşturmak veya değiştirmek için GET'i kullanmazsınız.
If the Request-URI does not point to an existing resource [...] the origin server *can* create the resource with that URI. Peki eğer mevcut değilse bir kaynak yaratmayı reddeden bir PUT uygulaması doğru olur, değil mi? Eğer öyleyse, bu pratikte olur mu? Ya da genellikle PUT üzerinde uygulamalar yaratılır?
Sadece anlambilim.
HTTP'nin PUTisteğin gövdesini kabul etmesi ve ardından bunu URI tarafından tanımlanan kaynakta depolaması gerekir.
Bir HTTP POSTdaha geneldir. Sunucuda bir eylem başlatması gerekiyor. Bu eylem, istek gövdesini URI tarafından tanımlanan kaynakta depolamak olabilir veya farklı bir URI olabilir veya farklı bir eylem olabilir.
PUT olduğu gibi bir dosya yükleme. Bir URI'ye koymak tam olarak bu URI'yi etkiler. Bir URI'ye gönderilen POST'un herhangi bir etkisi olabilir.
REST tarzı kaynaklara örnekler vermek için:
Bir sürü kitap bilgisi içeren "POST / kitaplar" yeni bir kitap oluşturabilir ve bu kitabı tanımlayan yeni URL ile yanıt verebilir: "/ books / 5".
"PUT / books / 5", 5 kimliğine sahip yeni bir kitap oluşturmak veya mevcut kitabı 5 kimliğiyle değiştirmek zorunda kalacaktır.
Kaynak olmayan tarzda, POST, yan etkisi olan hemen hemen her şey için kullanılabilir. Diğer bir fark, PUT'un idempotent olması gerektiğidir - aynı URL'ye aynı verilerin birden fazla PUT'sinin iyi olması gerekir;
PUT, bir öğeyi belirli bir URI'ye "yüklemek" veya o URI'da olanların üzerine yazmak için bir yöntem olarak ifade edilir.
Öte yandan POST, belirli bir URI'ye İLİŞKİLİ veri göndermenin bir yoludur.
HTTP RFC'ye bakın
Bildiğim kadarıyla, PUT çoğunlukla kayıtları güncellemek için kullanılır.
POST - Belge veya başka bir kaynak oluşturmak için
PUT - Oluşturulan belgeyi veya başka bir kaynağı güncellemek için.
Ancak açık olmak gerekirse, PUT genellikle mevcut kaydı orada varsa 'değiştirir' ve orada değilse oluşturur.
Diğerleri zaten mükemmel cevaplar yayınladılar, sadece çoğu dil, çerçeve ve kullanım senaryosuyla PST ile çok daha sık POST ile uğraşacağınızı eklemek istedim. PUT, DELETE, vs.'nin temelde önemsiz sorular olduğu noktaya kadar.
Lütfen bakınız: http://zacharyvoase.com/2009/07/03/http-post-put-diff/
Son zamanlarda web geliştiricileri tarafından bir POST kaynak oluşturmak için kullanılır ve bir PUT güncelleştirmek / değiştirmek için kullanılan bir yanlış anlama ile oldukça rahatsız alıyorum.
RFC 2616 (“Köprü Metni Aktarım Protokolü - HTTP / 1.1”), Bölüm 9.6'nın (“PUT”) 55. sayfasına bakarsanız, PUT'un gerçekte ne için olduğunu görürsünüz:
PUT yöntemi, ekteki varlığın sağlanan Request-URI altında saklanmasını ister.
POST ve PUT arasındaki farkı açıklamak için kullanışlı bir paragraf da var:
POST ve PUT istekleri arasındaki temel fark, İstek-URI'sinin farklı anlamına yansır. Bir POST isteğindeki URI, ekteki varlığı işleyecek kaynağı tanımlar. Bu kaynak veri kabul eden bir süreç, başka bir protokole açılan bir geçit veya ek açıklamaları kabul eden ayrı bir varlık olabilir. Buna karşılık, bir PUT isteğindeki URI, istekle birlikte gelen varlığı tanımlar - kullanıcı aracısı, URI'nin amaçlandığını bilir ve sunucunun, isteği başka bir kaynağa uygulamaması GEREKİR.
Güncelleme / oluşturma arasındaki farktan bahsetmiyor, çünkü bununla ilgili değil. Bu, arasındaki fark hakkında:
obj.set_attribute(value) # A POST request.
Ve bu:
obj.attribute = value # A PUT request.
Bu yüzden lütfen bu popüler yanılgının yayılmasını durdurun. RFC'lerinizi okuyun.
POST, fabrika tipi bir yöntem olarak kabul edilir. İstediğinizi oluşturmak için veri eklersiniz ve diğer tarafta ne varsa ne yapacağınızı bilir. Bir PUT, belirli bir URL'deki mevcut verileri güncellemek veya URI'nin ne olacağını bildiğinizde yeni bir şey oluşturmak için kullanılır ve zaten mevcut değildir (bir şey oluşturacak ve bir URL döndürecek bir POST yerine) gerekirse).
REST, geliştiricilerden HTTP yöntemlerini protokol tanımıyla tutarlı bir şekilde açıkça kullanmalarını ister. Bu temel REST tasarım ilkesi, oluşturma, okuma, güncelleme ve silme (CRUD) işlemleri ile HTTP yöntemleri arasında bire bir eşleme oluşturur. Bu haritalamaya göre:
• Sunucuda bir kaynak oluşturmak için POST'u kullanın.
• Bir kaynağı almak için GET tuşunu kullanın.
• Bir kaynağın durumunu değiştirmek veya güncellemek için PUT kullanın.
• Bir kaynağı kaldırmak veya silmek için SİL'i kullanın.
Daha fazla bilgi: RESTful Web hizmetleri: IBM'den temel bilgiler
Birini veya diğerini ne zaman kullanacağınız oldukça basit olmalı, ancak karmaşık ifadeler çoğumuz için bir karışıklık kaynağıdır.
PUTZaten kaynak koleksiyonunun bir parçası olan tekil bir kaynağı değiştirmek istediğinizde kullanın . PUTkaynağı bütünüyle değiştirir. Misal:PUT /resources/:resourceId
Sidenote:PATCH Kaynağın bir bölümünü güncellemek istiyorsanız kullanın .
POSTBir kaynak koleksiyonu altına bir alt kaynak eklemek istediğinizde kullanın . POST => /resourcesPUTiçin kullanın .POSTiçin kullanın .GET / şirket / raporlar => tüm raporlar alın
GET / şirket / raporlar / {id} => Al "id" tarafından tanımlanan rapor bilgisi
POST / şirket / raporlar => yeni bir rapor oluşturun
PUT / şirket / raporlar / {id} => Güncelleme "id"
PATCH / şirket / raporlar / {id} => tarafından tanımlanan rapor bilgileri "id"
DELETE / şirket / raporlar / {id} => Raporu "id" ile sil
POST ve PUT arasındaki fark PUT'un idempotent olması, yani aynı PUT isteğinin birden çok kez çağrılması her zaman aynı sonucu üretecektir (bu bir yan etki değildir), diğer yandan tekrar tekrar bir POST isteği çağırmak ( ek) Aynı kaynağı birden çok kez oluşturmanın yan etkileri.
GET : GET kullanan istekler yalnızca veri alır, yani belirtilen kaynağın temsilini ister
POST: Kaynak oluşturmak için sunucuya veri gönderir. İsteğin gövdesinin türü, İçerik Türü üstbilgisi ile belirtilir. Genellikle sunucuda durum veya yan etkilerde değişikliğe neden olur
PUT : Yeni bir kaynak oluşturur veya hedef kaynağın bir temsilini istek yükü ile değiştirir
PATCH : Bir kaynağa kısmi değişiklikler uygulamak için kullanılır
DELETE : Belirtilen kaynağı siler
TRACE : Hedef kaynağa giden yol boyunca bir ileti geri döngü sınaması gerçekleştirir ve kullanışlı bir hata ayıklama mekanizması sağlar
OPTIONS : Hedef kaynağın iletişim seçeneklerini tanımlamak için kullanılır, istemci OPTIONS yöntemi için bir URL veya tüm sunucuyu belirtmek için yıldız işareti (*) belirtebilir.
HEAD : Bir GET isteğiyle aynı, ancak yanıt gövdesi olmadan bir yanıt ister
CONNECT : Hedef kaynak tarafından tanımlanan sunucuya bir tünel oluşturur, SSL (HTTPS) kullanan web sitelerine erişmek için kullanılabilir
REST-ful kullanım
POST yeni bir kaynak oluşturmak için kullanılır ve ardından kaynağı döndürür URI
EX
REQUEST : POST ..../books
{
"book":"booName",
"author":"authorName"
}
Bu çağrı yeni bir kitap oluşturabilir ve bu kitabı döndürür URI
Response ...THE-NEW-RESOURCE-URI/books/5
PUT kaynağı değiştirmek için kullanılır, eğer kaynak varsa, o zaman güncelleyin, ancak kaynak mevcut değilse oluşturun,
REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}
İle PUTbiz kaynak tanımlayıcı biliyorum amaPOST yeni kaynak tanımlayıcı dönecektir
REST dışı kullanım
POST sunucu tarafında bir eylem başlatmak için kullanılır, bu eylem bir kaynak oluşturabilir veya oluşturmayabilir, ancak bu eylemin her zaman sunucudaki bir şeyi değiştireceği yan etkileri olacaktır
PUT değişmez içeriği belirli bir URL'ye yerleştirmek veya değiştirmek için kullanılır
Hem REST-ful hem de REST-ful olmayan stillerdeki bir başka fark
POST İdempotent Olmayan İşlem: Aynı istekle birden çok kez çalıştırılırsa bazı değişikliklere neden olur.
PUT İdempotent İşlemidir: Aynı istekle birden çok kez yürütülürse hiçbir yan etkisi olmayacaktır.
Bu söz değer olacağını POSTbazı ortak tabidir (CSRF) saldırıları xsrf ederkenPUT değil.
Aşağıdaki CSRF kurbanı ziyaret ettiğinde mümkün değildirPUTattackersite.com .
Saldırının etkisinin olmasıdır kurban istemeden bir kullanıcı siler o (kurban) giriş yapmış oldu sırf olarak adminüzerinde target.site.com, ziyaret etmeden önceattackersite.com :
Normal istek (çerezler gönderilir): (PUT desteklenen bir özellik değeri değildir)
Kod attackersite.com:
<form id="myform" method="post" action="http://target.site.com/deleteUser" >
<input type="hidden" name="userId" value="5">
</form>
<script>document.createElement('form').submit.call(document.getElementById('myform'));</script>
XHR isteği (çerezler gönderilir): ( PUTyanıtı tarayıcının deleteUsersayfayı istemesini engelleyecek bir ön kontrol isteğini tetikler )
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);
Basit bir deyişle şunu söyleyebilirsiniz:
1.HTTP Get: Bir veya daha fazla ürün almak için kullanılır
2.HTTP Postası: Bir öğe oluşturmak için kullanılır
3.HTTP Put: Bir öğeyi güncellemek için kullanılır
4.HTTP Yaması: Bir öğeyi kısmen güncellemek için kullanılır
5.HTTP Sil: Bir öğeyi silmek için kullanılır
Aslında unvanlarından başka bir fark yok. Aslında GET ve diğerleri arasında temel bir fark var. "GET" -Request yöntemiyle, verileri önce bir soru işareti ile, sonra da & işaretiyle ayrılmış olan url-adres satırında gönderirsiniz.
Ancak bir "POST" isteği yöntemi ile verileri url'den geçiremezsiniz, ancak verileri isteğin "gövdesi" nde bir nesne olarak iletmeniz gerekir. Sunucu tarafında, gönderilen verileri almak için alınan içeriğin gövdesini okumalısınız. Ancak diğer tarafta, bir "GET" -İsteği gönderdiğinizde, vücutta içerik gönderme olanağı yoktur.
"GET" in yalnızca veri almak ve "POST" veri göndermek olduğunu iddia etmek kesinlikle yanlıştır. Hiç kimse, "GET" isteği veya "POST" isteği tarafından gönderilen verilere dayanarak yeni içerik oluşturmanızı, mevcut içeriği silmenizi, mevcut içeriği düzenlemenizi veya arka uçta herhangi bir şeyi yapmanızı engelleyemez. Ve hiç kimse, arka ucu bir "POST" -Request ile istemcinin bir miktar veri istediği şekilde kodlamanızı engelleyemez.
Bir istekle, hangi yöntemi kullanırsanız kullanın, bir URL'yi ararsınız ve belirtmek için bazı verileri gönderir veya göndermezsiniz, isteğinizle ilgilenmek için sunucuya hangi bilgileri iletmek istediğinizi ve ardından istemci sunucu. Veriler göndermek istediğiniz her şeyi içerebilir, arka ucun verilerle ne isterse yapmasına izin verilir ve yanıt oraya koymak istediğiniz herhangi bir bilgiyi içerebilir.
Sadece bu iki TEMEL YÖNTEM vardır. GET ve POST. Ama bu onların arka planında kodladığınız şeyi değil, onları farklı kılan yapılarıdır. Arka uçta, alınan verilerle istediğinizi kodlayabilirsiniz. Ancak "POST" isteğiyle, url adres satırında değil, gövdede veri göndermeniz / almanız gerekir ve "GET" isteğiyle, URL adres satırında değil, url adres satırında veri göndermeniz / almanız gerekir vücut. Bu kadar.
"PUT", "DELETE" gibi diğer tüm yöntemler "POST" ile aynı yapıya sahiptirler.
POST Yöntemi esas olarak, içeriği biraz gizlemek istiyorsanız kullanılır, çünkü url-adres satırına ne yazarsanız yazın, bu önbelleğe kaydedilir ve GET-Yöntemi verilerle bir url-adres satırı yazmakla aynıdır. Bu nedenle, her zaman kullanıcı adı ve parola olmak zorunda olmayan, ancak url-adres satırında gösterilmesini istemediğiniz bazı kimlikler veya karmalar olan hassas veriler göndermek istiyorsanız, POST yöntemini kullanmalısınız. .
Ayrıca URL-Addressline'ın uzunluğu 1024 sembolle sınırlıdır, ancak "POST" -Method kısıtlanmamıştır. Bu nedenle, daha fazla miktarda veriniz varsa, bir GET-Request ile gönderemeyebilirsiniz, ancak POST-Request'i kullanmanız gerekir. Bu da POST isteği için başka bir artı nokta.
Ancak, gönderilecek karmaşık metniniz olmadığında, GET isteğiyle uğraşmak çok daha kolaydır. Aksi takdirde, ve bu POST yöntemi için bir başka artı noktasıdır, GET yöntemiyle metin veya hatta boşluklar içinde bazı semboller gönderebilmek için metni url kodlamanız gerekir. Ancak bir POST yöntemiyle herhangi bir kısıtlamanız yoktur ve içeriğinizin herhangi bir şekilde değiştirilmesi veya manipüle edilmesi gerekmez.
Hem PUT hem de POST Dinlenme Yöntemleridir.
PUT - Aynı parametreyi iki kez PUT kullanarak aynı isteği iki kez yaparsak, ikinci isteğin herhangi bir etkisi olmaz. Bu nedenle PUT genellikle Güncelleme senaryosu için kullanılır, Güncelleme'yi aynı parametrelerle birden çok kez çağırmak, ilk çağrıdan daha fazla bir şey yapmaz, bu nedenle PUT idempotenttir.
POST idempotent değildir, örneğin Create hedefe iki ayrı girdi oluşturur, bu nedenle idempotent değildir, bu nedenle CREATE POST'ta yaygın olarak kullanılır.
Her seferinde aynı parametrelerle POST kullanarak aynı çağrıyı yapmak iki farklı şeyin gerçekleşmesine neden olur, bu nedenle POST neden Oluştur senaryosu için yaygın olarak kullanılır?