JSON ควรรวมค่า null [ปิด]

89

ปิด . คำถามนี้เป็นคำถามความคิดเห็นตาม ขณะนี้ยังไม่ยอมรับคำตอบ

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

ปิดให้บริการใน2 ปีที่ผ่านมา

ฉันกำลังสร้าง API ที่แสดงผลลัพธ์เป็น JSON มีแนวทางปฏิบัติที่ดีที่สุดในปัจจุบันหรือไม่ว่าเราควรรวมคีย์ในผลลัพธ์เมื่อค่าเป็นโมฆะ ตัวอย่างเช่น:

{
    "title":"Foo Bar",
    "author":"Joe Blow",
    "isbn":null
}

หรือ

{
    "title":"Foo Bar",
    "author":"Joe Blow"
}

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

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

6

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

— เจย์

@Jacob แม้ว่าฉันจะไม่ได้พูดมัน แต่ความตั้งใจของฉันกับคำถามนี้ก็คือ JSON "เต็ม" ที่เป็นตัวแทนของการตอบกลับกำลังถูกส่งกลับ เมื่อลูกค้าสามารถสันนิษฐานได้ว่าดูเหมือนจะไม่มีความแตกต่างในการทำงานระหว่างสองแนวทาง หาก API เลือกที่จะไม่ส่งคืนคีย์ / ค่าใช่มันจะสร้างความแตกต่างอย่างมากว่าจะใช้แนวทางใด

— jjathman

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

— Surya Pratap

ฉันคิดว่าไม่มีอะไรให้ความเห็นเกี่ยวกับคำถามนี้ JSON เป็นมาตรฐาน ควรมีข้อกำหนดสำหรับมันและอาจเป็นกลุ่มของ RFC // ยิ่งไปกว่านั้นแม้แต่คำถามที่แสดงความคิดเห็นก็สามารถยอมรับได้ มีการพูดคุยเกี่ยวกับเรื่องนี้มาก่อนใน meta.stackexchange ซึ่งพวกเขาตัดสินว่าคำถามที่แสดงความคิดเห็นเป็นเรื่องปกติจากการแบ่งปัน "แนวทางปฏิบัติที่ดีที่สุด"

— bvdb

32

อย่างที่สองจะช่วยประหยัดแบนด์วิดท์ได้เล็กน้อย แต่หากเป็นปัญหาคุณจะใช้อาร์เรย์ที่จัดทำดัชนีแทนการกรอก JSON ด้วยคีย์ เห็นได้ชัดว่า["Foo Bar","Joe Blow"]สั้นกว่าที่คุณมีอยู่ตอนนี้มาก

ในแง่ของการใช้งานฉันไม่คิดว่ามันสร้างความแตกต่าง ในทั้งสองกรณีif(json.isbn)จะข้ามไปที่ไฟล์else. โดยปกติไม่จำเป็นต้องแยกแยะระหว่างnull(ไม่มีค่า) และundefined(ไม่มีค่าที่ระบุ)

— Niet the Dark Absol
แหล่งที่มา

7

+1 โดยทั่วไปไม่จำเป็นต้องแยกความแตกต่างระหว่าง null (ไม่มีค่า) และไม่ได้กำหนด (ไม่มีค่าที่กำหนด) มีแม้แต่ตัวดำเนินการที่สะดวกสำหรับมัน!= null(ไม่ได้ตั้งใจ)

— Esailija

กรณีเดียวที่ฉันคิดได้คือการทดสอบว่าเบราว์เซอร์รองรับเหตุการณ์บางประเภทหรือไม่ ตัวอย่างเช่นif( typeof onbeforepaste == "undefined")เพื่อดูว่าonBeforePasteรองรับหรือไม่ แม้ว่าจะไม่ได้สร้างความแตกต่างอย่างแท้จริงเนื่องจากคุณสามารถกำหนดกิจกรรมทั้งหมดที่คุณต้องการได้ (พวกเขาจะไม่ทำอะไรเลยหากไม่ได้รับการสนับสนุน)

— Niet the Dark Absolute

6

ในแง่ของการบันทึกไบต์ที่โอนการบีบอัดมีความสำคัญมากกว่าสิ่งต่างๆเช่นอาร์เรย์ที่จัดทำดัชนี web-resource-optimization.blogspot.no/2011/06/…ให้แน่ใจว่าเป็นสิ่งแรกที่คุณทำ ในกรณีส่วนใหญ่การเพิ่มสิ่งต่างๆเช่นอาร์เรย์ที่จัดทำดัชนีไว้ด้านบนนั่นคือสิ่งที่ฉันเรียกว่าการเพิ่มประสิทธิภาพก่อนกำหนด เว้นแต่คุณจะส่งข้อมูลจำนวนมาก นอกจากนี้ยังต้องมีการแยกวิเคราะห์เพิ่มเติมเพิ่มความซับซ้อนให้กับแอปของคุณ เบราว์เซอร์ทำ Gzipping ได้อย่างราบรื่น (สมมติว่าลูกค้าเป็นเบราว์เซอร์)

