อะไรคือความแตกต่างหลักระหว่าง PATCH และ PUT


187

ฉันกำลังใช้PUTคำขอในแอปพลิเคชัน Rails ของฉัน ขณะนี้PATCHเบราว์เซอร์HTTP ใหม่ถูกใช้งานโดยเบราว์เซอร์ ดังนั้นฉันต้องการทราบความแตกต่างที่สำคัญระหว่างPATCHและPUTคำขอคืออะไรและเมื่อใดที่เราควรใช้รายการใดรายการหนึ่ง

คำตอบ:


139

HTTP verbs เป็นหนึ่งในสิ่งที่คลุมเครือที่สุดเกี่ยวกับโปรโตคอล HTTP พวกเขามีอยู่และมีหลายคน แต่ทำไมพวกเขาอยู่?

Rails ดูเหมือนว่าต้องการรองรับคำกริยาจำนวนมากและเพิ่มคำกริยาที่ไม่ได้รับการสนับสนุนจากเว็บเบราว์เซอร์

นี่คือรายการคำกริยาที่ครบถ้วนสมบูรณ์ของ http: http://annevankesteren.nl/2007/10/http-methods

มีแพทช์ HTTP จาก RFC อย่างเป็นทางการ: https://datatracker.ietf.org/doc/rfc5789/?include_text=1

PATCHคำขอวิธีการที่ชุดของการเปลี่ยนแปลงที่อธิบายไว้ในคำขอกิจการนำไปใช้กับทรัพยากรที่ระบุโดยคำขอ URI ชุดการเปลี่ยนแปลงจะแสดงในรูปแบบที่เรียกว่า "เอกสารปะ" ที่ระบุโดยประเภทสื่อ หาก Request-URI ไม่ได้ชี้ไปที่ทรัพยากรที่มีอยู่เซิร์ฟเวอร์อาจสร้างทรัพยากรใหม่ขึ้นอยู่กับประเภทของโปรแกรมแก้ไขเอกสาร (ไม่ว่าจะสามารถแก้ไขทรัพยากรที่เป็นโมฆะได้) และสิทธิ์เป็นต้น

ความแตกต่างระหว่างคำขอPUTและPATCHจะสะท้อนให้เห็นในวิธีที่เซิร์ฟเวอร์ประมวลผลเอนทิตีที่ปิดล้อมเพื่อแก้ไขทรัพยากรที่ระบุโดย Request-URI ในคำขอPUTเอนทิตีที่ปิดล้อมจะถูกพิจารณาว่าเป็นเวอร์ชันที่แก้ไขของทรัพยากรที่เก็บไว้ในเซิร์ฟเวอร์ต้นทางและไคลเอนต์ร้องขอให้แทนที่เวอร์ชันที่เก็บไว้ อย่างไรก็ตามด้วยPATCHเอนทิตีที่ถูกล้อมรอบจะมีชุดคำสั่งที่อธิบายถึงวิธีที่ทรัพยากรที่อยู่บนเซิร์ฟเวอร์ต้นทางควรได้รับการแก้ไขเพื่อสร้างเวอร์ชันใหม่ PATCH วิธีการส่งผลกระทบต่อทรัพยากรที่ระบุโดยขอ URIและมันยัง MAYมีผลข้างเคียงต่อทรัพยากรอื่น ๆ คือทรัพยากรใหม่อาจถูกสร้างขึ้นหรือคนที่มีอยู่ในการแก้ไขโดยการประยุกต์ใช้ที่PATCH

เท่าที่ฉันรู้คำกริยาPATCHไม่ได้ถูกใช้เหมือนในแอพพลิเคชั่นทางรถไฟ ... เท่าที่ฉันเข้าใจสิ่งนี้คำกริยาปะ RFC ควรใช้เพื่อส่งคำแนะนำการปะเช่นเดียวกับเมื่อคุณแตกต่างระหว่างสองไฟล์ แทนที่จะส่งเอนทิตีทั้งหมดอีกครั้งคุณส่งแพตช์ที่อาจมีขนาดเล็กกว่าส่งเอนทิตีทั้งหมด

