JSON Naming Convention [cerrado]


379

¿Existe un estándar para nombrar JSON? Veo la mayoría de los ejemplos que usan todas las minúsculas separadas por un guión bajo (minúscula). Pero, ¿puedes usar PascalCase o camelCase?


12
Tenía curiosidad por lo que eligieron algunos líderes de la industria. Las API de Twitter y Facebook usan snake_case mientras que Microsoft y Google usan camelCase.
Justin

2
@Justin eso es porque Twitter está usando Ruby y Facebook está usando PHP. Ruby y PHP están en snake_case. Microsoft y Google están usando C / .NET y Java respectivamente. Ah, sí. Tal vez .Net y Java están en camelCase. Se trata de las convenciones de los lenguajes de programación
Abel Callejo

1
No existe un estándar, pero la convención parece ser utilizar el estándar de la tecnología del sistema receptor.
Martin de Hessle

1
Todos son correctos, no hay una convención estricta para nombres / claves en JSON. Sin embargo, recomiendo evitar el caso kebab, ya que no se puede acceder mediante la notación de punto (.) En javascript y se debe acceder utilizando la notación array [], lo que creo que es tedioso.
saurabh

2
Cerrado como basado principalmente en la opinión? El OP estaba pidiendo datos sobre las capacidades / limitaciones del formato, no para la opinión de nadie. Él dijo "puedes", no "deberías". Quizás el OP no lo expresó con suficiente claridad para esas cinco personas, pero tendría que tener una comprensión de lectura bastante pobre para no entender lo que él preguntaba.
dynamichael

Respuestas:


251

No hay un solo estándar, pero he visto 3 estilos que menciona ("Pascal / Microsoft", "Java" ( camelCase) y "C" (guiones bajos, snake_case)), así como al menos uno más, kebab-casecomo longer-name).

En su mayoría, parece depender de los desarrolladores de fondo del servicio en cuestión; aquellos con antecedentes de c / c ++ (o lenguajes que adoptan nombres similares, que incluyen muchos lenguajes de script, ruby, etc.) a menudo eligen la variante de subrayado; y descansar de manera similar (Java vs .NET). La biblioteca de Jackson que se mencionó, por ejemplo, asume la convención de nomenclatura del bean Java ( camelCase)

ACTUALIZACIÓN: mi definición de "estándar" es una CONVENCIÓN ÚNICA. Entonces, aunque uno podría decir "sí, hay muchos estándares", para mí hay múltiples Naming Conventions, ninguno de los cuales es "El" estándar en general. Uno de ellos podría considerarse el estándar para una plataforma específica, pero dado que JSON se usa para la interoperabilidad entre plataformas que pueden o no tener mucho sentido.


44
Mantenerse en el fondo de los desarrolladores es importante, pero JSON sigue con el estándar Javascript. Tu primera declaración no es correcta. Pero definitivamente quédese con las convenciones de nombres de su equipo.
Anubian Noob

8
Sería interesante ver algunas estadísticas, ya que existe una fricción constante entre las personas que afirman la conexión entre JSON y Javascript (más allá del patrimonio histórico), y aquellos que piensan que hay poco actualmente que conecte JSON con Javascript. Pertenezco al último campo. Pero me interesaría conocer los patrones de uso relativo.
StaxMan

@StaxMan C # usa PascalCase en la mayoría de los casos, no camelCase.
ArtOfCode

@ArtOfCode sí. ¿Cuál es tu punto? (también, pascal-caso a veces llamado "caso camello superior")
StaxMan

@StaxMan le considerar la actualización de su respuesta para incluir la mención de la Guía de Google Estilo
garrettmac

402

En este documento, Guía de estilo JSON de Google (recomendaciones para crear API JSON en Google),

Recomienda que:

  1. Los nombres de las propiedades deben ser camelCased , cadenas ASCII.

  2. El primer carácter debe ser una letra, un guión bajo (_) o un signo de dólar ($).

Ejemplo:

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

Mi equipo sigue esta convención.


8
Aparentemente, Google ha cambiado las pautas, ya no hay nada que encontrar sobre el caso de camello o que comience con la letra, _ o $ en el documento ...
TheEye

