REST API ควรส่งคืนข้อผิดพลาดเซิร์ฟเวอร์ภายใน 500 ข้อเพื่อระบุว่าแบบสอบถามอ้างอิงวัตถุที่ไม่มีอยู่หรือไม่

39

ฉันกำลังทำงานกับ REST API ซึ่งอยู่บนเซิร์ฟเวอร์ที่จัดการข้อมูลสำหรับอุปกรณ์ IoT จำนวนมาก

งานของฉันคือการสืบค้นเซิร์ฟเวอร์โดยใช้ API เพื่อรวบรวมข้อมูลประสิทธิภาพเฉพาะเกี่ยวกับอุปกรณ์ดังกล่าว

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

เซิร์ฟเวอร์ส่งคืน500 Internal Server Errorแบบสอบถามสำหรับหนึ่งใน ID เหล่านั้น ในแอปพลิเคชันของฉันมีข้อผิดพลาดเกิดขึ้นและฉันไม่เห็นรายละเอียดเกี่ยวกับข้อผิดพลาด หากฉันตรวจสอบการตอบสนองอย่างใกล้ชิดกับบุรุษไปรษณีย์ฉันจะเห็นว่าเซิร์ฟเวอร์ส่งคืน JSON ในเนื้อหาซึ่งมี:

errorMessage: "This ID does not exist".

ไม่สนใจข้อเท็จจริงที่เซิร์ฟเวอร์ระบุรหัสเริ่มต้นนั่นเป็นปัญหาแยกต่างหากสำหรับนักพัฒนา

REST API ควรส่งคืน a 500 Internal Server Errorเพื่อรายงานว่าแบบสอบถามอ้างอิงวัตถุที่ไม่มีอยู่หรือไม่? ตามความคิดของฉันรหัสตอบกลับ HTTP ควรอ้างอิงอย่างเคร่งครัดถึงสถานะของการเรียกใช้ REST แทนที่จะใช้กลไกภายในของ API ฉันคาดหวังว่าจะ200 OKมีการตอบสนองที่มีข้อผิดพลาดและคำอธิบายซึ่งจะเป็นกรรมสิทธิ์ของ API ที่เป็นปัญหา

มันเกิดขึ้นกับฉันว่ามีความคาดหวังที่แตกต่างกันขึ้นอยู่กับว่าการเรียกใช้ REST นั้นมีโครงสร้างอย่างไร

ลองพิจารณาตัวอย่างเหล่านี้:

http://example.com/restapi/deviceinfo?id=123
http://example.com/restapi/device/123/info

ในกรณีแรกรหัสอุปกรณ์จะถูกส่งเป็นตัวแปร GET 404 หรือ 500 จะระบุว่าเส้นทาง ( /restapi/deviceinfo) ไม่พบหรือทำให้เซิร์ฟเวอร์เกิดข้อผิดพลาด

ในกรณีที่สอง ID อุปกรณ์เป็นส่วนหนึ่งของ URL ฉันจะเข้าใจมากขึ้นเกี่ยวกับ a 404 Not Foundแต่ก็ยังสามารถโต้แย้งได้ว่าส่วนใดของเส้นทางที่ถูกตีความว่าเป็นตัวแปรเทียบกับจุดสิ้นสุด

api-design error-handling http-response

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

เงื่อนไขนี้คุณกำลังอธิบายว่าประสบความสำเร็จหรือล้มเหลวหรือไม่?

— Robert Harvey

3

เกี่ยวข้อง (อาจซ้ำกัน): ฉันควรส่งคืนการตอบสนอง 204 หรือ 404 เมื่อไม่พบทรัพยากรหรือไม่

— ริ้น

@RobertHarvey ความคาดหวังของฉันคือ API จะส่งคืนข้อมูลบางอย่างเกี่ยวกับอุปกรณ์ แบบสอบถามควรจะประสบความสำเร็จ แต่ ID อุปกรณ์ที่หายไปไม่ควรทำให้เกิดความล้มเหลวในระดับคำขอ