ลองนึกภาพคุณต้องการแก้ไขไฟล์ขนาดใหญ่ คุณแก้ไข 3 บรรทัด แทนที่จะส่งไฟล์กลับคุณเพียงแค่ต้องส่งความแตกต่าง ในด้านบวกการส่งคำขอแพทช์สามารถใช้เพื่อรวมไฟล์แบบอะซิงโครนัส ระบบควบคุมเวอร์ชันอาจใช้กริยาPATCHเพื่ออัปเดตโค้ดจากระยะไกล

กรณีการใช้งานที่เป็นไปได้อีกอย่างหนึ่งนั้นค่อนข้างเกี่ยวข้องกับฐานข้อมูล NoSQL ก็เป็นไปได้ในการจัดเก็บเอกสาร สมมติว่าเราใช้โครงสร้าง JSON เพื่อส่งข้อมูลไปมาจากเซิร์ฟเวอร์ไปยังลูกค้า ถ้าเราต้องการที่จะลบข้อมูลที่เราสามารถใช้ไวยากรณ์ที่คล้ายกับใน MongoDB สำหรับ$ ล้าง ที่จริงแล้ววิธีการที่ใช้ใน mongodb เพื่ออัปเดตเอกสารอาจจะใช้ในการจัดการแพทช์ json

ยกตัวอย่างนี้:

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

เราอาจมีสิ่งนี้:

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

สุดท้าย แต่ไม่ท้ายสุดผู้คนสามารถพูดอะไรก็ได้ที่พวกเขาต้องการเกี่ยวกับคำกริยา HTTP มีเพียงความจริงเดียวเท่านั้นและความจริงนั้นอยู่ใน RFCs


1
เป็นสิ่งสำคัญที่จะต้องทราบว่า RFC 5789 ยังอยู่ในช่วงข้อเสนอและยังไม่ได้รับการยอมรับอย่างเป็นทางการและขณะนี้ถูกตั้งค่าสถานะเป็น 'irrata มีอยู่' 'แนวปฏิบัติที่ดีที่สุด' นี้ได้รับการถกเถียงกันอย่างมากและทางเทคนิค PATCH ยังไม่ได้เป็นส่วนหนึ่งของมาตรฐาน HTTP ความจริงเดียวที่นี่คือเนื่องจาก RFC ไม่ได้รับการยอมรับคุณไม่ควรทำ
fishpen0

3
แม้ว่าจะยังอยู่ในข้อเสนอ แต่ก็ไม่ได้หมายความว่าไม่ควรใช้ หากเป็นเช่นนั้นเราจะไม่สามารถใช้ websockets และ rfcs อื่น ๆ อีกมากมายที่ยังอยู่ในข้อเสนอ ... การดำเนินการตามข้อเสนอนั้นดีกว่าการใช้สิ่งที่กำหนดเองโดยสิ้นเชิง 100 เท่าซึ่งไม่มีใครใช้
Loïc Faure-Lacroix

BS ไม่ใช่ "อยู่ในข้อเสนอ" และเป็นส่วนหนึ่งของมาตรฐาน HTTP (มาตรฐานผู้แทน RFC 7231 ไปยังรีจีสตรีของ IANA สำหรับวิธีการและ PATCH อยู่ในรายการนั้น)
Julian Reschke

@JulianReschke ถ้าคุณอ่านบรรทัดที่สองของ RFC นี้คุณจะเห็นว่ามันยังคงทำเครื่องหมายว่าเป็นมาตรฐานเสนอ ดังนั้นไม่วิธีการแก้ไขยังอยู่ในข้อเสนอ rfc อยู่ที่นี่ btw tools.ietf.org/html/rfc5789และ rfc7231 ก็เป็นมาตรฐานที่เสนอเช่นกัน หากคุณดู RFC821 เป็นตัวอย่างมันถูกทำเครื่องหมายเป็นINTERNET STANDARD
Loïc Faure-Lacroix