32
@TheEye Todavía está allí, solo necesita hacer clic en el menú desplegable.
gdw2

55
Buen ojo, @ gdw2. Para otras personas en el futuro, es si haces clic en el botón de flecha Property Name Guidelines->Property Name Format->Choose meaningful property names..
Panzercrisis

3
¿Alguien puede explicar por qué y cuándo usaría un guión bajo para prefijar un nombre de propiedad? Una referencia sería útil, no solo una opinión.
Sean Glover

44
Citar a Google no es una respuesta adecuada. simplemente admiten una determinada convención / directriz y parece tener sentido Java ya que están bastante orientados a Java.
Thomas Andreè Wang

186

Premisa

No hay nombres estándar de claves en JSON . De acuerdo con la sección Objetos de la especificación:

La sintaxis JSON no impone restricciones a las cadenas utilizadas como nombres, ...

Lo que significa que camelCase o snake_case deberían funcionar bien.

Factores impulsores

Imponer una convención de nomenclatura JSON es muy confuso. Sin embargo, esto se puede resolver fácilmente si lo divide en componentes.

  1. Lenguaje de programación para generar JSON

    • Python - snake_case
    • PHP - snake_case
    • Java - camelCase
    • JavaScript - camelCase
  2. JSON en sí no tiene un nombre estándar de claves

  3. Lenguaje de programación para analizar JSON

    • Python - snake_case
    • PHP - snake_case
    • Java - camelCase
    • JavaScript - camelCase

Mezcla-combina los componentes

  1. Python »JSON» Python - snake_case - unánime
  2. Python »JSON» PHP - snake_case - unánime
  3. Python »JSON» Java - snake_case - vea el problema de Java a continuación
  4. Python »JSON» JavaScript - snake_case tendrá sentido; atornillar la parte delantera de todos modos
  5. Python »JSON» no lo sabes - snake_case tendrá sentido; atornillar el analizador de todos modos
  6. PHP »JSON» Python - snake_case - unánime
  7. PHP »JSON» PHP - snake_case - unánime
  8. PHP »JSON» Java - snake_case - vea el problema de Java a continuación
  9. PHP »JSON» JavaScript - snake_case tendrá sentido; atornillar la parte delantera de todos modos
  10. PHP »JSON» no sabes - snake_case tendrá sentido; atornillar el analizador de todos modos
  11. Java »JSON» Python - snake_case - vea el problema de Java a continuación
  12. Java »JSON» PHP - snake_case - vea el problema de Java a continuación
  13. Java »JSON» Java - camelCase - unánime
  14. Java »JSON» JavaScript - camelCase - unánime
  15. Java »JSON» que no sabes - camelCase tendrá sentido; atornillar el analizador de todos modos
  16. JavaScript »JSON» Python - snake_case tendrá sentido; atornillar la parte delantera de todos modos
  17. JavaScript »JSON» PHP - snake_case tendrá sentido; atornillar la parte delantera de todos modos
  18. JavaScript »JSON» Java - camelCase - unánime
  19. JavaScript »JSON» JavaScript - camelCase - Original

Problema de Java

snake_case todavía tendrá sentido para aquellos con entradas de Java porque las bibliotecas JSON existentes para Java solo usan métodos para acceder a las claves en lugar de usar la sintaxis estándar dot.syntax . Esto significa que no le haría mucho daño a Java acceder a las teclas snake_cased en comparación con el otro lenguaje de programación que puede hacer la sintaxis dot.syntax .

Ejemplo para el paquete de Javaorg.json

JsonObject.getString("snake_cased_key")

Ejemplo para el paquete de Javacom.google.gson

JsonElement.getAsString("snake_cased_key")

Algunas implementaciones reales

Conclusiones

Elegir la convención de nomenclatura JSON adecuada para su implementación JSON depende de su pila de tecnología. Hay casos en los que se puede usar snake_case , camelCase o cualquier otra convención de nomenclatura.

Otra cosa a tener en cuenta es el peso que se debe poner en el generador JSON frente al analizador JSON y / o el JavaScript front-end. En general, se debe poner más peso en el lado del generador JSON en lugar del lado del analizador JSON. Esto se debe a que la lógica empresarial generalmente reside en el lado del generador JSON.

