Apa perbedaan utama antara permintaan PATCH dan PUT?


187

Saya menggunakan PUTpermintaan dalam aplikasi Rails saya. Sekarang, kata kerja HTTP baru, PATCHtelah diterapkan oleh browser. Jadi, saya ingin tahu apa perbedaan utama antara PATCHdan PUTpermintaan, dan kapan kita harus menggunakan satu atau yang lain.

Jawaban:


139

Kata kerja HTTP mungkin salah satu hal yang paling samar tentang protokol HTTP. Mereka ada, dan ada banyak dari mereka, tetapi mengapa mereka ada?

Rails tampaknya ingin mendukung banyak kata kerja dan menambahkan beberapa kata kerja yang tidak didukung oleh browser web.

Berikut daftar lengkap kata kerja http: http://annevankesteren.nl/2007/10/http-methods

Ada tambalan HTTP dari RFC resmi: https://datatracker.ietf.org/doc/rfc5789/?include_text=1

The PATCH metode permintaan yang set perubahan yang dijelaskan dalam entitas permintaan diterapkan pada sumber daya diidentifikasi oleh Permintaan-URI. Set perubahan diwakili dalam format yang disebut "dokumen tambalan" yang diidentifikasi oleh jenis media. Jika Request-URI tidak menunjuk ke sumber daya yang ada, server MUNGKIN membuat sumber daya baru, tergantung pada jenis dokumen tambalan (apakah secara logis dapat mengubah sumber daya nol) dan izin, dll.

Perbedaan antara permintaan PUT dan PATCH tercermin dalam cara server memproses entitas terlampir untuk memodifikasi sumber daya yang diidentifikasi oleh Request-URI. Dalam permintaan PUT , entitas terlampir dianggap sebagai versi modifikasi dari sumber daya yang disimpan di server asal, dan klien meminta agar versi yang disimpan diganti. Dengan PATCH , bagaimanapun, entitas terlampir berisi serangkaian instruksi yang menggambarkan bagaimana sumber daya yang saat ini berada di server asal harus dimodifikasi untuk menghasilkan versi baru. The PATCH metode mempengaruhi sumber daya diidentifikasi oleh Request-URI , dan juga MEImemiliki efek samping pada sumber daya lain; yaitu, sumber daya baru dapat dibuat, atau yang sudah ada dimodifikasi, oleh aplikasi PATCH .

Sejauh yang saya tahu, kata kerja PATCH tidak digunakan karena dalam aplikasi rails ... Seperti yang saya pahami, kata kerja patch RFC harus digunakan untuk mengirim instruksi patch seperti ketika Anda melakukan perbedaan antara dua file. Alih-alih mengirim seluruh entitas lagi, Anda mengirim patch yang bisa jauh lebih kecil daripada mengirim ulang seluruh entitas.

Bayangkan Anda ingin mengedit file besar. Anda mengedit 3 baris. Alih-alih mengirim file kembali, Anda hanya perlu mengirim diff. Di sisi positifnya, mengirim permintaan tambalan dapat digunakan untuk menggabungkan file secara tidak sinkron. Sistem kontrol versi berpotensi menggunakan kata kerja PATCH untuk memperbarui kode dari jarak jauh.

Satu kemungkinan penggunaan lainnya agak terkait dengan database NoSQL, dimungkinkan untuk menyimpan dokumen. Katakanlah kita menggunakan struktur JSON untuk mengirim dan mengirim data dari server ke klien. Jika kami ingin menghapus suatu bidang, kami dapat menggunakan sintaksis yang mirip dengan yang ada di mongodb untuk $ unset . Sebenarnya, metode yang digunakan dalam mongodb untuk memperbarui dokumen mungkin dapat digunakan untuk menangani patch json.

Ambil contoh ini:

db.products.update(
   { sku: "unknown" },
   { $unset: { quantity: "", instock: "" } }
)

Kita dapat memiliki sesuatu seperti ini:

PATCH /products?sku=unknown
{ "$unset": { "quantity": "", "instock": "" } }

Terakhir, tetapi tidak sedikit, orang dapat mengatakan apa pun yang mereka inginkan tentang kata kerja HTTP. Hanya ada satu kebenaran, dan kebenaran ada di RFC.


1
Penting untuk dicatat bahwa RFC 5789 masih dalam tahap proposal dan belum secara resmi diterima dan saat ini ditandai sebagai 'irrata exist'. 'Praktik terbaik' ini sangat diperdebatkan dan secara teknis PATCH belum menjadi bagian dari standar HTTP. Satu-satunya kebenaran di sini adalah karena RFC tidak dapat diterima, Anda tidak boleh melakukannya.
fishpen0