1
@JulianReschke en.wikipedia.org/wiki/Internet_Standard#Proposed_Standard ... ไม่ใช่คำพูดของฉัน มาตรฐานที่เสนอไม่ได้หมายความว่าคุณไม่สามารถปรับใช้ได้ตามที่ฉันอธิบายไว้ข้างต้น ไม่ได้หมายความว่ามันไม่เสถียรพอที่จะใช้ ... แต่มันยังอยู่ในข้อเสนอเว้นแต่จะมีการทำเครื่องหมายเป็นมาตรฐานอินเทอร์เน็ต ... ฉันไม่แน่ใจว่าคุณโต้เถียงกับเรื่องนั้นอย่างไร มันเรียกว่า "มาตรฐานที่เสนอ" มันไม่สามารถหมายถึงสิ่งอื่นใดนอกเหนือจากข้อเสนอ หากคุณต้องการที่จะโต้แย้งว่ามาตรฐานที่นำเสนอสามารถนำมาใช้ มันเป็นสิ่งที่ฉันเขียน
Loïc Faure-Lacroix

104

ฉันใช้เวลาสองสามชั่วโมงกับ google และพบคำตอบที่นี่

PUT => หากผู้ใช้สามารถอัปเดตทั้งหมดหรือเพียงบางส่วนของบันทึกใช้ PUT (ผู้ใช้ควบคุมสิ่งที่ได้รับการปรับปรุง)

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

PATCH => หากผู้ใช้สามารถอัปเดตบางส่วนได้เพียงพูดว่าที่อยู่อีเมล (แอปพลิเคชันควบคุมสิ่งที่สามารถอัปเดตได้) ให้ใช้ PATCH

PATCH /users/123
[description of changes]

ทำไม Patch

PUTวิธีต้องการแบนด์วิดธ์มากขึ้นหรือจัดการทรัพยากรเต็มแทนบางส่วน ดังนั้นจึงPATCHแนะนำให้ลดแบนด์วิดธ์

คำอธิบายเกี่ยวกับPATCH

PATCH เป็นวิธีการที่ไม่ปลอดภัยหรือ idempotent และอนุญาตการอัปเดตทั้งหมดและบางส่วนและผลข้างเคียงต่อทรัพยากรอื่น ๆ

PATCH เป็นวิธีที่เอนทิตีที่ล้อมรอบมีชุดคำสั่งที่อธิบายถึงวิธีที่ทรัพยากรที่อยู่บนเซิร์ฟเวอร์ต้นทางควรได้รับการแก้ไขเพื่อสร้างเวอร์ชันใหม่

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

นี่คือข้อมูลเพิ่มเติมเกี่ยวกับการวางและแพทช์


7
ทำไมแพทช์นี้ไม่ปลอดภัย
Bishisht Bhatta

1
PATCHหมู่POST, PUTฯลฯ ไม่ได้เป็น "ปลอดภัย" เพราะมันปรับเปลี่ยนข้อมูลของคุณ (มีผลข้างเคียง) เมื่อเทียบกับGET, OPTIONSฯลฯ (วิธีการที่ปลอดภัย) ซึ่งคุณสามารถโทรปลายทางหลายครั้งโดยไม่มีผลข้างเคียงใด ๆ
emix

1
PATCH ไม่ได้รับการแนะนำให้รู้จักกับการประหยัดแบนด์วิดธ์เพียงอย่างเดียว ตามที่ RFC 5789 ระบุ:> "วิธีการใหม่เป็นสิ่งจำเป็นในการปรับปรุงการทำงานร่วมกันและป้องกันข้อผิดพลาด" ในสภาพแวดล้อมที่มีหลายขนานที่มีเฉพาะ PUTs ที่รวมส่วนที่เหลือของเพย์โหลดจะเพิ่มความเสี่ยงของการปรับเปลี่ยนแอตทริบิวต์อื่น ๆ ของทรัพยากร แพทช์แก้ปัญหาดังกล่าว
Tomasz Nazar

