การออกแบบ RESTful API ฉันจะกลับมาได้อย่างไรหากไม่มีแถว?

50

ขณะนี้ฉันกำลังเขียนรหัส API สำหรับเครือข่ายสังคมด้วย Slim Framework คำถามของฉันคืออะไรแนวปฏิบัติที่ดีที่สุดเมื่อไม่มีแถวที่จะส่งคืนในโครงสร้าง json คืออะไร

ให้บอกว่าการโทรนี้/ v1 / get / ภาพยนตร์ส่งคืน 2 แถวจากชื่อภาพยนตร์ตาราง:

[
    {"name": "Ghostbusters"},
    {"name": "Indiana Jones"}
]

แต่ฉันโทรหา/ v1 / get / หนังสือและไม่มีแถวในตารางนั้น ฉันควรคืนโครงสร้างว่างเปล่าไหม

[
]

... หรือว่าจะเป็นข้อความและรหัสข้อผิดพลาดดีกว่า

[
    "errors": {
        "message": "no matches found",
        "code": 134
    }
]

ข้อปฏิบัติที่ดีกว่าคืออะไร (API จะใช้ในแอพ iOS และ Android) ขอบคุณ!

— Andres SK
แหล่งที่มา

3

สำหรับฉันแล้วนี่รู้สึกเหมือนคำถามว่าศูนย์มียอดจริงหรือเปล่า

— scarfridge

16

ตัวอย่างของคุณเสีย คุณไม่สามารถมีวัตถุ json ที่มีคีย์ซ้ำกันได้ สิ่งที่คุณกำลังมองหาคืออาร์เรย์เช่น[{"name": "..."}, {"name":"..."}]

— Martin Wickman

@MartinWickman ขอโทษที่ฉันเพิ่งแก้ไข

— Andres SK

8

@andufo จริงคุณไม่ได้ ...

— avakar

25

หากแอปพลิเคชันของคุณตั้งใจที่จะสงบแล้วกริยา / เมธอด "รับ" เป็นส่วนหนึ่งของ URI ปลายทางของคุณทำไม

— user50849

46

โดยปกติแล้วฉันจะส่งกลับจำนวนระเบียนในผลลัพธ์เป็นเมตาดาต้า ฉันไม่แน่ใจว่านี่เป็นแบบฝึกหัด REST ปกติหรือไม่ แต่เป็นข้อมูลที่ไม่มากนักและแม่นยำมาก โดยปกติจะมีการแบ่งหน้าสำหรับบริการจำนวนมากมันเป็นไปไม่ได้ที่จะส่งคืนชุดผลลัพธ์ขนาดใหญ่พร้อมกัน ส่วนตัวผมรู้สึกรำคาญเมื่อมีเลขชุดผลขนาดเล็ก .. ถ้ามันเป็นที่ว่างเปล่ากลับและหนังสือเป็นรายการที่ว่างเปล่าnumber_of_records : 0 / อาร์เรย์books : []

{
    meta: {
        number_of_records : 2,
        records_per_page : 10,
        page : 0
    },
    books : [
        {id:1},
        {id:27}
    ]
}

แก้ไข (ไม่กี่ปีต่อมา): คำตอบจาก Martin Wickman ดีกว่ามากนี่คือคำอธิบายสั้น ๆ ว่าทำไม

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

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

หากคุณมีข้อมูลมากเกินไปที่จะประมวลผลพร้อมกันให้ลองส่งคืน "รายการ id" พร้อมผลลัพธ์และรายละเอียดทั้งหมดสำหรับบางส่วนของรายการนั้นและจัดเตรียมการเรียก API แบบ multi_get / get_by_id_list

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

1

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

— Izkata

1

-1 เนื่องจากbooksพารามิเตอร์เป็นวัตถุ แต่ 'หนังสือ' มีความหมายมากกว่าหนึ่งอย่างและมากกว่าหนึ่งหมายถึงอาร์เรย์ ข้อมูลเมตานั้นเจ๋งและทั้งหมด แต่ในที่สุดฉันก็คาดหวังว่าหนังสือจะเป็นชุดของวัตถุหนังสือ หากไม่มีหนังสือให้ฉันจัดแถวที่ว่างเปล่าให้ฉัน

— Charles Sprayberry

9

