ฉันควรตั้งรหัสสถานะใดสำหรับUPDATE( PUT) และDELETE(เช่นอัปเดตผลิตภัณฑ์สำเร็จ)
รหัสสถานะ HTTP สำหรับการอัปเดตและลบ
คำตอบ:
สำหรับคำขอPUT : HTTP 200หรือHTTP 204ควรบ่งบอกถึง "การปรับปรุงทรัพยากรสำเร็จ"
สำหรับคำขอDELETE : HTTP 200หรือHTTP 204ควรบอกเป็นนัยว่า "ทรัพยากรถูกลบสำเร็จ" HTTP 202ยังสามารถส่งคืนซึ่งบ่งบอกว่าคำสั่งนั้นได้รับการยอมรับจากเซิร์ฟเวอร์และ "ทรัพยากรถูกทำเครื่องหมายสำหรับการลบ"
หากมีการแก้ไขทรัพยากรที่มีอยู่ให้ส่งรหัสตอบกลับ 200 (OK) หรือ 204 (ไม่มีเนื้อหา)> SHOULD เพื่อบ่งชี้ว่าการร้องขอสำเร็จ
การตอบสนองที่ประสบความสำเร็จควรเป็น 200 (OK) หากการตอบสนองนั้นรวมถึงเอนทิตีที่อธิบายสถานะ 202 (ยอมรับแล้ว) หากการกระทำนั้นยังไม่ได้มีการประกาศใช้หรือ 204 (ไม่มีเนื้อหา) หากการกระทำนั้นมีการตราขึ้นแล้ว นิติบุคคล
ที่มา: W3.org: นิยามวิธี HTTP / 1.1
HTTP 200 OK:การตอบสนองมาตรฐานสำหรับคำขอ HTTP ที่สำเร็จ การตอบสนองที่แท้จริงจะขึ้นอยู่กับวิธีการร้องขอที่ใช้
HTTP 204 ไม่มีเนื้อหา:เซิร์ฟเวอร์ประมวลผลคำขอเรียบร้อยแล้ว แต่ไม่ได้ส่งคืนเนื้อหาใด ๆ
40
โพสต์ที่มีประโยชน์มาก! อย่างไรก็ตามฉันสงสัยว่ารหัสสถานะ HTTP ควรเป็นสิ่งที่คำขอที่ส่งโดยลูกค้านั้นถูกต้อง (DELETE mySite / entity / 123 ) และไม่มีเอนทิตีที่จะลบ
—
มาร์ติน
@Martin: ในกรณีนี้บริการควรกลับ HTTP 404 อย่างเคร่งครัดพูดลบหรือขอ GET สำหรับทรัพยากรที่ไม่มีอยู่ไม่ใช่คำขอ "ถูกต้อง" - เช่น ลูกค้าไม่ควรพยายามร้องขออีกครั้งเพราะจะไม่ประสบความสำเร็จ ... โปรโตคอล HTTP กำหนดปัญหาได้ 2 ประเภท - ประเภทที่มีรหัสสถานะ 4xx ซึ่งลูกค้าจะต้องแก้ไขคำขอก่อนลองอีกครั้งและผู้ที่มีสถานะ 5xx รหัสซึ่งระบุว่าบริการประสบปัญหาและลูกค้าควร / สามารถลองคำขอที่แน่นอนเดิมโดยไม่ต้องเปลี่ยน
—
Daniel Vassallo
@JeffMartin ที่อาจจะเป็นอย่างนั้นจากมุมมองของผู้ใช้ แต่เท่าที่เซิร์ฟเวอร์เป็นห่วงถ้าทรัพยากรไม่ได้อยู่เซิร์ฟเวอร์ควรกลับ 404
—
Randolpho
@ Randolpho, Idempotence คือทั้งหมดที่เกี่ยวกับการรับผลลัพธ์เดียวกันไม่ว่าคุณจะเรียกใช้การดำเนินการครั้งเดียวหรือหลายครั้ง ลูกค้ากำลังขอให้คุณตรวจสอบให้แน่ใจว่าทรัพยากรถูกลบ ประโยชน์ของการคืน 404 คืออะไร ทำไมถึงต้องรู้ทางใดทางหนึ่ง ตอนนี้ลอจิกไคลเอ็นต์ต้องจัดการสองรหัสการตอบกลับที่แยกจากกันแทนที่จะเป็นหนึ่งรหัส
—
Gili
@Gili: บางทีwikiจะอธิบายได้ดีกว่า: วิธีการ PUT และ DELETE ถูกกำหนดให้เป็น idempotent ... โปรดทราบว่า idempotence อ้างถึงสถานะของระบบหลังจากการร้องขอเสร็จสมบูรณ์ดังนั้นในขณะที่การกระทำของเซิร์ฟเวอร์ (เช่นการลบบันทึก ) หรือรหัสตอบกลับที่ส่งคืนอาจแตกต่างกันในคำขอถัดไปสถานะระบบจะเหมือนเดิมทุกครั้ง
—
Randolpho
คำตอบสั้น ๆ : สำหรับทั้ง PUT และ DELETE คุณควรส่ง 200 (OK) หรือ 204 (ไม่มีเนื้อหา)
คำตอบยาว: นี่คือแผนภาพการตัดสินใจที่สมบูรณ์ (คลิกเพื่อขยาย)
แผนภาพนั้นน่าทึ่ง มีรุ่นความละเอียดสูงกว่าสำหรับการพิมพ์ออกมา?
—
KiKi
ในบริบทของ POST ของทรัพยากรที่มีอยู่การอภิปราย SO อีกครั้ง ( stackoverflow.com/questions/3825990/… ) แนะนำให้ส่ง 409 Conflict หรือ 302 Found พบแทนที่จะต่อท้ายเนื้อหา
—
koppor
ฉันอยากรู้ว่าการตอบสนอง 204 และ 200 หลังจากการลบเกิดขึ้นควรย้อนกลับหรือไม่ ที่ถูกลบ? -> การตอบสนองรวมถึงนิติบุคคลหรือไม่? -> ใช่ -> 204 ไม่มีเนื้อหา; ไม่มี -> 200 ตกลง
—
matth
เวอร์ชันที่อัปเดตของรูปภาพอยู่ที่นี่: raw.github.com/for-GET/http-decision-diagram/master/httpdd.png
—
zaius
มันหายไปจากแพทช์
—
doremi
นี่คือเคล็ดลับบางอย่าง:
ลบ
200 (ถ้าคุณต้องการส่งข้อมูลเพิ่มเติมในการตอบกลับ) หรือ204 (แนะนำ)
202ปฏิบัติการที่ถูกลบยังไม่ได้รับการมอบหมาย
หากไม่มีอะไรที่จะลบให้ใช้204 หรือ 404 (การดำเนินการ DELETE นั้นเป็น idempotent แล้วลบรายการที่ถูกลบแล้วไปแล้วว่าเป็นการดำเนินการที่ประสบความสำเร็จดังนั้นคุณสามารถส่งคืน204ได้ แต่มันเป็นความจริงที่ idempotent ไม่จำเป็น
ข้อผิดพลาดอื่น ๆ :
- 400 คำขอไม่ถูกต้อง (ไวยากรณ์ผิดรูปแบบหรือแบบสอบถามไม่ถูกต้องเป็นเรื่องแปลกแต่เป็นไปได้)
- 401 การ ตรวจสอบสิทธิ์โดยไม่ได้รับอนุญาตล้มเหลว
- 403 ต้องห้าม : การอนุญาตล้มเหลวหรือรหัสแอปพลิเคชันไม่ถูกต้อง
- 405 ไม่ได้รับอนุญาต แน่ใจ
- 409 ความขัดแย้งของทรัพยากรสามารถเกิดขึ้นได้ในระบบที่ซับซ้อน
- และ501 , 502ในกรณีที่มีข้อผิดพลาด
PUT
หากคุณกำลังปรับปรุงองค์ประกอบของคอลเลกชัน
- 200/204ด้วยเหตุผลเดียวกับ DELETE ด้านบน
- 202หากยังไม่ได้ส่งมอบปฏิบัติการ
องค์ประกอบที่อ้างอิงไม่มีอยู่:
- PUT สามารถเป็น201 (ถ้าคุณสร้างองค์ประกอบเพราะนั่นเป็นพฤติกรรมของคุณ)
404ถ้าคุณไม่ต้องการสร้างองค์ประกอบผ่าน PUT
400 คำขอไม่ถูกต้อง (ไวยากรณ์ผิดรูปแบบหรือแบบสอบถามไม่ถูกต้องพบได้บ่อยกว่าในกรณีของ DELETE)
- 401 ไม่ได้รับอนุญาต
- 403 ต้องห้าม : การตรวจสอบล้มเหลวหรือรหัสแอปพลิเคชันไม่ถูกต้อง
- 405 ไม่ได้รับอนุญาต แน่ใจ
- ความขัดแย้งทรัพยากร409สามารถเกิดขึ้นได้ในระบบที่ซับซ้อนเช่นเดียวกับใน DELETE
- 422 เอนทิตีที่ไม่สามารถประมวลผลได้ซึ่งช่วยแยกความแตกต่างระหว่าง "คำขอไม่ถูกต้อง" (เช่น XML / JSON ที่มีรูปแบบไม่ถูกต้อง) และค่าฟิลด์ที่ไม่ถูกต้อง
- และ501 , 502ในกรณีที่มีข้อผิดพลาด
คำตอบนี้สร้างขึ้นจากเครื่องหมายคำพูดขนาดใหญ่เกือบสองคำ แต่ไม่มีการระบุแหล่งที่มา คุณมาจากไหน
—
เควนติ
204 สถานะที่เหมาะสมที่จะส่งคืนสำหรับคำขอ PUT หรือไม่หากสถานะไม่เปลี่ยนแปลงอย่างมีประสิทธิภาพ ตัวอย่างเช่นคุณขอให้ปิดการใช้งานผู้ใช้ แต่ผู้ใช้ไม่ได้ใช้งานแล้ว
—
ΕГИІИО
คำขอ PUT คือ idempotent ดังนั้นคุณสามารถส่งคืน 204 ได้เนื่องจากวัตถุมีการเปลี่ยนแปลงในระบบ PUT ไม่ใช่ PATCH ดังนั้นคุณไม่แน่ใจว่าคุณต้องการเปลี่ยนฟิลด์ใด คุณสามารถส่งกลับ 501 - 502 ถ้าการออกแบบของคุณจำเป็นต้องรู้ว่าวัตถุนั้นเหมือนกับวัตถุในคำขอ แต่ ... ฉันไม่ชอบมันจริง ๆ .. ฉันชอบ 204 หรือถ้าคุณต้องการ ปิดใช้งานผู้ใช้โดยไม่ต้องเปลี่ยนฟิลด์เพิ่มเติมคุณอาจใช้ PATCH
—
Alfonso Tienda
ฉันจะเพิ่ม HTTP 422 Entity ที่ไม่สามารถประมวลผลได้ ช่วยแยกแยะระหว่าง "คำขอไม่ถูกต้อง" (เช่น XML / JSON ที่มีรูปแบบไม่ถูกต้อง) และค่าฟิลด์ที่ไม่ถูกต้อง
—
vdboor
นอกจาก 200 และ 204, 205 (รีเซ็ตเนื้อหา)อาจเป็นการตอบสนองที่ถูกต้อง
เซิร์ฟเวอร์ได้ดำเนินการตามคำขอและตัวแทนผู้ใช้ SHOULD รีเซ็ตมุมมองเอกสารที่ทำให้คำขอถูกส่ง ... [เช่น] การล้างฟอร์มที่มีการป้อนข้อมูล
ตั้งแต่ขุดคุ้ยคำถามลงไปถ้าลบ "ควรจะ" กลับ200 VS 204เป็นมูลค่าการพิจารณาว่าบางคนแนะนำให้กลับนิติบุคคลที่มีการเชื่อมโยงเพื่อให้การตั้งค่าสำหรับ200
"แทนที่จะส่งคืน 204 (ไม่มีเนื้อหา) API ควรมีประโยชน์และแนะนำสถานที่ที่ควรไปในตัวอย่างนี้ฉันคิดว่าลิงก์ที่ชัดเจนที่จะให้คือ" 'ที่ไหนสักแห่ง.com/container/' (ลบ 'ทรัพยากร') "- คอนเทนเนอร์ที่ไคลเอ็นต์เพิ่งลบทรัพยากรบางทีไคลเอนต์ต้องการที่จะลบทรัพยากรเพิ่มเติมเพื่อที่จะเป็นลิงค์ที่มีประโยชน์ "
http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/
หากลูกค้าพบการตอบสนอง 204 มันอาจยอมแพ้ไปที่จุดเริ่มต้นของ API หรือกลับไปที่ทรัพยากรก่อนหน้านี้ที่เข้าเยี่ยมชม ไม่มีตัวเลือกที่ดีโดยเฉพาะอย่างยิ่ง
โดยส่วนตัวแล้วฉันจะไม่บอกว่า 204 ผิด (ไม่ใช่ผู้เขียน; เขาพูดว่า "น่ารำคาญ") เพราะการแคชที่ดีที่ฝั่งไคลเอ็นต์มีประโยชน์มากมาย ดีที่สุดคือการสอดคล้องกันทั้งสองทาง
นี่คือรหัสสถานะบางส่วนที่คุณควรรู้สำหรับความรู้ประเภทของคุณ
การตอบสนองข้อมูล 1XX
- 100 ดำเนินการต่อ
- 101 การสลับโปรโตคอล
- 102 การประมวลผล
- 103 คำแนะนำเริ่มแรก
สำเร็จ 2XX
- 200 ตกลง
- 201 สร้างแล้ว
- 202 ได้ รับการยอมรับ
- 203 ข้อมูลที่ไม่มีสิทธิ์
- 204 ไม่มีเนื้อหา
- 205 รีเซ็ตเนื้อหา
- 206 เนื้อหาบางส่วน
- 207 หลายสถานะ
- 208 มีการรายงานแล้ว
- 226 IM ใช้แล้ว
3XX Redirection
- ทางเลือกมากกว่า300 รายการ
- 301 ย้ายอย่างถาวร
- 302 พบ
- 303 ดูที่อื่น ๆ
- 304 ไม่ได้รับการแก้ไข
- 305 ใช้พรอกซี
- 306 Switch Proxy
- 307 การ เปลี่ยนเส้นทางชั่วคราว
- 308 การ เปลี่ยนเส้นทางถาวร
ข้อผิดพลาดไคลเอนต์ 4XX
- 400 คำขอไม่ถูกต้อง
- 401 ไม่ได้รับอนุญาต
- จำเป็นต้องชำระเงิน402
- 403 ต้องห้าม
- ไม่พบ404
- ไม่อนุญาตให้ใช้วิธี405
- 406 ไม่เป็นที่ยอมรับ
- ต้องมีการรับรองความถูกต้องของพร็อกซี407
- 408 คำขอหมดเวลา
- 409 ความขัดแย้ง
- 410 หายไป
- 411 ความยาวที่ต้องการ
- 412 เงื่อนไขเบื้องต้นล้มเหลว
- 413 น้ำหนักบรรทุกมากเกินไป
- 414 URI ยาวเกินไป
- 415 ประเภทสื่อที่ไม่รองรับ
- 416 Range ไม่เป็นที่พอใจ
- 417 ความคาดหวังล้มเหลว
- 418 ฉันเป็นกาน้ำชา
- 420 วิธีการล้มเหลว
- 421 คำขอผิดพลาด
- 422 เอนทิตีที่ไม่สามารถประมวลผลได้
- 423 ถูกล็อค
- 424 การ พึ่งพาล้มเหลว
- จำเป็นต้องอัพเกรด426
- จำเป็นต้องมีเงื่อนไข428
- 429 คำขอมากเกินไป
- 431 คำขอส่วนหัวฟิลด์มีขนาดใหญ่เกินไป
- 451 ไม่พร้อมใช้งานด้วยเหตุผลทางกฎหมาย
ข้อผิดพลาดเซิร์ฟเวอร์ 5XX
- ข้อผิดพลาด500 เซิร์ฟเวอร์ภายใน
- 501 ไม่ดำเนินการ
- 502 เกตเวย์ไม่ดี
- 503 บริการไม่พร้อมใช้งาน
- การ หมดเวลาเกตเวย์504
- ไม่รองรับรุ่น505 Http
- 506 Varient ยังเจรจาต่อรอง
- 507 การ จัดเก็บไม่เพียงพอ
- ตรวจพบ508 Loop
- 510 ไม่ขยาย
- ต้องมีการตรวจสอบความถูกต้องเครือข่าย511
ในเดือนมิถุนายน 2014 RFC7231ล้าสมัย RFC2616 หากคุณกำลังทำ REST ผ่าน HTTP RFC7231 จะอธิบายถึงพฤติกรรมที่คาดหวังได้จาก GET, PUT, POST และ DELETE
เมื่อเป็นทรัพยากรที่มีการแก้ไขรหัสการตอบสนองที่ควรจะเป็น200 (“OK”) หากสถานะทรัพยากรเปลี่ยนไปในทางที่เปลี่ยน URI เป็นทรัพยากร (ตัวอย่างเช่นบัญชีผู้ใช้จะถูกเปลี่ยนชื่อ) รหัสตอบสนองคือ 301 (“ ย้ายถาวร”)และส่วนหัวสถานที่ควรระบุ URI ใหม่
เมื่อวัตถุถูกลบรหัสการตอบสนองควรเป็น 200 (“ OK”)
ตามลิงค์ด้านล่างเพื่อดูรายละเอียดเพิ่มเติม - รหัสสถานะสำหรับการพักผ่อน