รหัสสถานะ HTTP สำหรับคำขอที่ประสบความสำเร็จบางส่วน

116

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

ตอนนี้ฉันกำลังถามตัวเองว่ารหัสสถานะที่เหมาะสมสำหรับแอปพลิเคชันจะเป็นอย่างไรโดยบอกว่าคำขอได้รับการยอมรับ แต่มีบางสิ่งที่ไม่สามารถทำได้

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

http rest http-status-codes

— Norbert Hartl
แหล่งที่มา

66

ฉันได้จัดการกับปัญหาที่คล้ายกันมาก ในกรณีนี้ฉันส่งคืนไฟล์

207 หลายสถานะ

ตอนนี้นี่ไม่ใช่ HTTP ที่เข้มงวด แต่เป็นส่วนหนึ่งของส่วนขยาย WebDAV ดังนั้นหากคุณไม่สามารถควบคุมไคลเอนต์ได้ก็ไม่ดีสำหรับคุณ หากคุณทำเช่นนั้นคุณสามารถทำได้ดังนี้:

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D='DAV:'>
     <D:response>
       <D:user>user-123</D:user>
       <D:status>success</D:status>
     </D:response>
     <D:response>
       <D:user>user-789</D:user>
       <D:status>failure</D:status>
     </D:response>
   </D:multistatus>

แต่อีกครั้งนี่เป็นส่วนขยาย HTTP และคุณต้องมีการควบคุมไคลเอ็นต์ด้วย

— ไคลาร์
แหล่งที่มา

3

ฉันคิดจะใช้สิ่งนี้ แต่ฉันไม่ค่อยสบายใจกับมัน ขอบคุณ!

— Norbert Hartl

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

— Kylar

ฉันเข้าใจ. ฉันแค่พยายามหลีกเลี่ยงการจัดการสถานะในระดับเพิ่มเติม (ซึ่งไม่ใช่ IMHO ที่ดี) รหัสส่วนใหญ่ของฉันใช้ได้กับ HTTP และฉันคิดว่ากรณีการใช้งานที่อธิบายไว้ของฉันจะทำได้ดีหากไม่มี

— Norbert Hartl

คุณสามารถส่งเนื้อหากลับได้ตลอดเวลา - ส่ง 200 พร้อมการตอบสนอง JSON หรืออะไรก็ได้ที่คุณต้องการเพื่อพิจารณาว่าตัวใดประสบความสำเร็จ

— Kylar

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

— Norbert Hartl

66

ฉันมีปัญหาเดียวกันและลงเอยด้วยการใช้สองวิธีที่แตกต่างกัน:

รหัสส่งคืน HTTP 202: Acceptedซึ่งระบุว่าคำขอนั้นใช้ได้ แต่ไม่มีการรับประกันว่าทุกอย่างเป็นไปตามที่ควรจะเป็น
ส่งคืนค่าปกติ200ในการตอบกลับ แต่รวมรายการสิ่งที่ไม่ได้เลื่อนออกไปในเนื้อหาการตอบกลับ

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

— Arne
แหล่งที่มา

5

202 ไม่ได้หมายถึงสิ่งอื่น ๆ เช่นการเข้าคิวหรือไม่?

— Sinaesthetic

6

ใช่ @Sinaesthetic จากข้อมูลจำเพาะ HTTP 1.1 ล่าสุด "(... ) คำขอได้รับการยอมรับสำหรับการประมวลผล แต่การประมวลผลยังไม่เสร็จสมบูรณ์" ดังนั้นเพื่อความสำเร็จบางส่วน 202 จึงไม่เหมาะสม

— Huercio

-4

สิ่งที่เกี่ยวกับการใช้ 206 Partial Content ฉันรู้ว่า 206 เป็นข้อมูลเพิ่มเติมเกี่ยวกับช่วง แต่จะเป็นอย่างไรหากสามารถระบุคำขอที่ประสบความสำเร็จบางส่วนได้