3
Bahkan jika itu masih dalam proposal, itu tidak berarti itu tidak boleh digunakan. Jika demikian, kami tidak akan dapat menggunakan soket web dan banyak rfcs lainnya yang masih dalam proposal ... Menerapkan proposal 100 kali lebih baik daripada menerapkan sesuatu yang sepenuhnya kebiasaan yang tidak diterapkan oleh orang lain.
Loïc Faure-Lacroix

BS. Ini bukan "dalam proposal", dan itu adalah bagian dari standar HTTP (standar, RFC 7231 delegasi ke registri IANA untuk metode, dan PATCH terdaftar di sana).
Julian Reschke

@JulianReschke jika Anda membaca baris kedua RFC ini, Anda akan melihat bahwa itu masih ditandai sebagai STANDAR YANG DIUSULKAN . Jadi tidak, metode tambalan masih dalam proposal. Rfc ada di sini btw. tools.ietf.org/html/rfc5789 dan rfc7231 juga DIUSULKAN STANDAR . Jika Anda melihat RFC821 misalnya, itu ditandai sebagai INTERNET STANDAR
Loïc Faure-Lacroix

1
@JulianReschke en.wikipedia.org/wiki/Internet_Standard#Proposed_Standard ... Itu bukan kata-kata saya. Usulan standar tidak berarti Anda tidak dapat mengimplementasikannya dengan baik seperti yang saya jelaskan di atas. Itu tidak berarti bahwa itu tidak cukup stabil untuk diterapkan ... tetapi masih dalam proposal kecuali itu ditandai sebagai Standar Internet ... Saya tidak yakin bagaimana Anda memperdebatkan itu. Ini disebut "standar yang diusulkan" itu tidak bisa berarti apa pun selain proposal. Jika Anda ingin berdebat bahwa standar yang diusulkan dapat digunakan. Persis seperti yang saya tulis.
Loïc Faure-Lacroix

104

Saya menghabiskan beberapa jam dengan google dan menemukan jawabannya di sini

PUT => Jika pengguna dapat memperbarui semua atau hanya sebagian dari catatan , gunakan PUT (pengguna mengontrol apa yang diperbarui)

PUT /users/123/email
new.email@example.org

PATCH => Jika pengguna hanya dapat memperbarui sebagian catatan , ucapkan hanya alamat email (aplikasi mengontrol apa yang dapat diperbarui), gunakan PATCH.

PATCH /users/123
[description of changes]

Mengapa Patch

PUTMetode membutuhkan lebih banyak bandwidth atau menangani sumber daya penuh sebagai gantinya secara parsial. Jadi PATCHdiperkenalkan untuk mengurangi bandwidth.

Penjelasan tentang PATCH

PATCH adalah metode yang tidak aman, atau idempoten, dan memungkinkan pembaruan penuh dan sebagian dan efek samping pada sumber daya lainnya.

PATCH adalah metode yang entitas terlampir berisi serangkaian instruksi yang menggambarkan bagaimana sumber daya yang saat ini berada di server asal harus dimodifikasi untuk menghasilkan versi baru.

PATCH /users/123
[
  { "op": "replace", "path": "/email", "value": "new.email@example.org" }
]

Di sini, informasi lebih lanjut tentang put and patch


7
Mengapa PATCH ini tidak aman?
Bishisht Bhatta

1
PATCHdi antara POST, PUTdll tidak "aman", karena memodifikasi data Anda (memiliki efek samping). Dibandingkan dengan GET, OPTIONSdll. (Metode aman) tempat Anda dapat memanggil titik akhir beberapa kali tanpa efek samping.
emix

1
PATCH TIDAK diperkenalkan hanya untuk menyelamatkan bandwidth. Seperti yang dinyatakan RFC 5789:> "Metode baru diperlukan untuk meningkatkan interoperabilitas dan mencegah kesalahan." Dalam lingkungan multi paralel yang hanya memiliki PUT yang mencakup sisa muatan akan meningkatkan risiko modifikasi atribut lain dari sumber daya. PATCH memecahkan masalah seperti itu.
Tomasz Nazar

43

put
jika saya ingin mengubah firstnama saya kemudian kirim permintaan put untuk Pembaruan

{ "first": "Nazmul", "last": "hasan" } 

tapi di sini ada satu masalah yaitu putpermintaan bahwa ketika saya ingin mengirim putpermintaan saya harus mengirim semua dua parameter itu firstdan last
jadi wajib untuk mengirim semua nilai lagi

patch :
patchrequest said. hanya mengirim yang datamana yang Anda inginkan updatedan itu tidak akan mempengaruhi atau mengubah data lainnya.
jadi tidak perlu mengirim semua nilai lagi. hanya saya ingin memperbarui nama depan saya jadi saya hanya perlu mengirim firstnama untuk memperbarui.


13

Berikut adalah perbedaan antara metode POST, PUT dan PATCH dari protokol HTTP.

POS

Metode HTTP.POST selalu membuat sumber daya baru di server. Ini permintaan non-idempoten yaitu jika pengguna memukul permintaan yang sama 2 kali itu akan membuat sumber daya baru jika tidak ada kendala.