ปัญหาเกี่ยวกับสิ่งนี้คือการเพิ่ม "number_of_records" ไม่ได้ให้ข้อมูลเพิ่มเติมใด ๆ แต่เป็นการเพิ่มความซ้ำซ้อนและเพิ่มความซับซ้อน หากต้องการส่งสัญญาณข้อผิดพลาดให้ส่งคืนรหัส http ที่เหมาะสม + บางอย่างในร่างกาย

— Martin Wickman

1

@cspray หนังสือเป็นรายการตามที่ Izkata ชี้พิมพ์ผิดของฉัน

— grizwako

2

@MartinWickman ฉันไม่ต้องการที่จะสร้างมลภาวะคำตอบเดิมด้วยข้อมูลเมตาเพิ่มเติม แต่จากประสบการณ์ของฉันบริการจำนวนมากไม่ได้ส่งคืนข้อมูลทั้งหมดทันที แต่ด้วยวิธีการ "เลขหน้า"

— grizwako

105

ตัวอย่างของคุณเสีย คุณไม่ควรมีวัตถุ json ที่มีคีย์ซ้ำกัน สิ่งที่คุณกำลังมองหาคืออาร์เรย์ที่มีวัตถุภาพยนตร์เช่นนี้:

 [
    {"name": "movie1"}, 
    {"name": "movie2"}
 ]

วิธีการนี้ยังตอบคำถามของคุณ คุณควรคืนอาเรย์ที่ว่างเปล่าเมื่อเคียวรีไม่ตรงกับ:

[]

ในทางกลับกันหากคุณพยายามรับทรัพยากรภาพยนตร์ที่เฉพาะเจาะจงGET api/movie/34และไม่มีภาพยนตร์นั้นให้ส่งคืน 404 ด้วยข้อผิดพลาดที่เหมาะสม (เข้ารหัส json) ในเนื้อหา

— Martin Wickman
แหล่งที่มา

1

1 นี้เป็น JSON json_xsที่ถูกต้องตาม

— l0b0

15

ถ้านี่คือ JSON คุณควรพิจารณาคืน Array of objects สิ่งนี้มีข้อดีหลายประการรวมถึงเมื่อคุณไม่มีระเบียนมันเป็นอาร์เรย์ว่างเปล่า

ดังนั้นเมื่อคุณมีบันทึกคุณจะกลับมา:

    [
        {"name": "Ghostbusters"},
        {"name": "Indiana Jones"}
    ]

และเมื่อคุณไม่มีบันทึกคุณจะกลับมา:

    [

    ]

— Devdatta Tengshe
แหล่งที่มา

14

หากคุณดำเนินการสำเร็จ แต่ไม่มีอะไรที่จะกลับมาเช่น map ที่{}ว่างเปล่าหรือ array ที่ว่างเปล่า[]ฉันต้องการที่จะตอบสนองด้วยรหัสตอบรับ 204 นี่คือข้อความที่ตัดตอนมาจากข้อกำหนดสถานะรหัสสถานะ HTTP :

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

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

การตอบสนอง 204 ต้องไม่รวมเนื้อหาของข้อความและทำให้ถูกยกเลิกโดยบรรทัดว่างแรกเสมอหลังจากฟิลด์ส่วนหัว

โดยพื้นฐานแล้วฉันแนะนำให้ใช้ 204 ในแอปพลิเคชั่น RESTful ผ่าน HTTP เมื่อไม่มีอะไรให้คืน

— เดวิดเซอร์เกย์
แหล่งที่มา

4

ฉันเห็นด้วยกับความคิดเห็นของ @ avakar สำหรับคำตอบอื่น ๆ ที่นี่ หากลูกค้าพยายามเข้าถึง / v1 / get / movies / 1 ก็ควรคืนค่า 404 หากไม่มีภาพยนตร์ที่สามารถระบุได้ด้วย 1 เพียงแค่ / v1 / get / movies ควรคืน 200 ถ้าไม่มีภาพยนตร์ แต่ 204 ไม่เหมาะเพราะมีไว้สำหรับการดำเนินการอินพุต

— imel96

7