— Martin Hansen

3

เนื่องจาก HTTPS กลายเป็นบรรทัดฐานของวันนี้ (อย่างน้อยก็สำหรับแอปที่มีฐานผู้ใช้ขนาดใหญ่) การบีบอัดจึงต้องเปลี่ยนไป ดูen.wikipedia.org/wiki/CRIME_%28security_exploit%29

— Gaurav Vaish

6

ที่จริงฉันจะ -1 สิ่งนี้สำหรับ "โดยทั่วไปไม่จำเป็นต้องแยกความแตกต่างระหว่างค่าว่าง" ถ้าฉันมีชื่อเสียง จาก 2 เหตุผล 1. เหตุผลที่แยกแยะว่ามีอยู่และไม่ใช่ของหายาก 2. แนวทางปฏิบัติที่ดีที่สุดคือการมีค่าที่ "กำหนดไว้อย่างดี" เสมอนั่นหมายถึงการป้องกันความคลุมเครืออยู่เสมอ - 2 ความหมายของ 1 ค่าคือความชั่วร้ายเสมอ - ควรจะค่อนข้างชัดเจน ..

— Srneczek

80

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

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

ควรระบุด้วยว่าฟังก์ชัน hasOwnProperty ของ javascript จะช่วยให้คุณเข้าใจมากขึ้น

/* if true object DOES contain the property with *some* value */
if( objectFromJSON.hasOwnProperty( "propertyName" ) )

/* if true object DOES contain the property and it has been set to null */
if( jsonObject.propertyName === null )

/* if true object either DOES NOT contain the property
   OR
   object DOES contain the property and it has been set to undefined */
if( jsonObject.propertyName === undefined )

— รัชเคลดอน
แหล่งที่มา

3

แน่นอนว่าผู้คนจำนวนมากขึ้นต้องเข้าใจความแตกต่างระหว่าง "", null และ undefined คำตอบสำหรับคำถามนี้ขึ้นอยู่กับความต้องการของผู้ใช้

— เจย์

13

+1. บุคคลที่อยู่อีกด้านหนึ่ง (ผู้เขียนโค้ด) จะได้รับการบริการที่ดีกว่าด้วยค่าที่ชัดเจน พวกเขาอาจไม่ได้เขียน JavaScript ;-)

— Steve11235

2

โปรดทราบว่าการตรวจสอบค่า null ใช้ไม่ได้กับ ==, === เป็นสิ่งจำเป็น (เนื่องจากไม่ได้กำหนด == null)!

— Tommy

ส่วนแรกของคำตอบที่ยอมรับนั้นผิดมาก ...

— Srneczek

ฉันจะเขียน"propertyName" in objectFromJSONแทนobjectFromJSON.hasOwnProperty("propertyName"). นอกจากนี้หากคุณยืนยันที่จะใช้ให้hasOwnPropertyเขียนObject.prototype.hasOwnProperty.call(objectFromJSON, "propertyName")เพื่อความปลอดภัย

— Aadit M Shah

22

ใน JavaScript, หมายถึงสิ่งที่แตกต่างกันมากกว่าnullundefined

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

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

5

ไม่มี "ไม่ได้กำหนด" ใน JSON ดังนั้นฉันคิดว่าเขาถามเพียงว่าจะรวมคุณสมบัติ "ว่าง" หรือไม่ - {"prop":undefined}แตกต่างจาก{}.

— Bergi

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

— Brad

11

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

ในทางกลับกันหากไม่จำเป็นต้องให้ใครมาสร้างความแตกต่างก็จงออกไป

— พอล
แหล่งที่มา

0

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

ความแตกต่างปรากฏในไฟล์ JSON-config เมื่อผู้ใช้ควรแก้ไขบางสิ่งด้วยมือ เมื่อคุณใช้ตัวอย่างแรกคุณให้คำแนะนำแก่ผู้ใช้เกี่ยวกับการกำหนดค่า

— Alexey Kachalov
แหล่งที่มา

1

คุณช่วยอธิบายเพิ่มเติมได้ไหมโดยเพิ่มคำอธิบายเพิ่มเติมเกี่ยวกับโซลูชันที่คุณให้

— abarisone