— JYelton

18

ID ไม่ใช่เสียงที่มีอยู่เช่นฉัน 404 สาเหตุที่พบบ่อยที่สุดสำหรับข้อผิดพลาด 500 ข้อคือโปรแกรมเมอร์อนุญาตให้เกิดข้อยกเว้นภายในเพื่อทำให้เซิร์ฟเวอร์โฮสติ้งจัดการได้ บางครั้งมีกรณีพิเศษที่เกิดขึ้นและบางครั้งก็เป็นเพียงการเขียนโปรแกรมขี้เกียจ ยากที่จะพูดซึ่งเกิดขึ้นที่นี่

— Berin Loritsch

9

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

— berry120

96

ฉันคิดว่าการตอบกลับ 404 เป็นการจับคู่ความหมายที่ดีที่สุดที่นี่เพราะทรัพยากรที่คุณพยายามค้นหา (ดังที่ URI แสดงไว้สำหรับการสืบค้น) ไม่พบ การส่งคืน payload ข้อผิดพลาดในเนื้อความนั้นสมเหตุสมผล แต่ไม่จำเป็น

ตามRFC 2616คำจำกัดความของรหัสสถานะ 404 คือ:

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

— Andy Hunt
แหล่งที่มา

6

404 เป็นเพียงการจับคู่ความหมายหากรหัสที่ไม่มีอยู่สอดคล้องกับทรัพยากรที่ถูกดึงออกมา

— Robert Harvey

55

@ThomasOwens การค้นหาที่ส่งคืนผลลัพธ์จะไม่ส่งคืนสถานะ 200 และอาร์เรย์ผลลัพธ์ที่ว่างเปล่า จะส่งคืน 404 เมื่อระบุ ID อ็อบเจ็กต์เฉพาะที่ไม่มีอยู่จริงเท่านั้น

— ฌอนเบอร์ตัน

11

@ThomasOwens: จาก pespective โทร, ปลายทางไม่ได้ก็/questions /questions/368213ปลายทางนั้นไม่มีอยู่ในสถานการณ์ของคุณ คิดแบบนี้: ถ้าคุณทำ GET บน / foo / bar และไม่มีบาร์ทำไมการตอบสนองควรแตกต่างกันถ้า / foo มีอยู่หรือไม่?

— ไบรอัน Oakley

17

ใช่ไม่ใช่ข้อผิดพลาดของเซิร์ฟเวอร์ดังนั้นเราจึงไม่ส่ง 5xx มันเป็นข้อผิดพลาดของลูกค้า - ลูกค้าขอสิ่งที่ไม่มีดังนั้นเราจึงส่ง 4xx โดยเฉพาะ 404

— bdsl

7

@ThomasOwens:

How do you differentiate between a 404 meaning "the query returned no results" and a 404 meaning "the endpoint does not exist"?

- 400 คำขอไม่ถูกต้อง

— Robert Harvey

34

ฉันจะใช้ตัวอย่างของคุณ

http://example.com/restapi/deviceinfo?id=123

หากปลายทางส่งคืนอาร์เรย์ json ตัวเลือกที่ดีที่สุดคืออยู่200 OKกับอาร์เรย์ว่างเปล่าหากไม่พบผลลัพธ์

หากปลายทางถูกออกแบบมาเพื่อกลับมาเป็นผลเดียวทางเลือกของฉันจะเป็นเพราะสำหรับฉันไวยากรณ์ที่เหมาะสมสำหรับชนิดของปลายทางคือ:404 NOT FOUND http://example.com/restapi/deviceinfo/123ฉันมักจะใช้พารามิเตอร์ขอสำหรับการกรองเท่านั้นและเมื่อจุดสิ้นสุดของฉันส่งคืนอาร์เรย์

http://example.com/restapi/device/123/info

ผมคิดว่าคำถามนี้ได้รับการตอบอยู่แล้วนี่ POST หรือ GET ตัวเลือกที่ดีกว่าน่าจะเป็น404 NOT FOUNDเพราะ123ไม่พบทรัพยากร