ปัญหาอีกข้อหนึ่งของการแก้ปัญหานี้คือโดยทั่วไปแล้วมันจะต้องใช้รหัสพิเศษในไคลเอนต์: หากการตอบสนองเป็นรายการว่างเปล่าก็สามารถแยกวิเคราะห์เป็น JSON เช่นเดียวกับการตอบสนองปกติ หากการตอบสนองเป็นเนื้อหาที่ว่างเปล่าตัวแยกวิเคราะห์ JSON น่าจะบ่น (เพราะเอกสาร emtpy ไม่ถูกต้อง JSON) ดังนั้นลูกค้าต้องการรหัสพิเศษเพื่อตรวจสอบ HTTP 204 และข้ามการแยกวิเคราะห์

— sleske

7

ผมเชื่อว่านี่เป็น misreading ของความตั้งใจที่ 204 204 ปรากฎขึ้นมาจะตั้งใจไม่ได้สำหรับการดำเนินงานที่คาดว่าเนื้อหาและล้มเหลวที่จะพบใด ๆ แต่สำหรับการดำเนินงานที่ประสบความสำเร็จและมีผลตอบแทนไม่ตั้งใจ จากวิกิพีเดีย: "เซิร์ฟเวอร์ประมวลผลคำขอเรียบร้อยแล้ว แต่ไม่ได้ส่งคืนเนื้อหาใด ๆ โดยปกติจะใช้เป็นการตอบกลับคำขอลบที่สำเร็จ"

— XML

10

ได้มีจำนวนที่เหมาะสมของงานที่ทำเกี่ยวกับการสร้างมาตรฐานรูปแบบ JSON API

การทำตามหลักการในสเปคนั้นหมายความว่าทรัพยากรทั้งหมดที่ส่งคืนควรเป็น "คอลเลกชัน" อย่างมีประสิทธิภาพ (แม้ว่าจะรวมอยู่ในทรัพยากรเดียว) การทำตามนี้จะหมายความว่าการโทรของคุณ/v1/get/moviesจะกลับมา:

{
    "movies": [
        {"name": "Ghostbusters"},
        {"name": "Indiana Jones"}
    ]
}

การโทรไปยัง/v1/get/books(ซึ่งส่งกลับศูนย์ทรัพยากร) จะกลับมา:

{
    "books": []
}

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

5

สำหรับตัวอย่างเฉพาะของคุณฉันขอแนะนำว่า / v1 / get / books ควรคืนค่า HTTP 200 ด้วยอาเรย์ที่ว่างเปล่า

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

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

เหตุผลที่ฉันไม่แนะนำให้ส่งคืน HTTP 204 คือสิ่งนี้จะแนะนำว่า "ไม่มีเนื้อหา" เป็นสภาวะปกติ: การดำเนินการกับทรัพยากรนี้ตามปกติจะไม่ส่งคืนสิ่งใด นั่นเป็นสาเหตุที่มักใช้เป็นคำตอบสำหรับคำขอลบตัวอย่างเช่นลักษณะการลบโดยทั่วไปหมายความว่าไม่มีอะไรเหลือให้คืน กรณีนี้จะคล้ายกันเมื่อใช้เพื่อตอบสนองต่อคำขอที่มีตระกูลส่วนหัว If-Modified: คุณต้องการเนื้อหาเฉพาะเมื่อทรัพยากรมีการเปลี่ยนแปลง แต่ไม่ได้ดังนั้นฉันจะไม่ให้เนื้อหาใด ๆ แก่คุณ

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

— The Spooniest
แหล่งที่มา

5

คุณควรทำเพียงหนึ่งในสองสิ่งเท่านั้น

อาจส่งคืน200 (OK)รหัสสถานะและอาร์เรย์ที่ว่างเปล่าในเนื้อความ

หรือส่งคืน204 (NO CONTENT)รหัสสถานะและไม่มีเนื้อหาตอบกลับ

สำหรับฉันตัวเลือก 2 ดูเหมือนว่าถูกต้องมากขึ้นในทางเทคนิคและสอดคล้องกับหลักการ REST และ HTTP

อย่างไรก็ตามตัวเลือก 1 ดูเหมือนว่ามีประสิทธิภาพมากขึ้นสำหรับลูกค้า - เนื่องจากไคลเอนต์ไม่จำเป็นต้องมีตรรกะเพิ่มเติมเพื่อแยกความแตกต่างระหว่างรหัสสถานะสอง (สำเร็จ) เนื่องจากมันรู้ว่ามันจะได้รับอาเรย์เสมอมันจึงต้องตรวจสอบว่ามันได้รับไม่มีรายการใดรายการหนึ่งหรือหลายรายการและดำเนินการอย่างเหมาะสม

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

