JSON có nên bao gồm giá trị null [đóng]


89

Tôi đang tạo một API trả về kết quả dưới dạng JSON. Có phương pháp hay nhất hiện tại về việc liệu chúng ta có nên đưa các khóa vào kết quả khi giá trị bằng không? Ví dụ:

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

hoặc là

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

Vì cái thứ hai nhỏ hơn nên tôi đang nghiêng về phong cách này, nhưng tôi không chắc liệu có phong cách ưa thích hay không. Từ góc độ khách hàng, có vẻ như cả hai phong cách sẽ tương đương nhau về mặt chức năng. Bất kỳ ưu hoặc khuyết điểm cho mỗi?


6
Không thể trả lời điều này một cách chính xác. Câu trả lời chính xác phụ thuộc vào yêu cầu của ứng dụng. OP chỉ cần chọn câu trả lời phù hợp với yêu cầu của mình. Nếu ứng dụng của bạn cần có khả năng phân biệt giữa việc biết "isbn" là null và nếu "isbn" có thể không được gửi từ máy chủ vì một lý do khác, bạn cần phải bao gồm nó.
Jay

@Jacob Mặc dù tôi không nói ra, nhưng ý định của tôi với câu hỏi này là JSON "đầy đủ" đại diện cho câu trả lời đang được trả lại. Khi khách hàng có thể cho rằng dường như không có sự khác biệt về chức năng giữa hai cách tiếp cận. Nếu API sẽ không trả về các khóa / giá trị một cách chọn lọc thì có, nó sẽ tạo ra sự khác biệt lớn mà cách tiếp cận đã được thực hiện.
jjathman

lợi ích của biểu diễn đầu tiên là lược đồ đối tượng được giữ nguyên, sự hiện diện của thuộc tính không mơ hồ dựa trên dữ liệu. ở định dạng thứ hai thông tin này bị mất. JSON spec như vậy không uỷ quyền hoặc định dạng AFAIK
Surya Pratap

Câu trả lời:


32

Cách thứ hai sẽ tiết kiệm một lượng nhỏ băng thông, nhưng nếu đó là mối quan tâm, bạn cũng sẽ sử dụng các mảng được lập chỉ mục thay vì lấp đầy JSON bằng các khóa. Rõ ràng, ["Foo Bar","Joe Blow"]là ngắn hơn nhiều so với những gì bạn có bây giờ.

Về khả năng sử dụng, tôi không nghĩ rằng nó tạo ra bất kỳ sự khác biệt nào. Trong cả hai trường hợp, if(json.isbn)sẽ bỏ qua else. Thường không cần phân biệt giữa null(không có giá trị) và undefined(không có giá trị cho trước).


7
+1 cho Thường không cần phân biệt giữa null (không có giá trị) và không xác định (không có giá trị nhất định). Thậm chí còn có một nhà điều hành tiện dụng cho nó != null(không nghiêm ngặt dành)
Esailija

Trường hợp duy nhất tôi có thể nghĩ đến là thử nghiệm nếu một trình duyệt hỗ trợ một loại sự kiện nhất định. Ví dụ, if( typeof onbeforepaste == "undefined")để xem nếu onBeforePasteđược hỗ trợ. Thậm chí sau đó, nó không tạo ra sự khác biệt thực sự nào vì bạn có thể chỉ định các sự kiện tất cả những gì bạn muốn (chúng sẽ không làm gì nếu không được hỗ trợ).
Niet the Dark Absol

6
Về mặt lưu các byte được chuyển, nén quan trọng hơn nhiều so với những thứ như mảng được lập chỉ mục. web-resource-optimization.blogspot.no/2011/06/… Hãy đảm bảo rằng đó là điều đầu tiên bạn làm. Trong hầu hết các trường hợp, thêm những thứ như mảng được lập chỉ mục lên trên đó là những gì tôi sẽ gọi là tối ưu hóa sớm. Trừ khi bạn đang gửi một lượng dữ liệu LỚN. Điều đó cũng yêu cầu phân tích cú pháp bổ sung, làm tăng thêm độ phức tạp cho ứng dụng của bạn. Gzipping được trình duyệt thực hiện liền mạch. (giả sử khách hàng là một trình duyệt)
Martin Hansen