ในทั้งสองกรณีฉันไม่เห็นความจำเป็นในการอธิบายเหตุผลของคำขอที่ยังไม่เสร็จสมบูรณ์ ข้อมูลคำขอและรหัส HTTP ได้อธิบายไปแล้วว่าทำไม

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

2

คุณแยกความแตกต่างระหว่าง id ที่ไม่มีอยู่และ URL ที่ไม่ดีได้อย่างไร

— Robert Harvey

2

@luizfzs คุณสามารถทำเช่นนั้นฉันไม่เห็นปัญหาเกี่ยวกับสิ่งนั้น ใน API บางตัวที่ฉันพัฒนาขึ้นฉันชอบที่จะใช้ 204 ใน PUT หรือ DELETE ที่ประสบความสำเร็จ ( ดังที่อธิบายไว้ที่นี่ ) โดยไม่มีเนื้อหาตอบสนอง

— Dherik

10

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

— cHao

6

@cHao เพราะในฐานะนักพัฒนาฉันต้องการทราบว่าแอปของฉันล้มเหลวเพราะไม่มีรายการหรือไม่หรือถ้าฉันชี้แอปของฉันไปที่ app.company.cxm / test / แทนที่จะ app.company.cxm / tst /

— Patrick M

7

@PatrickM: ในฐานะนักพัฒนาคุณควรรู้ว่าการตอบสนองข้อผิดพลาดอาจมีเนื้อหาของข้อความด้วย นั่นคือสิ่งที่ข้อมูลข้อผิดพลาดอธิบายจะไปถ้าคุณต้องการมัน อย่าทำลายความหมายเพียงเพราะคุณหวาดระแวงเกี่ยวกับนิ้วอ้วน ในระดับ HTTP มันไม่สำคัญว่าคุณจะทำผิดพลาด/itms/1234หรือ/items/12234ไม่

— cHao

27

HTTP 404 ถูกต้องเนื่องจากเซิร์ฟเวอร์เข้าใจทรัพยากรที่ลูกค้าขอ แต่ไม่มีทรัพยากรนั้น

ข้อเท็จจริงที่ว่าคุณกำลังทำงานกับ "REST API" เป็นกุญแจสำคัญ API ควรทำงานเหมือนกำลังดำเนินการถ่ายโอนสถานะของการนำเสนอไม่ใช่การเรียกใช้ฟังก์ชัน (แน่นอนว่าคำว่า "ส่วนที่เหลือ" ได้มามีความหมายที่กว้างขึ้น แต่คุณยังสามารถใช้ความหมายที่แท้จริงของตนเพื่อผลดีที่นี่.) ลูกค้าได้ขอให้สถานะของทรัพยากรที่อธิบายไว้โดยที่ http://example.com/restapi/device/123/infoURL การสืบค้น ( /deviceinfo?id=123) จะไม่เปลี่ยนแปลงสถานการณ์ เซิร์ฟเวอร์รู้ว่าคุณกำลังขอให้โอนสถานะของอุปกรณ์ 123 แต่ไม่รู้จักว่าเป็นทรัพยากรที่รู้จัก HTTP 404ด้วยเหตุนี้

คำตอบที่เป็นไปได้อื่น ๆ ที่กล่าวถึงที่นี่มีความหมายเฉพาะเช่นกัน:

HTTP 200- เราได้รับสถานะของคุณ มันอยู่ในร่างกายตอบสนอง
HTTP 204- เราได้รับสถานะของคุณ มันว่างเปล่า
HTTP 400- เราไม่สามารถบอกได้ว่าคุณต้องการทรัพยากรอะไร แก้ไข URL ของคุณ
HTTP 500- เราทำงานผิดปกติ ไม่ใช่ความผิดของคุณ.

ดูRFC 2616 Sec 10 ตามความเหมาะสม

— เทรวิสวิลสัน
แหล่งที่มา

