PUT

Metode PUT meminta agar status sumber daya target dibuat atau diganti dengan status yang ditentukan oleh representasi yang dilampirkan dalam muatan pesan permintaan. PUT yang berhasil pada representasi yang diberikan akan menunjukkan bahwa GET berikutnya pada sumber daya target yang sama akan menghasilkan representasi yang setara yang dikirim dalam respons 200 (OK). Namun, tidak ada jaminan bahwa perubahan status seperti itu akan dapat diamati, karena sumber daya target mungkin ditindaklanjuti oleh agen pengguna lain secara paralel, atau mungkin tunduk pada pemrosesan dinamis oleh server asal, sebelum GET berikutnya diterima. Respons yang berhasil hanya menyiratkan bahwa maksud agen pengguna tercapai pada saat pemrosesan oleh server asal.

Jika sumber daya target tidak memiliki representasi saat ini dan PUT berhasil membuatnya, maka server asal HARUS memberi tahu agen pengguna dengan mengirimkan respons 201 (Created). Jika sumber daya target memiliki representasi saat ini dan representasi tersebut berhasil dimodifikasi sesuai dengan status representasi yang dilampirkan, maka server asal HARUS mengirimkan respons 200 (OK) atau 204 (Tidak Ada Konten) untuk mengindikasikan penyelesaian permintaan yang berhasil dilakukan.

Server asal HARUS mengabaikan bidang tajuk yang tidak dikenal yang diterima dalam permintaan PUT (mis, tidak menyimpannya sebagai bagian dari status sumber daya).

Sebuah server asal HARUS memverifikasi bahwa representasi PUT konsisten dengan batasan apa pun yang dimiliki server untuk sumber daya target yang tidak dapat atau tidak akan diubah oleh PUT. Hal ini sangat penting ketika server asal menggunakan informasi konfigurasi internal yang terkait dengan URI untuk menetapkan nilai metadata representasi pada respons GET. Ketika representasi PUT tidak konsisten dengan sumber daya target, server asal HARUS membuatnya konsisten, dengan mengubah representasi atau mengubah konfigurasi sumber daya, atau merespons dengan pesan kesalahan yang sesuai yang berisi informasi yang cukup untuk menjelaskan mengapa representasi tersebut tidak sesuai. Kode status 409 (Konflik) atau 415 (Jenis Media Tidak Didukung) disarankan, dengan kode status yang terakhir ini khusus untuk batasan nilai Jenis Konten.

Misalnya, jika sumber daya target dikonfigurasikan untuk selalu memiliki Jenis Konten "teks/html" dan representasi yang sedang di-PUT memiliki Jenis Konten "gambar/jpeg", server asal harus melakukan salah satu dari:

a. mengkonfigurasi ulang sumber daya target untuk mencerminkan jenis media yang baru;

HTTP tidak mendefinisikan secara tepat bagaimana metode PUT memengaruhi status server asal di luar apa yang dapat diungkapkan oleh maksud permintaan agen pengguna dan semantik respons server asal. HTTP tidak mendefinisikan apa yang dimaksud dengan sumber daya, dalam arti apa pun, di luar antarmuka yang disediakan melalui HTTP. Ini tidak mendefinisikan bagaimana status sumber daya "disimpan", atau bagaimana penyimpanan tersebut dapat berubah sebagai akibat dari perubahan status sumber daya, atau bagaimana server asal menerjemahkan status sumber daya ke dalam representasi. Secara umum, semua detail implementasi di balik antarmuka sumber daya disembunyikan secara sengaja oleh server.

Server asal TIDAK BOLEH mengirim bidang header validator (Bagian 7.2), seperti bidang ETag atau Last-Modified, dalam respons yang berhasil terhadap PUT kecuali data representasi permintaan disimpan tanpa transformasi apa pun yang diterapkan pada tubuh (yaitu, data representasi baru sumber daya identik dengan data representasi yang diterima dalam permintaan PUT) dan nilai bidang validator mencerminkan representasi baru. Persyaratan ini memungkinkan agen pengguna untuk mengetahui kapan badan representasi yang dimilikinya dalam memori tetap ada sebagai hasil dari PUT, sehingga tidak perlu diambil lagi dari server asal, dan bahwa validator baru yang diterima dalam respons dapat digunakan untuk permintaan bersyarat di masa mendatang untuk mencegah penimpaan yang tidak disengaja (Bagian 5.2). Sumber daya target dalam permintaan POST dimaksudkan untuk menangani representasi yang di-enclave sesuai dengan semantik sumber daya itu sendiri, sedangkan representasi yang di-enclave dalam permintaan PUT didefinisikan sebagai penggantian status sumber daya target. Oleh karena itu, maksud dari PUT adalah tidak berdaya dan dapat dilihat oleh perantara, meskipun efek yang tepat hanya diketahui oleh server asal.

Interpretasi yang tepat dari permintaan PUT mengasumsikan bahwa agen pengguna mengetahui sumber daya target mana yang diinginkan. Sebuah layanan yang memilih URI yang tepat atas nama klien, setelah menerima permintaan pengubahan status, HARUS diimplementasikan dengan menggunakan metode POST, bukan PUT. Jika server asal tidak akan membuat perubahan status PUT yang diminta ke sumber daya target dan sebaliknya ingin menerapkannya ke sumber daya yang berbeda, seperti ketika sumber daya telah dipindahkan ke URI yang berbeda, maka server asal HARUS mengirimkan respons 3xx (Pengalihan) yang sesuai; agen pengguna MUNGKIN membuat keputusan sendiri mengenai apakah akan mengalihkan permintaan tersebut atau tidak. Sebagai contoh, sebuah artikel mungkin memiliki URI untuk mengidentifikasi "versi saat ini" (sumber daya) yang terpisah dari URI yang mengidentifikasi setiap versi tertentu (sumber daya yang berbeda yang pada suatu saat memiliki status yang sama dengan sumber daya versi saat ini). Permintaan PUT yang berhasil pada URI "versi saat ini" dapat membuat sumber daya versi baru selain mengubah status sumber daya target, dan juga dapat menyebabkan tautan ditambahkan di antara sumber daya terkait.

Sebuah server asal yang mengizinkan PUT pada sumber daya target yang diberikan HARUS mengirimkan respons 400 (Permintaan Buruk) ke permintaan PUT yang berisi bidang header Content-Range (Bagian 4.2 dari [RFC7233]), karena muatannya kemungkinan besar adalah konten parsial yang telah salah PUT sebagai representasi penuh. Pembaruan konten parsial dapat dilakukan dengan menargetkan sumber daya yang diidentifikasi secara terpisah dengan status yang tumpang tindih dengan sebagian sumber daya yang lebih besar, atau dengan menggunakan metode berbeda yang telah didefinisikan secara khusus untuk pembaruan parsial (misalnya, metode PATCH yang didefinisikan dalam [RFC5789]).

Respons terhadap metode PUT tidak dapat di-cache. Jika permintaan PUT yang berhasil melewati cache yang memiliki satu atau lebih respons yang tersimpan untuk URI permintaan yang efektif, respons yang tersimpan tersebut akan dibatalkan (lihat Bagian 4.4 dari [RFC7234]).