2012-06-12 16 views
83

Estoy creando una API que arroje resultados como JSON. ¿Existe una mejor práctica actual para saber si debemos incluir claves en el resultado cuando el valor es nulo? Por ejemplo:En caso de que JSON incluya valores nulos

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

o

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

Dado que la segunda es más pequeña que estoy inclinando hacia este estilo, pero no estoy seguro de si hay un estilo preferido o no. Desde la perspectiva del cliente, parece que ambos estilos serían funcionalmente equivalentes. ¿Alguna ventaja o desventaja para cada uno?

+5

Es imposible responder esto correctamente. La respuesta correcta depende de los requisitos de la aplicación. El OP simplemente ha seleccionado la respuesta que se ajusta a sus necesidades. Si su aplicación necesita poder distinguir entre saber si el "isbn" es nulo y si el "isbn" puede no haberse enviado del servidor por otro motivo, debe incluirlo. – Jacob

+0

@Jacob Aunque no lo dije, mi intención con esta pregunta era que se devolviera el JSON "completo" que representaba la respuesta. Cuando un cliente puede suponer que no parece haber diferencia funcional entre los dos enfoques.Si la API no devuelve selectivamente las claves/valores, entonces sí, sería una gran diferencia qué enfoque se tomó. – jjathman

+0

el beneficio de la primera representación es que el esquema del objeto se conserva; la presencia de la propiedad no es ambigua en función de los datos. en el segundo formato esta información se pierde. La especificación JSON no requiere formato AFAIK –

Respuesta

30

El segundo ahorrará una pequeña cantidad en el ancho de banda, pero si eso fuera una preocupación, también usaría matrices indexadas en lugar de llenar el JSON con las claves. Claramente, ["Foo Bar","Joe Blow"] es mucho más corto que lo que tienes ahora.

En términos de usabilidad, no creo que haga ninguna diferencia. En ambos casos, if(json.isbn) saltará al else. Por lo general, no es necesario distinguir entre null (sin valor) y undefined (valor no determinado).

+7

+1 por * No suele ser necesario distinguir entre nulo (sin valor) e indefinido (sin valor dado). * Incluso hay un operador práctico para él '! = Null' (no estricto) – Esailija

+0

El único caso Puedo pensar en probar si un navegador admite cierto tipo de evento. Por ejemplo, 'if (typeof onbeforepaste ==" undefined ")' para ver si 'onBeforePaste' es compatible. Incluso así, no hay diferencia real, ya que puedes asignar eventos todo lo que quieras (simplemente no harán nada si no son compatibles). –

+0

En ese caso, probaría '" onbeforepaste "en el documento', para probar la existencia de la propiedad. – Esailija

19

En JavaScript, null significa algo muy diferente de undefined.

Su salida JSON debe reflejar lo que usa y necesita su aplicación en el contexto específico del uso de los datos JSON.

+4

. No hay "indefinido" en JSON, así que creo que solo pregunta si se deben incluir las propiedades "vacías" o no - '{" prop ": undefined}' es diferente de '{ } ' – Bergi

+0

Estoy de acuerdo, estoy tratando de explicar que en el extremo receptor, si está buscando que una propiedad específica se establezca como nula, no lo será. No estará definido, si se deja fuera. – Brad

10

Definitivamente debe incluirlo si hay alguna necesidad de distinguir entre null y undefined ya que estos tienen dos significados diferentes en Javascript. Puede pensar en null como que la propiedad es desconocida o sin sentido, y undefined significa que la propiedad no existe.

Por otro lado, si no hay necesidad de que alguien haga esa distinción, continúe y omítala.

71

Soy un fan de incluir siempre nulo explícitamente ya que eso conlleva significado. Si bien omitir una propiedad deja ambigüedad.

Siempre que se acuerde el protocolo con el servidor, cualquiera de los anteriores puede funcionar, pero si pasa nulos desde el servidor, creo que hace que sus API sean más flexibles más adelante.

También debería mencionar que la función hasOwnProperty de javascript le proporciona más informació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

Exactamente, más personas necesitan entender la diferencia entre "", nulo e indefinido. La respuesta a esta pregunta depende de los requisitos de los usuarios. – Jacob

+11

+1. La persona del otro lado (quien escribió el código) estará mejor servida por valores explícitos. Es posible que no estén escribiendo JavaScript ;-) – Steve11235

+2

Tenga en cuenta que la comprobación contra null no funciona con ==, === es necesario (porque undefined == null)! – Tommy

0

Creo que no hay ninguna diferencia cuando utiliza el JSON como datos detrás de la experiencia del usuario.

La diferencia aparece en los archivos JSON-config, cuando un usuario debe editar algo a mano. Cuando utiliza el primer ejemplo, le da al usuario alguna pista sobre la configuración.

+1

¿Podría por favor elaborar más su respuesta agregando un poco más de descripción acerca de la solución que proporciona? – abarisone

Cuestiones relacionadas