ฉันเห็นด้วยกับสิ่งที่คุณทำ ถ้าเซิร์ฟเวอร์ส่งคืน 404 นั่นจะสมเหตุสมผลมากกว่าที่ทำ (500) ขอขอบคุณ.

— JYelton

11

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

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

ฉันจะปฏิบัติต่อทั้งสองตัวอย่างของคุณ ( http://example.com/restapi/deviceinfo?id=123และhttp://example.com/restapi/device/123/info) เหมือนกัน - 123คือพารามิเตอร์ ทั้งสองกรณีเป็นวิธีที่แตกต่างกันในการจัดโครงสร้างคำร้องขอเพื่อรับข้อมูลอุปกรณ์สำหรับอุปกรณ์ที่มี ID 123

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

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

หากพารามิเตอร์ทั้งหมดถูกต้องฉันจะเริ่มดำเนินการตามคำขอ หากระบบหรือการพึ่งพาใด ๆ (ฐานข้อมูลบริการของบุคคลที่สามและบริการภายในอื่น) ใช้งานไม่ได้ฉันจะส่งคืนรหัส 5xx - 503 จะเฉพาะเจาะจง แต่ 500 ก็จะยอมรับได้ ไม่ว่าในกรณีใดฉันจะส่งคืนเนื้อหาพร้อมรายละเอียดเพิ่มเติม โปรดพิจารณาว่าหากผู้อ้างอิงภายนอกรายงานการร้องขอการหมดเวลา 408 ฉันจะกินสิ่งนั้นและส่งคืน 500 ให้กับลูกค้าของฉันเพื่อให้ลูกค้าได้รับ 408 เฉพาะเมื่อการร้องขอไปยังระบบของฉันหมดเวลา หากระบบสามารถดำเนินการตามคำขอฉันจะส่งคืน 200 และเนื้อหาที่เหมาะสม

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

เวลาเดียวที่จะส่งคืน 404 คือถ้าเซิร์ฟเวอร์ไม่มี/deviceinfoจุดปลายหรือ/device/:id/infoจุดปลาย

ฉันจะไม่พิจารณา ID ที่ไม่พบว่าเหมือนกับทรัพยากรที่ไม่พบ ทรัพยากรคือข้อมูลอุปกรณ์สำหรับอุปกรณ์เฉพาะ (ในตัวอย่างของคุณ) การส่งคืน 404 หมายความว่าไม่มีทรัพยากร (ข้อมูลอุปกรณ์) อยู่ 200 ตัวที่เหมาะสมหมายความว่าระบบสามารถให้ข้อมูลอุปกรณ์ได้ อาจมีหรือไม่มีอุปกรณ์ที่มีรหัสที่ระบุ

— โทมัสโอเวนส์
แหล่งที่มา

1

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

— โธมัสโอเวนส์

2

ถ้าผมกำลังออกแบบ API นี้ที่ฉันสอบถามผมจะได้มันกลับมา 200 device: 123; status: not found;กับร่างกายนั้นมีบางสิ่งบางอย่างเพื่อผลของการที่ จากนั้นฉันก็รู้ว่าคิวรีทำงานได้และ API กำลังบอกข้อมูลที่เป็นประโยชน์

— JYelton

7

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

— mbrig

6

Http ไม่มีแนวคิดของ 'ปลายทาง' ไม่มีความแตกต่างที่เกี่ยวข้องระหว่างตัวแปรและส่วนที่เหลือของ URL และดังนั้นจึงไม่เหลือ คุณอาจมีระบบการจัดเส้นทางหนึ่งระบบที่จับคู่กับ regex และกำหนดเส้นทาง URL หลายพันรายการไปยังฟังก์ชันคอนโทรลเลอร์หนึ่งรายการ แต่นั่นเป็นรายละเอียดการนำไปใช้งานไม่ใช่ส่วนพื้นฐานของ API การตอบสนอง 200 ครั้งบนการรับจะใช้สำหรับเคสเท่านั้นเมื่อทรัพยากรที่ร้องขอถูกเรียกคืน ในกรณีนี้ลูกค้าต้องการเป็นตัวแทนของทรัพยากรที่ไม่มีอยู่ดังนั้น 404 จึงเป็นการตอบสนองที่ถูกต้อง

— bdsl

8

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

— bdsl

5

ข้อผิดพลาด HTTP 500 series ระบุว่าเซิร์ฟเวอร์ทำงานผิดปกติ นอกเหนือจาก501 Not Implementedและการ505 HTTP Version Not Supportedใช้รหัสข้อผิดพลาดเหล่านี้ยังมีความหมายที่ลองอีกครั้งในภายหลังอาจประสบความสำเร็จ (แม้ว่าจะ503 Service Unavailableระบุไว้อย่างชัดเจนเท่านั้น) ตามหลักแล้วเซิร์ฟเวอร์ไม่ควรสร้างรหัสใดรหัสหนึ่งถึงแม้ว่าการไม่สามารถเขียนซอฟต์แวร์ที่ไม่มีบั๊กและจัดหาเซิร์ฟเวอร์ที่มีทรัพยากรไม่สิ้นสุดหมายความว่าคุณจะต้องใช้รหัสเหล่านี้เป็นครั้งคราว

สำหรับผลลัพธ์ "วัตถุไม่มีอยู่" คุณควรส่งคืนอย่างใดอย่างหนึ่ง404 Not Found(เมื่อคำขอสำหรับวัตถุตามชื่อ) หรือ200 Successด้วยเนื้อหาผลลัพธ์ว่างเปล่า (เมื่อค้นหาวัตถุด้วยแอตทริบิวต์) 204 No Contentดูน่าดึงดูดใจ แต่ฉันจะใช้มันเฉพาะในสถานการณ์ที่ร่างกายขาดการตอบสนองเป็นผลลัพธ์ที่คาดหวัง

— เครื่องหมาย
แหล่งที่มา

1

ในฐานะลูกค้าของ API ของคุณเมื่อฉันทำการโทรอย่างใดอย่างหนึ่ง:

http://example.com/restapi/deviceinfo?id=123
http://example.com/restapi/device/123/info

ฉันคาดหวังว่าจะได้DeviceInfoวัตถุ (หรือตัวแทนบางประเภท) กลับมาไม่ว่าจะเป็นประเภทที่เป็นทางการหรือบางสิ่งบางอย่างที่สอดคล้องกับแบบแผน "เป็ดประเภท" ที่จัดทำเป็นเอกสาร) ฉันต้องการ200สถานะหมายความว่าฉันได้รับจริงและฉันสามารถไปข้างหน้าและใช้งานได้