— ยูซุฟ
แหล่งที่มา

MDNระบุดังนี้: "รหัสตอบกลับสถานะความสำเร็จของเนื้อหาบางส่วนของ HTTP 206 ระบุว่าคำขอประสบความสำเร็จและมีเนื้อหาประกอบด้วยช่วงของข้อมูลที่ร้องขอตามที่อธิบายไว้ในส่วนหัวช่วงของคำขอ" เท่าที่ฉันเข้าใจ 206 Partial Content มีไว้สำหรับคำขอที่มีช่วงเนื้อหาอย่างเคร่งครัด

— sbbs

-14

HyperText Transfer Protocol เกี่ยวข้องกับด้านการส่งข้อมูล ไม่มีรหัสข้อผิดพลาดในการจัดการกับข้อผิดพลาดระดับแอปพลิเคชัน

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

— AVee
แหล่งที่มา

18

HTTP เป็นโปรโตคอลระดับแอปพลิเคชัน คุณไม่สามารถวางไว้ในระดับการขนส่งและการใช้งานได้ หากคุณคิดถึง OSI HTTP จะอยู่ที่เลเยอร์ 5-7 HTTP แตกต่างกันบ้าง ส่วนหัวและรหัสส่งคืนส่วนใหญ่เป็นโปรแกรมเฉพาะ รหัสจะขึ้นอยู่กับข้อมูลที่ระบุในเอนทิตีโปรโตคอล HTTP ไม่ใช่ในรูปแบบแอปพลิเคชันที่กำหนดเอง เกี่ยวกับ 200 ฉันจะบอกว่าคำจำกัดความของคุณผิดอย่างหมดจดหากนำไปใช้กับคำกริยาที่ไม่ได้เป็น POST แต่ POST เปลี่ยนเกมเล็กน้อยและในบริบทนี้สมมติฐานของคุณ "จัดการอย่างเหมาะสม" ก็ไม่แน่ใจเช่นกัน

— Norbert Hartl

OSI ที่พูดอย่างเข้มงวดถือว่า HTTP เป็นโปรโตคอลระดับแอปพลิเคชันและเมื่อพูดคุยกับเว็บเซิร์ฟเวอร์ "ปกติ" สิ่งนี้เป็นจริง แต่ในกรณีของคุณคุณกำลังเรียกใช้โปรโตคอลของคุณเองบน HTTP เช่นเดียวกับแอปพลิเคชันจำนวนมากในปัจจุบัน ในการใช้งานประเภทนั้น HTTP เพียงแค่ให้การขนส่ง (แอปพลิเคชันของคุณกำลังส่งข้อความถึงผู้ใช้ไม่ใช่การถ่ายโอนไฮเปอร์เท็กซ์ ... )

— AVee

2

เพียงเพื่อให้ชัดเจน HTTP ในทาง REST คือทรัพยากรเป็นศูนย์กลาง ในบริบทนี้ 200 หมายถึงเอกลักษณ์ (ทรัพยากรที่คุณระบุ) แทนที่จะเป็น 3xx ซึ่งชี้ไปในทิศทางของข้อมูลประจำตัว การใช้ POST จะเปลี่ยน URI ของทรัพยากรให้เป็น URI การประมวลผลและมีรหัสข้อผิดพลาดที่ต้องจัดการกับสิ่งนั้น บริบทเปลี่ยนไปเล็กน้อยและคำจำกัดความของสิ่งต่าง ๆ ก็พร่ามัวเล็กน้อยหรืออย่างน้อยก็ยากที่จะเข้าใจ

— Norbert Hartl

1

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

— AVee

1

อย่างไรก็ตามขอบคุณที่ตอบคำถามของฉัน ฉันเพิ่งค้นพบว่า stackoverflow เป็นไคลเอนต์แชทที่ไม่ดี :)

— Norbert Hartl