ในการออกแบบ RESTful API นั้น PUT และ PATCH เป็นสองวิธี HTTP ที่ใช้ในการอัปเดตทรัพยากรบนเซิร์ฟเวอร์ แต่ความแตกต่างระหว่าง PUT กับ PATCH ใน REST API อยู่ที่วิธีการอัปเดตและสถานการณ์ที่เหมาะสมที่สุด ทั้งสองวิธีได้รับการออกแบบมาเพื่อแก้ไขข้อมูลที่มีอยู่ แต่การทำความเข้าใจความแตกต่างของ PUT และ PATCH ใน REST API สามารถช่วยให้นักพัฒนาตัดสินใจเลือกได้ดีที่สุดโดยอิงตามลักษณะของการอัปเดตที่พวกเขาจำเป็นต้องดำเนินการ ในบล็อกโพสต์นี้ เราจะสำรวจความแตกต่างระหว่าง PUT และ PATCH ใน REST API โดยมุ่งเน้นไปที่การอภิปรายระหว่าง PATCH และ REST ที่อัปเดต ว่าควรใช้แต่ละข้อเมื่อใด และให้คำแนะนำในการเลือกวิธีการที่เหมาะสมสำหรับกรณีการใช้งานที่แตกต่างกัน
PUT ใน REST API คืออะไร
เพื่อทำความเข้าใจความแตกต่างระหว่าง PUT และ PATCH ใน REST API ก่อนอื่นเราจะต้องรู้ว่า PUT คืออะไร ขึ้นอยู่กับ มาตรา 9.6 RFC 2616วิธี PUT ใน REST API ร้องขอให้จัดเก็บเอนทิตีที่แนบมาภายใต้ Request-URI ที่ให้มา
หาก Request-URI อ้างถึงทรัพยากรที่มีอยู่แล้ว เอนทิตีที่ล้อมรอบควรได้รับการพิจารณาว่าเป็นเวอร์ชันที่ได้รับการแก้ไขของเอนทิตีที่อยู่ในเซิร์ฟเวอร์ต้นทาง หาก Request-URI ไม่ได้ชี้ไปที่ทรัพยากรที่มีอยู่และ URI นั้นสามารถถูกกำหนดเป็นทรัพยากรใหม่โดยตัวแทนผู้ใช้ที่ร้องขอ เซิร์ฟเวอร์ต้นทางจะสามารถสร้างทรัพยากรด้วย URI นั้นได้
กล่าวอีกนัยหนึ่ง วิธี PUT ใช้เพื่ออัปเดตทรัพยากรทั้งหมดบนเซิร์ฟเวอร์ สิ่งนี้ทำให้ PUT เป็นการอัปเดตที่ "สมบูรณ์" มากขึ้น ซึ่งมักใช้เมื่อจำเป็นต้องเปลี่ยนทรัพยากรโดยสมบูรณ์
ดังนั้น PUT จึงเหมาะที่สุดสำหรับกรณีการใช้งานต่อไปนี้:
- การอัปเดตทรัพยากรที่สมบูรณ์ (เช่น การอัปเดตโปรไฟล์ผู้ใช้ด้วยข้อมูลใหม่ทั้งหมด)
- การแทนที่รายการหรือบันทึกทั้งหมด
- เมื่อข้อมูลระบุตัวตนของทรัพยากรชัดเจน และข้อมูลของทรัพยากรจำเป็นต้องได้รับการรีเฟรชอย่างสมบูรณ์
ในระบบเช่น การค้นหาแบบยืดหยุ่นการดำเนินการแบบ idempotent เป็นสิ่งจำเป็นเพื่อรับประกันความสอดคล้องของข้อมูล ตัวอย่างเช่น การอัปเดตเอกสารใน Elasticsearch โดยใช้ PUT ช่วยให้มั่นใจได้ว่าคำขอเดียวกันสามารถทำซ้ำได้โดยไม่มีผลข้างเคียงที่ไม่ได้ตั้งใจ
PATCH ใน REST API คืออะไร
ตอนนี้เราได้พูดถึง PUT ใน REST API แล้ว เรามาดูกันว่า PATCH คืออะไรใน REST API และมันทำงานอย่างไร ก่อนที่เราจะเปรียบเทียบ PUT กับ PATCH ใน REST API ตามที่กำหนดไว้ใน อาร์เอฟซี 5789เมธอด PATCH ใน REST API ร้องขอให้นำชุดการเปลี่ยนแปลงที่อธิบายไว้ในเอนทิตีคำขอไปใช้กับทรัพยากรที่ระบุโดย Request-URI
สิ่งนี้สอดคล้องกับความแตกต่างของ PUT และ PATCH REST API โดยที่คุณส่งข้อมูลที่จำเป็นต้องแก้ไขเท่านั้น และเซิร์ฟเวอร์จะนำการเปลี่ยนแปลงเหล่านั้นไปใช้กับทรัพยากรที่มีอยู่โดยไม่ต้องแก้ไขทรัพยากรทั้งหมด นักพัฒนามักจะสร้างแพตช์เพื่อแสดงการเปลี่ยนแปลงที่เพิ่มขึ้นเหล่านี้ เพื่อให้มั่นใจว่ามีการถ่ายโอนข้อมูลน้อยที่สุดและการอัปเดตที่มีประสิทธิภาพ
นั่นเป็นเหตุผลว่าทำไมวิธี PATCH ใน REST API จึงเหมาะสมกับกรณีการใช้งานต่อไปนี้มากกว่า:
- การอัปเดตเฉพาะช่องย่อยในทรัพยากร (เช่น การเปลี่ยนที่อยู่อีเมลหรือหมายเลขโทรศัพท์ของผู้ใช้) ตัวอย่าง PATCH API อาจเกี่ยวข้องกับการส่งอีเมลใหม่ โดยไม่แตะต้องช่องอื่นๆ
- การปรับปรุงประสิทธิภาพโดยการลดเพย์โหลดข้อมูลให้เหลือน้อยที่สุด
- เมื่อคุณต้องการอัพเดตทรัพยากรทีละน้อย แทนที่จะแทนที่ทั้งหมด
- สร้างแพตช์เพื่อสรุปการเปลี่ยนแปลงในช่องเฉพาะ เช่น การแก้ไขอีเมลของผู้ใช้ โดยไม่ส่งผลกระทบต่อข้อมูลที่ไม่เกี่ยวข้อง
สำหรับแพลตฟอร์มเช่น CMS ไร้หัว ที่มักจะจัดการโครงสร้างเนื้อหาที่ซับซ้อน การใช้ PATCH สำหรับการอัพเดตขนาดเล็ก เช่น การแก้ไขฟิลด์เดียว สามารถลดภาระของเซิร์ฟเวอร์และปรับปรุงประสิทธิภาพได้
เมื่อครอบคลุมทั้งสองวิธีนี้แล้ว คุณควรมีความคิดที่ดีว่า PUT และ PATCH คืออะไรใน REST API อย่างไรก็ตาม ก่อนที่เราจะพูดถึงความแตกต่างระหว่าง PUT กับ PATCH ใน REST API เราจำเป็นต้องพูดถึง Idempotence ในสองวิธีนี้ก่อน
Idempotence ใน PUT Vs Patch ใน REST API
ใน REST APIs idempotence หมายถึงคุณสมบัติของการดำเนินการที่เมื่อทำซ้ำหลายครั้งด้วยอินพุตเดียวกัน จะให้ผลลัพธ์เดียวกัน ซึ่งหมายความว่าการร้องขอเดียวกันหลายครั้งควรมีผลเช่นเดียวกันบนเซิร์ฟเวอร์ ไม่ว่าจะดำเนินการกี่ครั้งก็ตาม นี่เป็นสิ่งสำคัญในการรับรองความเสถียรและความสามารถในการคาดการณ์ใน API แต่มันเกี่ยวข้องกับความแตกต่างของ PUT และ PATCH ใน REST API อย่างไร
วิธี PUT และ Idempotence
วิธี PUT ใน REST API เป็นแบบ idempotent เสมอ เนื่องจากได้รับการออกแบบมาเพื่อแทนที่ทรัพยากรทั้งหมดที่ URI ที่ระบุด้วยข้อมูลที่ให้ไว้ในคำขอ กล่าวอีกนัยหนึ่ง หากคุณดำเนินการคำขอ PUT หลายครั้งด้วยข้อมูลทรัพยากรเดียวกัน ผลลัพธ์จะเหมือนเดิมเสมอ
เหตุใด PUT Idempotent จึงเป็นเช่นนั้น เมื่อคุณส่งคำขอ PUT คุณกำลังบอกเซิร์ฟเวอร์ว่า "นี่คือสถานะที่สมบูรณ์และตรงตามที่ฉันต้องการสำหรับทรัพยากรนี้" ไม่ว่าคุณจะออกคำขอ PUT หนึ่งครั้งหรือหลายครั้ง ทรัพยากรผลลัพธ์จะเหมือนกันเสมอ
เช่น พิจารณาสถานการณ์ที่คุณอัปเดตที่อยู่อีเมลของผู้ใช้ หากคุณส่งคำขอ PUT เดียวกันหลายครั้ง ผลลัพธ์จะไม่ถูกเปลี่ยนแปลงเนื่องจากทรัพยากรจะถูกแทนที่ด้วยข้อมูลเดียวกันทุกครั้ง
ตัวอย่าง:
| PUT /users/1{“ชื่อผู้ใช้”: “john_doe”,”อีเมล”: “[email protected]”} |
หากคุณส่งคำขอนี้หลายครั้ง ผลลัพธ์จะเหมือนเดิมเสมอ:
| {“ชื่อผู้ใช้”: “john_doe”,”อีเมล”: “[email protected]”} |
แม้ว่าข้อมูลของผู้ใช้จะเป็นเช่นนี้แล้ว การส่งคำขออีกครั้งจะไม่เปลี่ยนแปลงอะไรเลย โดยจะแทนที่ข้อมูลด้วยข้อมูลเดียวกัน ดังนั้นผลของคำขอจึงยังคงเหมือนเดิมไม่ว่าจะทำซ้ำกี่ครั้งก็ตาม นี่คือสิ่งที่ทำให้ PUT idempotent
วิธี PATCH และ Idempotence
ในทางกลับกัน เมธอด PATCH ใน REST API นั้นโดยทั่วไปแล้วจะเป็นแบบ idempotent เช่นกัน แต่มีความยืดหยุ่นมากกว่า เมื่อคุณสร้างแพตช์ ตรวจสอบให้แน่ใจว่าการดำเนินการเป็นแบบเดิม (เช่น การตั้งค่า) เพื่อหลีกเลี่ยงผลข้างเคียงที่ไม่ได้ตั้งใจจากคำขอซ้ำๆ ไม่ว่า PATCH จะเป็น idempotent หรือไม่นั้นขึ้นอยู่กับการดำเนินการและข้อมูลที่กำลังแก้ไข
ทำไม PATCH ถึงเป็น Idempotent? สำหรับคำขอ PATCH idempotence หมายความว่าการใช้แพตช์เดียวกันหลายครั้งจะได้ผลลัพธ์ที่เหมือนกัน สิ่งนี้จะเกิดขึ้นจริงตราบใดที่ตัวแพทช์ไม่ก่อให้เกิดผลข้างเคียงหรือการเปลี่ยนแปลงเพิ่มเติมเมื่อใช้ซ้ำ ๆ หากคุณใช้แพตช์เดิมกับข้อมูลเดิม ผลลัพธ์จะไม่เปลี่ยนแปลงหลังจากแอปพลิเคชันครั้งแรก
ตัวอย่างเช่น หากคุณเพียงอัปเดตอีเมลของผู้ใช้ การส่งคำขอ PATCH เดิมซ้ำๆ จะไม่เปลี่ยนแปลงผลลัพธ์หลังจากครั้งแรก แม้ว่าจะมีการส่งคำขอหลายครั้งก็ตาม อีเมลของผู้ใช้จะยังคงเหมือนเดิม และสถานะของทรัพยากรจะไม่เปลี่ยนแปลง
ตัวอย่าง PATCH API:
| PATCH /users/1{“อีเมล”: “[email protected]”} |
หากอีเมลเป็น [email protected] อยู่แล้ว การใช้ PATCH นี้อีกครั้งจะไม่ทำให้เกิดการเปลี่ยนแปลง ทำให้เป็น idempotent
อย่างไรก็ตาม PATCH อาจไม่ใช่ idempotent ได้ในบางกรณี ตัวอย่างเช่น หากการดำเนินการ PATCH แก้ไขตัวนับหรือเพิ่มรายการลงในรายการ (เช่น การเพิ่มตัวเลขหรือการผนวกเข้ากับอาร์เรย์) การใช้ PATCH เดียวกันซ้ำ ๆ อาจนำไปสู่ผลลัพธ์ที่ต่างกัน สิ่งนี้จะละเมิดคุณสมบัติ idempotence
ตัวอย่าง PATCH API ที่ไม่ใช่ idempotent:
| PATCH /counter/1{“เพิ่มขึ้น”: 1} |
หากคุณใช้ PATCH นี้ซ้ำๆ ตัวนับจะเพิ่มขึ้นเรื่อยๆ ส่งผลให้ค่าต่างๆ แตกต่างกันทุกครั้ง สิ่งนี้ไม่ใช่ idempotent เนื่องจากผลลัพธ์จะเปลี่ยนแปลงไปตามแต่ละแอปพลิเคชัน
เมื่อคุณทราบถึงสิ่งสำคัญแล้ว เรามาดูสถานการณ์ตัวอย่างบางส่วนเพื่อทำความเข้าใจความแตกต่างระหว่าง PUT และ PATCH ใน REST API ได้ดียิ่งขึ้น
สถานการณ์ตัวอย่าง: PUT กับ PATCH ใน REST API
นอกเหนือจากทฤษฎีแล้ว ลองดูความแตกต่างระหว่าง PUT และ PATCH พร้อมตัวอย่าง รวมถึงการดำเนินการทั้งแบบ idempotent และ non-idempotent
สถานการณ์ที่ 1: คำขอ PUT – การแทนที่ทรัพยากรทั้งหมด
ลองจินตนาการถึงจุดสิ้นสุด API สำหรับการจัดการผลิตภัณฑ์ในระบบอีคอมเมิร์ซ คุณต้องอัปเดตรายละเอียดทั้งหมดของผลิตภัณฑ์ รวมถึงชื่อ ราคา และคำอธิบาย นี่เป็นตัวอย่างทั่วไปของวิธี HTTP PUT กับ PATCH โดยที่ PUT ใช้เพื่อแทนที่ทรัพยากรผลิตภัณฑ์ทั้งหมด
สินค้าเริ่มต้น:
| GET /products/1001{“id”: 1001,”ชื่อ”: “แล็ปท็อป”,”ราคา”: 999.99,”คำอธิบาย”: “แล็ปท็อปที่ทรงพลัง”} |
คุณต้องการอัปเดตราคาและคำอธิบายของผลิตภัณฑ์ คุณส่งคำขอ PUT พร้อมทรัพยากรทั้งหมด:
ใส่คำขอ:
| PUT /products/1001{“id”: 1001,”name”: “Laptop”,”price”: 899.99,”description”: “แล็ปท็อปทรงพลังลดราคา”} |
หากคุณส่งคำขอ PUT นี้หนึ่งครั้งหรือหลายครั้ง ผลลัพธ์จะเหมือนเดิมเสมอ รายละเอียดสินค้าจะได้รับการอัปเดตเพื่อแสดงราคาและคำอธิบายใหม่ และผลลัพธ์เดียวกันจะเกิดขึ้นในแต่ละครั้ง สิ่งนี้ทำให้มั่นใจได้ถึงธรรมชาติของ PUT
ผลลัพธ์ (หลังจากคำขอ PUT):
| {“id”: 1001,”ชื่อ”: “แล็ปท็อป”,”ราคา”: 899.99,”คำอธิบาย”: “แล็ปท็อปทรงพลังลดราคา”} |
สถานการณ์ที่ 2: คำขอ PATCH – การอัปเดตส่วนหนึ่งของทรัพยากร
ตอนนี้ เรามาพิจารณาคำขอ PATCH เพื่ออัปเดตรายละเอียดผลิตภัณฑ์เพียงบางส่วน เช่น คำอธิบาย ตัวอย่าง PATCH API: หากคุณต้องการเปลี่ยนรายละเอียดสินค้าแต่ไม่ต้องการราคา PATCH เป็นตัวเลือกที่ดีกว่า หากต้องการใช้งาน คุณจะต้องสร้างแพตช์ที่มีเฉพาะฟิลด์ที่ต้องแก้ไข เช่น คำอธิบายในตัวอย่าง API REST PATCH นี้
สินค้าเริ่มต้น:
| GET /products/1001{“id”: 1001,”ชื่อ”: “แล็ปท็อป”,”ราคา”: 999.99,”คำอธิบาย”: “แล็ปท็อปที่ทรงพลัง”} |
คำขอแพทช์:
| PATCH /products/1001{“description”: “แล็ปท็อปน้ำหนักเบาและทรงพลัง”} |
เมื่อคุณส่งคำขอ PATCH นี้ เฉพาะช่องคำอธิบายเท่านั้นที่จะได้รับการอัปเดต หากคุณส่งคำขอ PATCH เดียวกันหลายครั้ง คำอธิบายจะยังคงไม่เปลี่ยนแปลงหลังจากการอัพเดตครั้งแรก ทำให้คำขอเป็นแบบเดิม
ผลลัพธ์ (หลังจากคำขอ PATCH):
| {“id”: 1001,”ชื่อ”: “แล็ปท็อป”,”ราคา”: 999.99,”คำอธิบาย”: “แล็ปท็อปน้ำหนักเบาและทรงพลัง”} |
หากคุณใช้ PATCH เดิมอีกครั้ง รายละเอียดสินค้าจะยังคงเหมือนเดิมหลังจาก PATCH แรก ผลลัพธ์มีความสอดคล้องกัน ซึ่งทำให้ PATCH idempotent ในสถานการณ์นี้
สถานการณ์ที่ 3: คำขอ PATCH – การดำเนินการที่ไม่ใช่ idempotent
มาดูการดำเนินการ PATCH ที่ไม่ใช่ idempotent กัน สมมติว่ามีจุดสิ้นสุดสำหรับยอดคงเหลือในกระเป๋าสตางค์ของผู้ใช้ และคุณต้องการเพิ่มยอดคงเหลือ ตัวอย่างความแตกต่างระหว่าง PUT และ PATCH แสดงไว้ที่นี่: PATCH จะเพิ่มมูลค่าให้กับยอดคงเหลือในแต่ละครั้ง
กระเป๋าเงินเริ่มต้น:
| รับ /users/1/wallet{“id”: 1,”ยอดคงเหลือ”: 100.00} |
คำขอแพทช์:
| PATCH /users/1/wallet{“เพิ่มขึ้น”: 50.00} |
คำขอ PATCH นี้จะเพิ่มยอดคงเหลือในกระเป๋าเงิน 50 ดอลลาร์ หากคุณส่งคำขอ PATCH นี้หลายครั้ง ยอดคงเหลือจะเพิ่มขึ้นเรื่อยๆ ในแต่ละ PATCH ซึ่งนำไปสู่ผลลัพธ์ที่แตกต่างกันในแต่ละครั้ง สิ่งนี้ไม่ใช่แบบ idempotent เนื่องจากการใช้ PATCH เดียวกันซ้ำ ๆ จะทำให้เกิดผลลัพธ์ที่แตกต่างออกไป
ผลลัพธ์ (หลังจากการร้องขอ PATCH ครั้งแรก):
| {“รหัส”: 1” ยอดคงเหลือ”: 150.00} |
ผลลัพธ์ (หลังจากคำขอ PATCH ครั้งที่สอง):
| {“รหัส”: 1” ยอดคงเหลือ”: 200.00} |
ในที่นี้ PATCH ไม่ใช่ idempotent เนื่องจากการร้องขอซ้ำๆ ด้วยข้อมูลเดียวกันจะให้ผลลัพธ์ที่แตกต่างกัน
สรุป: ความแตกต่างที่สำคัญระหว่าง PUT กับ PATCH ใน REST API
ข้อแตกต่างที่สำคัญระหว่าง PUT กับ PATCH ใน REST API คือวิธีจัดการกับการอัปเดต PUT จะแทนที่ทรัพยากรทั้งหมด ดังนั้นช่องที่ขาดหายไปจะถูกล้างออก ซึ่งอาจทำให้ข้อมูลสูญหายได้ นี่คือสาเหตุที่นักพัฒนาสร้างแพตช์สำหรับการอัพเดตบางส่วน เพื่อหลีกเลี่ยงการเขียนทับฟิลด์ที่ไม่เปลี่ยนแปลงและรักษาความสมบูรณ์ของข้อมูล
สิ่งนี้ทำให้ PATCH มีประสิทธิภาพมากขึ้นสำหรับการอัพเดตบางส่วน ตัวอย่างของ PATCH API คือ หากคุณต้องการอัปเดตเฉพาะอีเมลของผู้ใช้ การสร้างแพตช์จะส่งเฉพาะช่องอีเมลเท่านั้น ซึ่งต่างจากคำขอ PUT ที่ต้องใช้ข้อมูลผู้ใช้ทั้งหมด
ด้วย PUT จำเป็นต้องมีเพย์โหลดข้อมูลแบบเต็ม ซึ่งหมายความว่าจะต้องส่งทุกช่อง และช่องที่ขาดหายไปจะถูกลบออก อย่างไรก็ตาม PATCH จะส่งเฉพาะฟิลด์ที่ต้องอัปเดตเท่านั้น ทำให้มีประสิทธิภาพมากขึ้น โดยเฉพาะอย่างยิ่งสำหรับทรัพยากรขนาดใหญ่ที่มีการเปลี่ยนแปลงเพียงเล็กน้อย เมธอด PATCH ใน REST API ช่วยให้สามารถส่งคำขอที่มีเป้าหมายมากขึ้นและมีขนาดเล็กลง ส่งผลให้การถ่ายโอนข้อมูลลดลง
ทั้ง PUT และ PATCH เป็น idempotent ซึ่งหมายความว่าการทำซ้ำคำขอเดียวกันจะส่งผลให้ได้ผลลัพธ์เดียวกัน อย่างไรก็ตาม PUT สามารถคาดเดาได้มากกว่าเนื่องจากจะแทนที่ทรัพยากรทั้งหมด PATCH เมื่อใช้เพื่อแก้ไขเฉพาะฟิลด์ที่ระบุ อาจนำไปสู่ผลลัพธ์ที่แตกต่างกัน ขึ้นอยู่กับวิธีที่เซิร์ฟเวอร์จัดการการอัปเดต
ตัวอย่างเช่น หาก PATCH เพิ่มตัวนับ คำขอซ้ำอาจนำไปสู่ผลลัพธ์ที่แตกต่างกัน อย่างไรก็ตาม การดำเนินการของ PATCH API ก็สามารถออกแบบให้เป็นแบบ idempotent ได้เช่นกัน
โดยสรุป ความแตกต่างของ PUT และ PATCH ใน REST API นั้นขึ้นอยู่กับลักษณะของการอัปเดต: PATCH มีไว้สำหรับการเปลี่ยนแปลงบางส่วน ในขณะที่ PUT มีไว้สำหรับการทดแทนทรัพยากรโดยสมบูรณ์ ทั้งสองเป็นแบบ idempotent แต่ PATCH อาจซับซ้อนกว่านี้ได้
ความคิดสุดท้าย
ทั้ง PUT และ PATCH เป็นวิธีการ HTTP พื้นฐานในการออกแบบ REST API แต่มีวัตถุประสงค์ที่แตกต่างกัน ซึ่งเป็นสาระสำคัญของความแตกต่าง PUT และ PATCH ใน REST API คุณสามารถปรับปรุงประสิทธิภาพ ความชัดเจน และฟังก์ชันการทำงานของ API ได้อย่างมากโดยการทำความเข้าใจความแตกต่างระหว่าง PUT และ PATCH ด้วยตัวอย่างที่เรากล่าวถึงในตอนต้นของบทความนี้ โดยการเลือกวิธีการที่ถูกต้อง (PATCH กับการอัปเดต REST) ตามกรณีการใช้งานของคุณ คุณสามารถทำให้ API ของคุณมีประสิทธิภาพ บำรุงรักษาได้ และเป็นมิตรกับผู้ใช้มากขึ้น พิจารณาลักษณะของการอัปเดตเสมอ ไม่ว่าจะเป็นการอัปเดตทั้งหมดหรือบางส่วน ตลอดจนผลกระทบต่อประสิทธิภาพและความสมบูรณ์ของข้อมูล และเลือกวิธีที่สอดคล้องกับความต้องการของคุณมากที่สุด