Además, si se desconoce el lado del analizador JSON, puede declarar lo que pueda funcionar para usted.


2
"Person":no es camelCase :)
stoft

1
@stoft probablemente porque también siguieron la convención de schema.org. Comenzar la clave con una letra mayúscula significa que es una entidad de vocabulario. Comenzar la clave con letras minúsculas significa que es una propiedad de vocabulario.
Abel Callejo

2
No estoy de acuerdo con estas ideas, simplemente porque el backend de Python> el frontend de Java debería ser camelCase, pero luego agrega el frontend de Python y ha comprometido el backend y un frontend. Debería ser cómo backend lo tiene por "estándar". Los analizadores frontend tienen más facilidad para adaptarse de todos modos
Bojan Kogoj

2
Mi preocupación aquí es que hay una referencia a la pila de "su tecnología". Un productor de JSON, especialmente si es servido por un servidor HTTP, no debe saber quién o qué lo consume, ni por qué razones. Si JSON se usa como método de comunicación entre muchos productores y consumidores, entonces la pila de tecnología del productor no debería ser considerada.
Robbie Wareham,

1
@RobbieWareham De alguna manera estoy de acuerdo en eso. La cuestión aquí es que "según los estándares" no existe una convención oficial de nombres. Entonces, con eso, tal vez uno debería optar por "de facto", que es mirar la pila de tecnología. Creo que mirar la pila de tecnología es la mejor manera de hacerlo. Echa un vistazo a Facebook, ¿históricamente honraron JavaScript y usaron snakeCase? Nah! Eligieron quedarse con el snake_case de PHP.
Abel Callejo

18

Notablemente para mí en NodeJS, si estoy trabajando con bases de datos y mis nombres de campo están separados por subrayado, también los uso en las claves de estructura.

Esto se debe a que los campos db tienen muchos acrónimos / abreviaturas, así que algo como appSNSInterfaceRRTest parece un poco desordenado, pero app_sns_interface_rr_test es más agradable.

En Javascript las variables son todas camelCase y los nombres de clase (constructores) son ProperCase, por lo que vería algo como

var devTask = {
        task_id: 120,
        store_id: 2118,
        task_name: 'generalLedger'
    };

o

generalLedgerTask = new GeneralLedgerTask( devTask );

Y, por supuesto, en JSON las claves / cadenas están entre comillas dobles, pero luego solo usa JSON.stringify y pasa objetos JS, por lo que no debe preocuparse por eso.

Luché un poco con esto hasta que encontré este medio feliz entre las convenciones de nombres JSON y JS.


1
igual que aquí. ¡Recibir JSON con snake_case en el cliente de Android se ve incómodo! Además, la base de datos no diferencia la carcasa de los nombres de columna, por lo que snake_case parece ser el mejor para la base de datos.
mythicalcoder

@mythicalcoder JSON en Java no es intrínseco en su núcleo. Java sólo utiliza paquetes externos para el análisis de Java por ejemplo org.json, gson. Recibir datos de snake_case no hace tanto daño ...JSONObject.get('snake_case_key_here')
Abel Callejo

9

Parece que hay suficiente variación para que las personas hagan todo lo posible para permitir la conversión de todas las convenciones a otras: http://www.cowtowncoder.com/blog/archives/cat_json.html

En particular, el analizador Jackson JSON mencionado prefiere bean_naming .


55
Corrección menor: Jackson adopta de manera predeterminada la convención de nomenclatura de beans Java, que es (inferior) Camel Case, como beanNaming.
StaxMan


0

Como otros han dicho, no hay un estándar, por lo que debe elegir uno usted mismo. Aquí hay un par de cosas a tener en cuenta al hacerlo:

  1. Si está utilizando JavaScript para consumir JSON, usar la misma convención de nomenclatura para las propiedades en ambos proporcionará consistencia visual y posiblemente algunas oportunidades para la reutilización de código más limpio.

  2. Una pequeña razón para evitar el caso kebab es que los guiones pueden chocar visualmente con los -caracteres que aparecen en los valores.

    {
      "bank-balance": -10
    }

1
snake_case usa guiones bajos, no guiones.
percebus
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.