43

ใส่
ถ้าฉันต้องการเปลี่ยนfirstชื่อของฉันแล้วส่งคำขอใส่สำหรับการปรับปรุง

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

แต่ที่นี่มีปัญหาหนึ่งที่เป็นputคำขอที่เมื่อฉันต้องการที่จะส่งputคำขอฉันต้องส่งทุกสองพารามิเตอร์ที่เป็นfirstและlast
ดังนั้นมันจะบังคับให้ส่งค่าทั้งหมดอีกครั้ง

แพทช์ :
patchคำขอพูดว่า ส่งเฉพาะสิ่งdataที่คุณต้องการupdateและมันจะไม่มีผลหรือเปลี่ยนแปลงข้อมูลอื่น ๆ
ดังนั้นไม่จำเป็นต้องส่งค่าทั้งหมดอีกครั้ง แค่ฉันต้องการอัปเดตชื่อของฉันดังนั้นฉันต้องส่งเฉพาะfirstชื่อเพื่ออัปเดต


13

นี่คือความแตกต่างระหว่างวิธี POST, PUT และ PATCH ของโปรโตคอล HTTP

โพสต์

วิธี HTTP.POST สร้างทรัพยากรใหม่บนเซิร์ฟเวอร์เสมอ มันเป็นคำขอที่ไม่ใช่ idempotent เช่นถ้าผู้ใช้พบคำขอเดียวกัน 2 ครั้งมันจะสร้างทรัพยากรใหม่อีกครั้งหากไม่มีข้อ จำกัด

วิธีการโพสต์ http เป็นเหมือนคำสั่ง INSERT ใน SQL ซึ่งจะสร้างระเบียนใหม่ในฐานข้อมูลเสมอ

ตัวอย่าง: ใช้วิธี POST เพื่อบันทึกผู้ใช้ใหม่ลำดับอื่น ๆ ที่เซิร์ฟเวอร์ส่วนหลังตัดสินใจ id ทรัพยากรสำหรับทรัพยากรใหม่

PUT

ในวิธี HTTP.PUT ทรัพยากรจะถูกระบุเป็นครั้งแรกจาก URL และหากมีอยู่จะมีการอัปเดตมิฉะนั้นจะมีการสร้างทรัพยากรใหม่ เมื่อทรัพยากรเป้าหมายมีอยู่มันจะเขียนทับทรัพยากรนั้นด้วยเนื้อหาใหม่ที่สมบูรณ์ นั่นคือวิธี HTTP.PUT ใช้ในการสร้างหรือปรับปรุงทรัพยากร

วิธีการใส่ http เป็นเหมือนคำสั่ง MERGE ใน SQL ที่แทรกหรืออัพเดตเร็กคอร์ดโดยขึ้นอยู่กับว่าเร็กคอร์ดที่กำหนดนั้นมีอยู่

คำขอ PUT คือ idempotent เช่นการกดปุ่มคำขอเดิมสองครั้งจะเป็นการอัปเดตการบันทึกที่มีอยู่ (ไม่มีการสร้างบันทึกใหม่) ในวิธีการ PUT id ทรัพยากรจะถูกตัดสินใจโดยลูกค้าและให้ไว้ใน URL คำขอ

ตัวอย่าง: ใช้วิธี PUT เพื่ออัปเดตผู้ใช้หรือคำสั่งซื้อที่มีอยู่

ปะ

วิธี HTTP.PATCH ใช้สำหรับการแก้ไขบางส่วนกับทรัพยากรเช่นการปรับปรุงเดลต้า

วิธีการแก้ไขของ http เป็นเหมือนแบบสอบถามแบบ UPDATE ใน SQL ซึ่งตั้งค่าหรือปรับปรุงคอลัมน์ที่เลือกเท่านั้นและไม่ใช่ทั้งแถว

ตัวอย่าง: คุณสามารถใช้วิธี PATCH เพื่ออัปเดตสถานะการสั่งซื้อ