สำหรับ REST APIs ฉันคิดว่ารหัส 400 และ 500 เป็นสิ่งที่คล้ายข้อยกเว้น คุณใช้พวกเขาเพื่อระบุว่าเมื่อใดที่คุณไม่สามารถตอบกลับคำขอ "ปกติ" สำหรับคำขอที่คุณได้รับดังนั้นลูกค้าจะต้องทำสิ่งที่พิเศษแทนที่จะประมวลผลข้อมูลที่คาดว่าจะได้รับ

ซึ่งหมายความว่าในฐานะผู้ใช้ API ฉันสามารถใช้ฟังก์ชั่นตรวจสอบส่วนที่เหลือที่ดึงข้อมูลการตอบกลับหรือส่งข้อยกเว้น เยี่ยมมาก ตรรกะปกติของฉันสามารถเป็นรหัสเส้นตรงและฉันสามารถจัดระเบียบข้อผิดพลาดการจัดการของฉันแบบเดียวกับที่ฉันทำในรหัสท้องถิ่น 404s ที่ไม่คาดคิดจะปรากฏเป็นข้อยกเว้น "ไม่พบทรัพยากร" โดยที่ฉันไม่ต้องทำอะไรเลยไม่ใช่ข้อผิดพลาด "แอตทริบิวต์ที่ขาดหายไป" เมื่อฉันประมวลผลในภายหลัง{ errorMessage: "Device 123 not found" }ราวกับว่ามันเป็นDeviceInfoวัตถุ

