PUT

PUT yöntemi, hedef kaynağın durumunun oluşturulmasını veya istek mesajı yükü içinde yer alan temsil tarafından tanımlanan durumla değiştirilmesini ister. Belirli bir temsilin başarılı bir PUT'u, aynı hedef kaynak üzerinde daha sonraki bir GET'in 200 (OK) yanıtında eşdeğer bir temsilin gönderilmesiyle sonuçlanacağını gösterir. Ancak, böyle bir durum değişikliğinin gözlemlenebilir olacağının garantisi yoktur, çünkü hedef kaynak paralel olarak diğer kullanıcı aracıları tarafından harekete geçirilebilir veya sonraki herhangi bir GET alınmadan önce kaynak sunucu tarafından dinamik işleme tabi tutulabilir. Başarılı bir yanıt yalnızca, kullanıcı aracısının amacının kaynak sunucu tarafından işlendiği sırada gerçekleştiği anlamına gelir.

Eğer hedef kaynağın geçerli bir temsili yoksa ve PUT başarılı bir şekilde bir temsil oluşturuyorsa, kaynak sunucu kullanıcı aracısını bir 201 (Oluşturuldu) yanıtı göndererek bilgilendirmelidir. Hedef kaynağın geçerli bir temsili varsa ve bu temsil ekteki temsilin durumuna göre başarıyla değiştirilmişse, kaynak sunucusu isteğin başarıyla tamamlandığını belirtmek için bir 200 (Tamam) veya 204 (İçerik Yok) yanıtı göndermelidir.

Kaynak sunucusu bir PUT isteğinde alınan tanınmayan başlık alanlarını yok saymalıdır (örn, kaynak durumunun bir parçası olarak kaydetmeyin).

Bir kaynak sunucu, PUT temsilinin, sunucunun PUT tarafından değiştirilemeyen veya değiştirilmeyecek olan hedef kaynak için sahip olduğu kısıtlamalarla tutarlı olduğunu doğrulamalıdır. Bu, kaynak sunucu GET yanıtlarında temsil meta verilerinin değerlerini ayarlamak için URI ile ilgili dahili yapılandırma bilgilerini kullandığında özellikle önemlidir. Bir PUT temsili hedef kaynakla tutarsız olduğunda, kaynak sunucu ya temsili dönüştürerek ya da kaynak yapılandırmasını değiştirerek bunları tutarlı hale getirmeli ya da temsilin neden uygun olmadığını açıklamak için yeterli bilgi içeren uygun bir hata mesajıyla yanıt vermelidir. 409 (Çakışma) veya 415 (Desteklenmeyen Ortam Türü) durum kodları önerilmektedir, ikincisi İçerik-Türü değerleri üzerindeki kısıtlamalara özgüdür.

Örneğin, hedef kaynak her zaman "text/html" İçerik-Türüne sahip olacak şekilde yapılandırılmışsa ve PUT edilen temsil "image/jpeg" İçerik-Türüne sahipse, kaynak sunucu aşağıdakilerden birini yapmalıdır:

• a. Hedef kaynağı yeni ortam türünü yansıtacak şekilde yeniden yapılandırmak;
• b. PUT temsilini yeni kaynak durumu olarak kaydetmeden önce kaynağınkiyle tutarlı bir biçime dönüştürmek; veya,
• c. Hedef kaynağın "text/html" ile sınırlı olduğunu belirten bir 415 (Desteklenmeyen Ortam Türü) yanıtı ile isteği reddetmek, belki de yeni temsil için uygun bir hedef olabilecek farklı bir kaynağa bir bağlantı eklemek.

HTTP, kullanıcı aracısı isteğinin amacı ve kaynak sunucu yanıtının semantiği ile ifade edilebileceklerin ötesinde, bir PUT yönteminin bir kaynak sunucunun durumunu nasıl etkilediğini tam olarak tanımlamaz. HTTP aracılığıyla sağlanan arayüzün ötesinde, bu kelimenin herhangi bir anlamında bir kaynağın ne olabileceğini tanımlamaz. Kaynak durumunun nasıl "depolandığını", kaynak durumundaki bir değişikliğin sonucu olarak bu depolamanın nasıl değişebileceğini ya da kaynak sunucusunun kaynak durumunu temsillere nasıl çevirdiğini tanımlamaz. Genel olarak, kaynak arayüzünün arkasındaki tüm uygulama ayrıntıları sunucu tarafından kasıtlı olarak gizlenir.