3

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

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

3

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

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

ไม่มี "การปฏิบัติที่ดีที่สุด" ที่นี่ทั้งตัวอย่างของคุณโดยพลการเพียงแค่เลือกหนึ่งและมีความสอดคล้อง นักพัฒนาเกลียดความประหลาดใจหาก/v1/get/moviesผลตอบแทน{}เมื่อไม่มีภาพยนตร์เราคาดหวังว่า/v1/get/actorsจะกลับมาอีก{}เมื่อไม่มีนักแสดง

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

1

การส่งคืน 404 เป็นสิ่งที่ถูกต้อง แต่น่าเสียดายที่ไม่มีใครทำเช่นนั้น - ตัวเองรวมอยู่ด้วย

— RibaldEddie

1

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

— devnull

5

ฉันไม่เห็นด้วยกับข้อความ 404 A 404 ฉันจะตีความว่า "ไม่มีทรัพยากร" และกังวลถ้าฉันมีบางอย่างผิดปกติกับ URL ของฉันหรืออะไรก็ตาม ถ้าฉันขอรายการภาพยนตร์และรับ 404 ฉันจะคิดว่าไม่มีทรัพยากรภาพยนตร์เลย "204 ไม่มีเนื้อหา" อาจเหมาะสมกว่า

— thorsten müller

8

ตกลงสิ่งที่ "ไม่มีร่างกาย" จะฆ่ามัน แต่: "รหัสสถานะคลาส 4xx มีไว้สำหรับกรณีที่ลูกค้าดูเหมือนจะผิดพลาด" แต่ไม่มีข้อผิดพลาดทางฝั่งไคลเอ็นต์ ดังนั้น 404 จึงให้ข้อมูลที่ผิด ส่ง 204 โดยไม่มีเนื้อความหรือพูดว่าใช้ได้และส่งรายการว่าง

— thorsten müller

9

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

— avakar

1

ฉันไม่คิดว่าคำตอบที่ถูกต้องคือคำตอบที่ถูกทำเครื่องหมาย

คำตอบที่ได้จาก nirth ควรเป็นคำตอบที่ดีที่สุดในสถานการณ์ REST จริง การตอบสนองของร่างกายควรว่างเปล่าและรหัสสถานะ http: 204; ทรัพยากรมีอยู่ แต่มี "ไม่มีเนื้อหา" ในเวลานั้น: ว่างเปล่า

REST HTTP_Status_Codes

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

1

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

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

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

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

0

ฉันจะ "ขึ้นอยู่กับ"

ถ้า zero เป็นผลลัพธ์ที่สมเหตุสมผลให้ส่งคืนรายการเปล่า ตัวอย่างเช่นหากคุณต้องการให้พนักงานทุกคนเรียกว่า "bob" โดยที่ "none" นั้นเป็นผลลัพธ์ที่สมเหตุสมผล หากไม่ใช่ผลลัพธ์ที่คาดหวังให้ส่งคืนข้อผิดพลาด ตัวอย่างเช่นการรับรายการที่อยู่ทางประวัติศาสตร์ของที่อยู่สำหรับคนที่คุณจ้าง .. พวกเขาจะต้องอยู่ที่ไหนสักแห่งดังนั้นผลลัพธ์ที่ได้อาจเป็นข้อผิดพลาดไม่ใช่เพียงแค่สภาพปกติ

ฉันแน่ใจว่าคุณสามารถโต้เถียงกับตัวอย่างเฉพาะของฉัน แต่คุณได้รับความคิด ...

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

0

ก่อนอื่นการมีgetURL ของคุณไม่ได้สงบอยู่เสมอ GET ใช้วิธี HTTP
หากคุณขอคอลเลกชันเช่นGET api/moviesผลตอบแทน200 OKกับ []array
หากคุณกำลังขอเป็นหนังที่เฉพาะเจาะจงเช่นGET api/movies/1(ที่1เป็น ID) 404 Not Foundและมันไม่ได้อยู่กลับ

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

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

-2

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

— ชิโน
แหล่งที่มา