หากคุณด้วยเหตุผลที่ว่าปลายทางhttp://example.com/restapi/deviceinfo จะพบและเป็นเพียงid=123ที่ไม่ได้และเพื่อให้กลับมา 200 ด้วยข้อผิดพลาดในร่างกายแล้วคุณกำลังสร้างตรงชนิดเดียวกันของปัญหาอินเตอร์เฟซที่เป็นฟังก์ชั่นซีที่จะกลับมาอย่างใดอย่างหนึ่ง ผลลัพธ์ที่ถูกต้องหรือรหัสข้อผิดพลาดหรือวิธีการที่ระบุปัญหาโดยการส่งคืนโดยพลการnull. มันเป็นเรื่องที่ดีกว่าในฐานะผู้ใช้อินเทอร์เฟซของคุณที่จะมีข้อผิดพลาดที่ระบุผ่านช่อง "แยก" จากการส่งคืนปกติ สิ่งนี้ก็มีผลเช่นกันแม้ว่า HTTP 200, 404 และ 500 การตอบกลับเป็นช่องทางเดียวกันจากมุมมองระดับต่ำ พวกเขาได้มาตรฐานและง่ายต่อการแยกออกจากกันดังนั้นเฟรมเวิร์กไคลเอ็นต์ REST ของฉันสามารถสลับสถานะเหล่านั้นเพื่อเปลี่ยนให้เป็นโครงสร้างที่เหมาะสมในภาษาของฉัน เพื่อทำสิ่งเดียวกันกับเลเยอร์ JSON (ที่คุณพูด 200 และให้ข้อความฉันDeviceInfoหรือข้อความแสดงข้อผิดพลาด) ฉันต้องฝังความรู้เกี่ยวกับสกีมา JSON ที่คุณใช้

