ตาม "REST อุดมการณ์" สิ่งที่ควรอยู่ในเนื้อหาการตอบสนองสำหรับคำขอ PUT / POST / DELETE
สิ่งที่เกี่ยวกับรหัสส่งคืน? คือHTTP_OKพอ?
อะไรคือเหตุผลของการประชุมเช่นนั้นถ้ามี?
ฉันพบโพสต์ที่ดีที่อธิบายความแตกต่าง POST / PUT: POST เทียบกับ PUT แต่ก็ยังไม่ตอบคำถามของฉัน
คำตอบ:
ให้อภัยความผิดพลาด แต่ถ้าคุณกำลังทำ REST ผ่าน HTTP RFC7231 จะอธิบายถึงพฤติกรรมที่คาดหวังได้จาก GET, PUT, POST และ DELETE
อัปเดต (3 ก.ค. '14):
ข้อมูลจำเพาะ HTTP โดยเจตนาไม่ได้กำหนดสิ่งที่ส่งคืนจาก POST หรือ DELETE ข้อมูลจำเพาะจะกำหนดสิ่งที่จะต้องกำหนดเท่านั้น ส่วนที่เหลือจะขึ้นอยู่กับผู้ใช้งานเพื่อเลือก
โดยรวมแล้วการประชุมนั้น“ คิดเหมือนคุณกำลังส่งหน้าเว็บ”
สำหรับ PUT ฉันจะคืนค่ามุมมองเดิมที่คุณจะได้รับถ้าคุณได้รับทันทีหลังจากนั้น ที่จะส่งผลให้ 200 (ดีสมมติว่าการแสดงผลสำเร็จแน่นอน) สำหรับ POST ฉันจะทำการเปลี่ยนเส้นทางไปยังทรัพยากรที่สร้างขึ้น (สมมติว่าคุณกำลังดำเนินการสร้างถ้าไม่เพียงแค่ส่งคืนผลลัพธ์); รหัสสำหรับการสร้างที่ประสบความสำเร็จคือ 201 ซึ่งจริงๆแล้วเป็นรหัส HTTP เดียวสำหรับการเปลี่ยนเส้นทางที่ไม่ได้อยู่ในช่วง 300
ฉันไม่เคยมีความสุขกับสิ่งที่ DELETE ควรส่งคืน (ขณะนี้รหัสของฉันสร้าง HTTP 204 และเนื้อความว่างเปล่าในกรณีนี้)
PUTคำขอส่งคืนหน้าถัดไปดูเหมือนเป็นการปฏิบัติที่ไม่ดีเนื่องจากการรีเฟรชในหน้าผลลัพธ์จะทำให้คำขอดำเนินการอีกครั้ง สำหรับฉันแล้วการเปลี่ยนเส้นทางโดยคิดว่าคุณกำลังจัดการกับคำขอแบบซิงโครนัส
PUTคำขออีกครั้งทำให้ข้อมูลเปลี่ยนกลับ ตัวอย่างเช่นหากคนสองคนกำลังอ้างถึงหน้าเดียวกันอีกคนหนึ่งทำการอัปเดตจากนั้นคนอื่นทำการอัปเดตหากคนแรกรีเฟรชเพื่อดูผลลัพธ์มันจะจบลงด้วยเหตุนี้สิ่งที่จะกลับไปเป็นจริงก่อนที่บุคคลที่สองจะสร้างขึ้น การเปลี่ยนแปลงของพวกเขา
โดยทั่วไปการสร้างทรัพยากรจะถูกแมปกับ POST และควรส่งคืนตำแหน่งของทรัพยากรใหม่ ตัวอย่างเช่นในนั่งร้าน Rails CREATE จะเปลี่ยนเส้นทางไปยัง SHOW สำหรับทรัพยากรที่สร้างขึ้นใหม่ วิธีการเดียวกันอาจเหมาะสมสำหรับการอัปเดต (PUT) แต่นั่นเป็นเพียงข้อตกลงที่น้อยกว่า การอัปเดตจำเป็นต้องระบุถึงความสำเร็จเท่านั้น การลบอาจจำเป็นต้องระบุถึงความสำเร็จเท่านั้น หากคุณต้องการเปลี่ยนเส้นทางการส่งคืนรายการทรัพยากรอาจเหมาะสมที่สุด
HTTP_OK สามารถระบุความสำเร็จได้
กฎเดียวที่ยากและรวดเร็วในสิ่งที่ฉันได้กล่าวไว้ข้างต้นคือ CREATE ควรส่งคืนตำแหน่งของทรัพยากรใหม่ ดูเหมือนว่าจะเป็นเกมง่ายๆสำหรับฉัน มันทำให้รู้สึกที่สมบูรณ์แบบที่ลูกค้าจะต้องสามารถเข้าถึงรายการใหม่
โดย RFC7231 มันไม่สำคัญและอาจว่างเปล่า
วิธีที่เราใช้โซลูชันที่ยึดตามมาตรฐาน json api ในโครงการ:
โพสต์ / วาง: เอาท์พุทแอตทริบิวต์ของวัตถุในขณะที่รับ (ตัวกรองข้อมูล / ความสัมพันธ์ใช้เหมือนกัน)
ลบ: ข้อมูลมีเพียง null (สำหรับการเป็นตัวแทนของวัตถุที่หายไป)
สถานะสำหรับการลบมาตรฐาน: 200
ฉันชอบ Alfonso Tienda responce จาก รหัสสถานะ HTTP สำหรับการอัปเดตและลบหรือไม่
นี่คือเคล็ดลับบางอย่าง:
ลบ
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ในกรณีที่มีข้อผิดพลาด