Bir kaynak sunucusu, isteğin temsil verileri gövdeye herhangi bir dönüşüm uygulanmadan kaydedilmedikçe (yani, kaynağın yeni temsil verileri PUT isteğinde alınan temsil verileriyle aynı olmadıkça) ve doğrulayıcı alan değeri yeni temsili yansıtmadıkça, PUT'a başarılı bir yanıtta ETag veya Son Değiştirilen alan gibi bir doğrulayıcı başlık alanı (Bölüm 7.2) GÖNDERMEMELİDİR. Bu gereklilik, kullanıcı aracısının bellekte bulunan temsil gövdesinin PUT sonucunda güncel kaldığını, dolayısıyla kaynak sunucudan tekrar alınmasına gerek olmadığını ve yanıtta alınan yeni doğrulayıcı(lar)ın yanlışlıkla üzerine yazılmasını önlemek için gelecekteki koşullu isteklerde kullanılabileceğini bilmesini sağlar (Bölüm 5.2).

POST ve PUT yöntemleri arasındaki temel fark, ekteki temsilin farklı amacı ile vurgulanır. Bir POST isteğindeki hedef kaynağın kapalı gösterimi kaynağın kendi semantiğine göre işlemesi amaçlanırken, bir PUT isteğindeki kapalı gösterim hedef kaynağın durumunun değiştirilmesi olarak tanımlanır. Bu nedenle, PUT'un amacı idempotenttir ve kesin etki yalnızca kaynak sunucu tarafından bilinse bile aracılar tarafından görülebilir.

Bir PUT isteğinin doğru yorumlanması, kullanıcı aracısının hangi hedef kaynağın istendiğini bildiğini varsayar. Durum değiştiren bir istek aldıktan sonra istemci adına uygun bir URI seçen bir hizmet, PUT yerine POST yöntemi kullanılarak uygulanmalıdır. Kaynak sunucu hedef kaynakta istenen PUT durum değişikliğini yapmayacaksa ve bunun yerine kaynağın farklı bir URI'ye taşınması gibi farklı bir kaynağa uygulanmasını istiyorsa, kaynak sunucu uygun bir 3xx (Yeniden Yönlendirme) yanıtı göndermelidir; kullanıcı aracısı daha sonra isteği yönlendirip yönlendirmeme konusunda kendi kararını verebilir.

Hedef kaynağa uygulanan bir PUT isteğinin diğer kaynaklar üzerinde yan etkileri olabilir. Örneğin, bir makale, her bir sürümü tanımlayan URI'lerden (bir noktada geçerli sürüm kaynağıyla aynı durumu paylaşan farklı kaynaklar) ayrı olan "geçerli sürümü" (bir kaynak) tanımlamak için bir URI'ye sahip olabilir. Bu nedenle, "geçerli sürüm" URI'si üzerindeki başarılı bir PUT isteği, hedef kaynağın durumunu değiştirmenin yanı sıra yeni bir sürüm kaynağı oluşturabilir ve ayrıca ilgili kaynaklar arasında bağlantıların eklenmesine neden olabilir.

Belirli bir hedef kaynak üzerinde PUT'a izin veren bir kaynak sunucusu, İçerik-Aralığı başlık alanı içeren bir PUT isteğine 400 (Kötü İstek) yanıtı göndermelidir ([RFC7233] Bölüm 4.2), çünkü yükün yanlışlıkla tam bir temsil olarak PUT edilmiş kısmi içerik olması muhtemeldir. Kısmi içerik güncellemeleri, daha büyük kaynağın bir kısmıyla örtüşen duruma sahip ayrı olarak tanımlanmış bir kaynağı hedefleyerek veya kısmi güncellemeler için özel olarak tanımlanmış farklı bir yöntem kullanarak mümkündür (örneğin, [RFC5789]'da tanımlanan PATCH yöntemi).

PUT yöntemine verilen yanıtlar önbelleğe alınamaz. Başarılı bir PUT isteği, etkin istek URI'si için bir veya daha fazla saklanmış yanıtı olan bir önbellekten geçerse, bu saklanmış yanıtlar geçersiz kılınacaktır (bkz. [RFC7234] Bölüm 4.4).