ดังนั้นใช้ 200 เมื่อคุณสามารถส่งคืนค่าที่ถูกต้องของประเภทที่คาดหวัง (ซึ่งเป็นสาเหตุที่http://example.com/restapi/search-devices?colour=blueสามารถส่งคืน 200 กับอาเรย์ที่ว่างเปล่าหากไม่มีอุปกรณ์สีฟ้าอาเรย์ที่ว่างเปล่าเป็นอาเรย์ที่ถูกต้องและคำตอบที่สมเหตุสมผล ต้องการรายละเอียดของอุปกรณ์สีน้ำเงินทั้งหมด ") หากคุณไม่สามารถทำได้ให้ใช้รหัสสถานะที่ไม่ใช่ 200 ที่เหมาะสมที่สุด แม้ว่า "ไม่มีอุปกรณ์ 123" คือการตอบสนองที่ถูกต้อง "ให้รายละเอียดของอุปกรณ์ 123" และไม่ใช่ข้อผิดพลาดสำหรับเซิร์ฟเวอร์มันเป็นข้อยกเว้นสำหรับความคาดหวังของลูกค้าว่าพวกเขาจะกลับมาDeviceInfoและควร ไม่สามารถสื่อสารได้ตามปกติ "นี่คือสิ่งที่คุณขอ" การตอบสนอง

— เบน
แหล่งที่มา

น่าเสียดายที่ฉันเป็นลูกค้าของ API นี้และไม่สามารถเปลี่ยนได้ นี่เป็นบทสรุปที่ยอดเยี่ยมว่าควรทำงานอย่างไร

— JYelton

0

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

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

4

บทความนี้อธิบายการใช้ 422 โดยละเอียดยิ่งขึ้น ฉันไม่คิดว่ารหัสข้อผิดพลาดนี้สามารถใช้งานได้จริงที่นี่

— Robert Harvey

ขอบคุณมีประโยชน์มาก! ฉันจะต้องลึกซึ้งยิ่งขึ้นในเรื่องนี้!

— FiNeX

0

ข้อผิดพลาด 500 ตามปกติระบุว่าคำขอขัดข้องโปรแกรมฝั่งเซิร์ฟเวอร์ ในสภาพแวดล้อมขององค์กรข้อผิดพลาดเหล่านี้จะถือว่าเป็นไข่ในหน้าและจะถูกหลีกเลี่ยง

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

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

1

ดังนั้นคุณกำลังพูดว่า "อย่าใช้ 500 เพราะคุณไม่ได้ทำงานล้มเหลวในเซิร์ฟเวอร์"

— Robert Harvey

0

แม้ว่า w3 จะบันทึกว่ามีการใช้ 404 เมื่อไม่มีการตอบสนองอื่น ๆ แต่จะเป็นการตอบสนองที่ 204 (ไม่มีเนื้อหา) หรือไม่ คำร้องขอนั้นถูกต้องจากมุมมองการประมวลผลและเซิร์ฟเวอร์ประมวลผลคำร้องขอและมีผลลัพธ์ นั่นคือความสำเร็จซึ่งโน้มเอียงไปสู่การตอบกลับ 2xx ไม่มีเนื้อหาสำหรับคำขอนี้ดังนั้น 204 จึงบอกผู้ใช้ว่าไม่มีข้อผิดพลาดในการสืบค้น แต่ไม่มีอะไรเกิดขึ้น

คุณสามารถสร้างกรณีที่อ่อนแอได้ว่า 409 (ความขัดแย้ง) เป็นการตอบสนองที่เหมาะสม แม้ว่า 409 มักใช้สำหรับโพสต์ แต่ก็พูดว่า

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

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

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

3

ไม่ 204 การตอบสนองต่อคำขอที่ได้รับจะสมเหตุสมผลเมื่อทรัพยากรที่ร้องขอถูกพบและการแสดงนั้นมีความยาวศูนย์อักขระ

— bdsl

0

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

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

-4

ผู้ใช้รายอื่นให้คำตอบที่ถูกต้องสำหรับสิ่งที่ต้องทำถ้าคุณต้องการไปโดยหนังสือ

อย่างไรก็ตามฉันขอแนะนำว่าคุณกำลังอ่าน RESTfulness มากเกินไปและมีความเพียวอย่างแท้จริงด้วยความเคารพ

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

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

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

ดังนั้นบรรทัดล่างคือฉันขอแนะนำให้ส่งคืน "HTTP 200 OK" และภายในส่วนของการตอบสนอง ("เนื้อหาเนื้อหาการตอบสนอง" ใน HTTP parlance) มีรหัสข้อผิดพลาดเฉพาะแอปพลิเคชันที่ระบุว่า "ID ไม่พบ" หรืออะไรก็ตาม

— ไมค์นากิส
แหล่งที่มา

ตัดสินโดย downvotes ฉันคิดว่าฉันต้องทำร้ายความรู้สึกของบางคน หรืออาจเป็นส่วนอื่นของร่างกาย C -: =

— Mike Nakis

พวกเขาควรอ่านสิ่งนี้จริง ๆ : blogs.dropbox.com/developers/2015/04/…

— Mike

1

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

— cHao

@cHao ดังนั้นฉันคิดว่าส่วนที่ระบุว่า "ปัจจุบัน Dropbox ใช้รหัสสถานะแตกต่างกันประมาณ 10 รหัส (ข้อผิดพลาด 8 ข้อและ 2 เพื่อความสำเร็จ) แต่เรากำลังวางแผนที่จะลดจำนวนนั้นใน API รุ่นอนาคต" ไม่ได้มีความหมายอะไรเลย คุณ.

— Mike Nakis

ไม่ได้หมายถึงสิ่งที่คุณได้รับจากมัน หากพวกเขารู้ว่าพวกเขากำลังทำอะไรอยู่สุดขั้วพวกเขาจะลดความสำเร็จลงหนึ่งรหัสข้อผิดพลาดสี่ตัว (400, 401, 404 และ 500) เพราะพวกเขาสนใจการประชุม

— cHao