PATCH / api / users / 40450236 / order / 10234557

คำขอร่างกาย: {สถานะ: 'ส่งแล้ว'}


นี่คือคำอธิบายที่เลวร้ายที่สุดที่ทุกคนสามารถอ่านเกี่ยวกับการวางและการแก้ไข และนอกจากนี้หลังจากคำตอบที่ดีมากมายที่โพสต์ไปแล้วอะไรทำให้คุณคิดว่าคำตอบของคุณแตกต่างจากที่นี่
CodeHunter

3

มีข้อ จำกัด ใน PUT ผ่าน PATCH ขณะทำการอัปเดต การใช้ PUT ต้องการให้เราระบุแอตทริบิวต์ทั้งหมดแม้ว่าเราต้องการเปลี่ยนเพียงหนึ่งแอตทริบิวต์ แต่ถ้าเราใช้วิธี PATCH เราสามารถอัปเดตเฉพาะฟิลด์ที่เราต้องการและไม่จำเป็นต้องพูดถึงฟิลด์ทั้งหมด PATCH ไม่อนุญาตให้เราแก้ไขค่าในอาร์เรย์หรือลบแอตทริบิวต์หรือรายการอาร์เรย์


1

วิธี PUTและPATCHคล้ายกันในธรรมชาติ แต่มีความแตกต่างที่สำคัญ

PUT - ในคำขอPUTเอนทิตีที่ถูกปิดล้อมจะถูกพิจารณาว่าเป็นเวอร์ชันที่แก้ไขของรีซอร์สที่อยู่บนเซิร์ฟเวอร์และจะถูกแทนที่โดยเอนทิตีที่แก้ไขนี้

PATCH - ในคำร้องขอPATCHเอนทิตีที่ล้อมรอบมีชุดคำสั่งที่วิธีที่เอนทิตีที่อยู่บนเซิร์ฟเวอร์จะถูกแก้ไขเพื่อสร้างเวอร์ชันที่ใหม่กว่า


1

ตามเงื่อนไข HTTP PUTคำขอเป็นเหมือนคำสั่งการอัพเดทฐานข้อมูล PUT- ใช้สำหรับการแก้ไขทรัพยากรที่มีอยู่ (โพสต์ก่อนหน้านี้) ในทางกลับกันPATCHคำขอจะใช้เพื่ออัปเดตบางส่วนของทรัพยากรที่มีอยู่

ตัวอย่างเช่น:

รายละเอียดลูกค้า:

// This is just a example.

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

เมื่อเราต้องการอัปเดตเป็นบันทึกทั้งหมด? เราต้องใช้Http PUT verbสิ่งนั้น

เช่น:

// Customer Details Updated.

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

Http PATCH verbในทางกลับกันถ้าเราต้องการที่จะปรับปรุงเพียงแค่ส่วนหนึ่งของการบันทึกไม่บันทึกทั้งหมดไปแล้วสำหรับ เช่น:

   // Only Customer firstName and lastName is Updated.

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

PUT VS POST:

เมื่อใช้การPUTร้องขอเราจะต้องส่งพารามิเตอร์ทั้งหมดเช่นชื่อ, นามสกุล, อีเมล, หมายเลขโทรศัพท์โดยที่ในpatchคำขอจะส่งเฉพาะพารามิเตอร์ที่เราต้องการอัปเดตและจะไม่มีผลหรือเปลี่ยนแปลงข้อมูลอื่น ๆ

สำหรับรายละเอียดเพิ่มเติมกรุณาเยี่ยมชม: https://fullstack-developer.academy/restful-api-design-post-vs-put-vs-patch/


0

วิธี Put และ Patch คล้ายกัน แต่ใน Rails นั้นจะมี metod ที่แตกต่างกันถ้าเราต้องการที่จะอัพเดท / แทนที่ทั้งเร็กคอร์ดเราก็ต้องใช้วิธี Put ถ้าเราต้องการอัปเดตการบันทึกโดยใช้วิธีการแก้ไข

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.