3
Với việc HTTPS trở thành chuẩn mực trong ngày (ít nhất là đối với các ứng dụng có cơ sở người dùng lớn), việc nén sẽ rất khó khăn. Xem en.wikipedia.org/wiki/CRIME_%28security_exploit%29
Gaurav Vaish

6
Tôi thực sự sẽ -1 điều này cho "Thường không cần phân biệt giữa null" nếu tôi có danh tiếng. Từ 2 lý do: 1. lý do để phân biệt tồn tại và chúng không hiếm 2. thực tiễn tốt nhất là luôn có các giá trị "được xác định rõ" nghĩa là luôn ngăn chặn bất kỳ sự mơ hồ nào - 2 ý nghĩa của 1 giá trị luôn là xấu - cần phải khá rõ ràng ..
Srneczek

80

Tôi là một fan hâm mộ của việc luôn bao gồm null một cách rõ ràng vì điều đó mang ý nghĩa. Trong khi bỏ qua một thuộc tính để lại sự mơ hồ.

Miễn là giao thức của bạn với máy chủ được thỏa thuận theo bất kỳ điều nào ở trên đều có thể hoạt động, nhưng nếu bạn chuyển null từ máy chủ, tôi tin rằng điều đó làm cho các API của bạn sau này linh hoạt hơn.

Cũng nên đề cập rằng hàm hasOwnProperty của javascript cung cấp cho bạn cái nhìn sâu sắc hơn.

/* 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
Chính xác, nhiều người cần hiểu sự khác biệt giữa "", null và undefined. Câu trả lời cho câu hỏi này là tùy thuộc vào yêu cầu của người dùng.
Jay

13
+1. Người ở đầu bên kia (người viết mã) sẽ được phục vụ tốt hơn bởi các giá trị rõ ràng. Họ có thể không được viết JavaScript ;-)
Steve11235

2
Lưu ý rằng việc kiểm tra null không hoạt động với ==, === là bắt buộc (vì không xác định == null)!
Tommy

chính xác thì phần đầu tiên của câu trả lời được chấp nhận rất sai ...
Srneczek

Tôi sẽ viết "propertyName" in objectFromJSONthay vì objectFromJSON.hasOwnProperty("propertyName"). Ngoài ra, nếu bạn nhấn mạnh vào việc sử dụng hasOwnPropertythì hãy viết Object.prototype.hasOwnProperty.call(objectFromJSON, "propertyName")cho an toàn.
Aadit M Shah

22

Trong JavaScript, nullcó nghĩa là một cái gì đó rất khácundefined .

Đầu ra JSON của bạn phải phản ánh những gì được ứng dụng của bạn sử dụng và cần thiết trong ngữ cảnh cụ thể của việc sử dụng dữ liệu JSON.


5
Không có "không xác định" trong JSON, vì vậy tôi nghĩ anh ấy chỉ hỏi liệu có nên bao gồm các thuộc tính "trống" hay không - {"prop":undefined}khác với {}.
Bergi

Đã đồng ý, tôi đang cố gắng giải thích rằng ở đầu nhận, nếu anh ta đang tìm kiếm một thuộc tính cụ thể được đặt thành null, thì sẽ không có. Nó sẽ không được xác định, nếu bị bỏ sót.
Brad

11

Bạn chắc chắn nên bao gồm nó nếu có bất kỳ nhu cầu nào để phân biệt giữa nullundefinedvì chúng có hai nghĩa khác nhau trong Javascript. Bạn có thể nghĩ về nullnghĩa là thuộc tính không xác định hoặc vô nghĩa, vàundefined nghĩa là thuộc tính không tồn tại.

Mặt khác, nếu không cần ai phân biệt điều đó thì hãy cứ bỏ nó đi.


0

Tôi nghĩ không có gì khác biệt khi bạn sử dụng JSON làm dữ liệu đằng sau trải nghiệm của người dùng.

Sự khác biệt xuất hiện trong các tệp JSON-config, khi người dùng nên chỉnh sửa nội dung nào đó bằng tay. Khi bạn sử dụng ví dụ đầu tiên, bạn cung cấp cho người dùng một số gợi ý về cấu hình.


1
Bạn có thể vui lòng giải thích thêm câu trả lời của mình bằng cách thêm một chút mô tả về giải pháp bạn cung cấp không?
abarisone
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.