Metode posting http seperti query INSERT dalam SQL yang selalu membuat catatan baru dalam database.

Contoh: Gunakan metode POST untuk menyimpan pengguna baru, memesan dll di mana server backend menentukan id sumber daya untuk sumber daya baru.

TARUH

Dalam metode HTTP.PUT sumber daya pertama kali diidentifikasi dari URL dan jika ada maka diperbarui jika tidak, sumber daya baru dibuat. Ketika sumber daya target ada itu menimpa sumber daya itu dengan badan baru yang lengkap. Itu adalah metode HTTP.PUT digunakan untuk MENCIPTAKAN atau memperbarui sumber daya.

Metode http put seperti query MERGE dalam SQL yang menyisipkan atau memperbarui catatan tergantung pada apakah catatan yang diberikan ada.

Permintaan PUT idempoten yaitu dengan menekan permintaan yang sama dua kali akan memperbarui rekaman yang ada (Tidak ada catatan baru yang dibuat). Dalam metode PUT, id sumber daya ditentukan oleh klien dan disediakan di url permintaan.

Contoh: Gunakan metode PUT untuk memperbarui pengguna atau pesanan yang ada.

PATCH

Metode HTTP.PATCH digunakan untuk modifikasi parsial ke sumber daya yaitu pembaruan delta.

Metode patch http seperti kueri UPDATE dalam SQL yang menetapkan atau memperbarui kolom yang dipilih saja dan bukan seluruh baris.

Contoh: Anda dapat menggunakan metode PATCH untuk memperbarui status pesanan.

PATCH / api / users / 40450236 / order / 10234557

Badan Permintaan: {status: 'Disampaikan'}


Ini adalah penjelasan terburuk yang bisa dibaca siapa pun tentang put and patch. Dan selain itu, setelah begitu banyak jawaban bagus yang diposting, apa yang membuat Anda berpikir jawaban Anda berbeda di sini?
CodeHunter

3

Ada batasan dalam PUT lebih dari PATCH saat melakukan pembaruan. Menggunakan PUT mengharuskan kita untuk menentukan semua atribut bahkan jika kita ingin mengubah hanya satu atribut. Tetapi jika kita menggunakan metode PATCH kita hanya dapat memperbarui bidang yang kita butuhkan dan tidak perlu menyebutkan semua bidang. PATCH tidak memungkinkan kami untuk mengubah nilai dalam array, atau menghapus atribut atau entri array.


1

Metode PUT dan PATCH pada dasarnya serupa, tetapi ada perbedaan utama.

PUT - dalam permintaan PUT , entitas yang terlampir akan dianggap sebagai versi sumber daya yang dimodifikasi yang berada di server dan akan diganti oleh entitas yang dimodifikasi ini.

PATCH - dalam permintaan PATCH , entitas terlampir berisi sekumpulan instruksi bahwa bagaimana entitas yang berada di server, akan dimodifikasi untuk menghasilkan versi yang lebih baru.


1

Menurut ketentuan HTTP, PUTPermintaan hanya seperti pernyataan pembaruan basis data. PUT- digunakan untuk memodifikasi sumber daya yang ada (Sebelumnya POSTED). Di sisi lain PATCHpermintaan digunakan untuk memperbarui sebagian dari sumber daya yang ada.

Sebagai contoh:

Detil pelanggan:

// This is just a example.

firstName = "James";
lastName = "Anderson";
email = "email@domain.com";
phoneNumber = "+92 1234567890";
//..

Kapan kami ingin memperbarui ke seluruh catatan? kita harus gunakan Http PUT verbuntuk itu.

seperti:

// Customer Details Updated.

firstName = "James++++";
lastName = "Anderson++++";
email = "email@Updated.com";
phoneNumber = "+92 0987654321";
//..

Di sisi lain, jika kita hanya ingin memperbarui bagian dari catatan, tidak seluruh catatan kemudian pergi untuk Http PATCH verb. seperti:

   // Only Customer firstName and lastName is Updated.

    firstName = "Updated FirstName";
    lastName = "Updated LastName";
   //..

PUT VS POST:

Saat menggunakan PUTpermintaan, kami harus mengirim semua parameter seperti firstName, lastName, email, phoneNumber Where in In patchrequest hanya mengirim parameter mana yang ingin kami perbarui dan tidak akan memengaruhi atau mengubah data lainnya.

Untuk detail lebih lanjut silakan kunjungi: https://fullstack-developer.academy/restful-api-design-post-vs-put-vs-patch/


0

Metode Put and Patch serupa. Tetapi dalam rel memiliki metod yang berbeda. Jika kita ingin memperbarui / mengganti seluruh record maka kita harus menggunakan metode Put. Jika kami ingin memperbarui catatan tertentu, gunakan metode Patch.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.