Convenção de Nomenclatura JSON [fechada]


379

Existe um padrão na nomeação JSON? Vejo a maioria dos exemplos usando todas as minúsculas separadas por sublinhado (minúsculas). Mas, você pode usar PascalCase ou camelCase?


12
Fiquei curioso sobre o que alguns líderes da indústria escolheram. As APIs do Twitter e do Facebook usam snake_case, enquanto a Microsoft e o Google usam o camelCase.
23416 Justin

2
@ Justin, porque o Twitter está usando Ruby e o Facebook está usando PHP. Ruby e PHP estão no snake_case. Microsoft e Google estão bem usando C / .NET e Java, respectivamente. Ah, isso mesmo .Net e Java estão no camelCase talvez. É tudo sobre as convenções das linguagens de programação
Abel Callejo 12/12

11
Não existe um padrão, mas a convenção parece usar o padrão da tecnologia do sistema receptor.
Martin of Hessle

11
Todos estão corretos, não há uma convenção rigorosa para nomes / chaves no JSON. No entanto, eu recomendo evitar o caso de kebab, pois ele não pode ser acessado pela notação de ponto (.) Em javascript e deve ser acessado usando a notação de matriz [], que eu acho tediosa.
saurabh

2
Fechado como baseado principalmente em opiniões? O OP estava solicitando fatos sobre as capacidades / limitações do formato, não para a opinião de ninguém. Ele disse "você pode", não "você deveria". Talvez o OP não tenha escrito com clareza suficiente para esses cinco indivíduos, mas você teria que ter uma compreensão de leitura bastante fraca para não entender o que ele está pedindo.
dynamichael

Respostas:


251

Não existe um padrão ÚNICO, mas já vi três estilos mencionados ("Pascal / Microsoft", "Java" ( camelCase) e "C" (sublinhados snake_case)) - bem como pelo menos mais um, kebab-casecomo longer-name).

Parece depender principalmente do que os desenvolvedores de segundo plano do serviço em questão tinham; aqueles com experiência em c / c ++ (ou linguagens que adotam nomes semelhantes, que incluem muitas linguagens de script, ruby ​​etc.) geralmente escolhem a variação de sublinhado; e descanse da mesma forma (Java vs .NET). A biblioteca Jackson mencionada, por exemplo, assume a convenção de nomenclatura do bean Java ( camelCase)

ATUALIZAÇÃO: minha definição de "padrão" é uma convenção ÚNICA. Portanto, embora alguém possa dizer "sim, existem muitos padrões", para mim existem vários Naming Conventions, nenhum dos quais é "o" padrão geral. Um deles pode ser considerado o padrão para plataforma específica, mas como o JSON é usado para interoperabilidade entre plataformas que podem ou não fazer muito sentido.


4
Manter o background dos desenvolvedores é importante, mas o JSON segue o padrão Javascript. Sua primeira afirmação não está correta. Mas fique atento às convenções de nomenclatura de sua equipe.
Anubian Noob

8
Seria interessante ver algumas estatísticas, pois há atrito constante entre pessoas que reivindicam conexão entre JSON e Javascript (além do patrimônio histórico) e aquelas que pensam que há pouco atualmente que conecta JSON a Javascript. Eu pertenço ao último acampamento. Mas eu estaria interessado em conhecer padrões de uso relativo.
precisa saber é o seguinte

O @StaxMan C # usa PascalCase na maioria dos casos, não o camelCase.
ArtOfCode 9/12

@ArtOfCode yes. Onde vc quer chegar? (também, caso pascal às vezes chamado de "caso camelo superior")
StaxMan

@StaxMan você considerar atualizar sua resposta para incluir menção de Guia Googles Estilo
garrettmac

402

Neste documento, o Google JSON Style Guide (recomendações para a criação de APIs JSON no Google),

Recomenda que:

  1. Os nomes das propriedades devem ser cadeias ASCII camelCased .

  2. O primeiro caractere deve ser uma letra, um sublinhado (_) ou um cifrão ($).

Exemplo:

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

Minha equipe segue esta convenção.


8
Aparentemente, o Google mudou as diretrizes, não encontramos nada sobre o caso camelo ou começando com a letra, _ ou US $ no documento mais ...
theeye

32
@TheEye Ainda está lá, basta clicar no menu suspenso.
Gdw2

5
Bom olho, @ gdw2. Para outras pessoas no futuro, é se você clicar no botão de seta por Property Name Guidelines->Property Name Format->Choose meaningful property names..
Panzercrisis

3
Alguém pode explicar por que e quando você usaria um sublinhado para prefixar o nome de uma propriedade? Uma referência seria útil, não apenas uma opinião.
Sean Glover

4
citar o Google não é uma resposta adequada. eles apenas apóiam uma certa convenção / diretriz e parece que o java faz sentido, pois é bastante orientado a java.
Thomas Andreè Wang

186

Premissa

Não há nomes padrão de chaves no JSON . De acordo com a seção Objetos da especificação:

A sintaxe JSON não impõe nenhuma restrição às strings usadas como nomes, ...

O que significa que camelCase ou snake_case deve funcionar bem.

Fatores de condução

A imposição de uma convenção de nomenclatura JSON é muito confusa. No entanto, isso pode ser facilmente descoberto se você a dividir em componentes.

  1. Linguagem de programação para gerar JSON

    • Python - snake_case
    • PHP - snake_case
    • Java - camelCase
    • JavaScript - camelCase
  2. O próprio JSON não possui nomes padrão de chaves

  3. Linguagem de programação para analisar JSON

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

Combine os componentes

  1. Python »JSON» Python - snake_case - unânime
  2. Python »JSON» PHP - snake_case - unânime
  3. Python »JSON» Java - snake_case - veja o problema do Java abaixo
  4. Python »JSON» JavaScript - snake_case fará sentido; enrosque o front-end de qualquer maneira
  5. Python »JSON» você não conhece - snake_case fará sentido; aparafuse o analisador de qualquer maneira
  6. PHP »JSON» Python - snake_case - unânime
  7. PHP »JSON» PHP - snake_case - unânime
  8. PHP »JSON» Java - snake_case - veja o problema de Java abaixo
  9. PHP »JSON» JavaScript - snake_case fará sentido; enrosque o front-end de qualquer maneira
  10. PHP »JSON» você não sabe - snake_case fará sentido; aparafuse o analisador de qualquer maneira
  11. Java »JSON» Python - snake_case - veja o problema do Java abaixo
  12. Java »JSON» PHP - snake_case - veja o problema de Java abaixo
  13. Java »JSON» Java - camelCase - unânime
  14. Java »JSON» JavaScript - camelCase - unânime
  15. Java »JSON» você não conhece - camelCase fará sentido; aparafuse o analisador de qualquer maneira
  16. JavaScript »JSON» Python - snake_case fará sentido; enrosque o front-end de qualquer maneira
  17. JavaScript »JSON» PHP - snake_case fará sentido; enrosque o front-end de qualquer maneira
  18. JavaScript »JSON» Java - camelCase - unânime
  19. JavaScript »JSON» JavaScript - camelCase - Original

Problema de Java

snake_case ainda fará sentido para aqueles com entradas Java, porque as bibliotecas JSON existentes para Java estão usando apenas métodos para acessar as chaves em vez de usar o dot.syntax padrão . Isso significa que não seria demais para Java acessar as chaves snake_cased em comparação com a outra linguagem de programação que pode executar a dot.syntax .

Exemplo para o pacote do Javaorg.json

JsonObject.getString("snake_cased_key")

Exemplo para o pacote do Javacom.google.gson

JsonElement.getAsString("snake_cased_key")

Algumas implementações reais

Conclusões

A escolha da convenção de nomenclatura JSON correta para sua implementação JSON depende da sua pilha de tecnologia. Há casos em que é possível usar snake_case , camelCase ou qualquer outra convenção de nomenclatura.

Outra coisa a considerar é o peso a ser colocado no gerador JSON versus o analisador JSON e / ou no JavaScript front-end. Em geral, mais peso deve ser colocado no lado do gerador JSON em vez do lado do analisador JSON. Isso ocorre porque a lógica de negócios geralmente reside no lado do gerador JSON.

Além disso, se o lado do analisador JSON for desconhecido, você poderá declarar o que pode funcionar para você.


2
"Person":não é camelCase :)
stoft 14/01

11
@stoft provavelmente porque eles também seguiram a convenção do schema.org. Iniciar a chave com uma letra maiúscula significa que é uma entidade de vocabulário. Iniciar a chave com letra minúscula significa que é uma propriedade do vocabulário.
Abel Callejo

2
Não concordo com essas idéias, simplesmente porque o front-end do Python> front-end do Java deve ser camelCase, mas você adiciona o front-end do Python e comprometeu o back-end e um front-end. Deve ser como o back-end o possui por "padrão". Analisadores de frontend tê-lo mais fácil de se adaptar de qualquer maneira
Bojan Kogoj

2
Minha preocupação aqui é que haja referência à pilha "sua tecnologia". Um produtor de JSON, especialmente se for atendido por um servidor HTTP, não deve ter conhecimento de quem ou o que está consumindo, ou por quais razões. Se o JSON for usado como um método de comunicação entre muitos produtores e consumidores, a pilha de tecnologia do produtor não deve ser considerada.
Robbie Wareham

11
@RobbieWareham De alguma forma, concordo com isso. A questão aqui é que "por padrões" não existe uma convenção oficial de nomes. Portanto, com isso, talvez se deva optar por "de fato", que é olhar para a pilha de tecnologias. Eu acho que olhar para a pilha de tecnologia é o melhor caminho a percorrer. Dê uma olhada no facebook, eles historicamente honram o JavaScript e usam o snakeCase? Nah! Eles escolheram ficar com o snake_case do PHP.
Abel Callejo

18

Especialmente para mim no NodeJS, se estou trabalhando com bancos de dados e meus nomes de campos estão separados por sublinhado, também os uso nas chaves struct.

Isso ocorre porque os campos db têm muitos acrônimos / abreviações, então algo como appSNSInterfaceRRTest parece um pouco confuso, mas app_sns_interface_rr_test é mais agradável.

No Javascript, as variáveis ​​são todas camelCase e os nomes das classes (construtores) são ProperCase, então você verá algo como

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

ou

generalLedgerTask = new GeneralLedgerTask( devTask );

E é claro que as chaves / strings JSON são colocadas entre aspas duplas, mas você simplesmente usa o JSON.stringify e passa nos objetos JS, portanto, não precisa se preocupar com isso.

Eu lutei um pouco com isso até encontrar esse meio termo entre as convenções de nomenclatura JSON e JS.


11
o mesmo aqui. Receber JSON com snake_case no cliente Android parece estranho !! Além disso, o banco de dados não diferencia as maiúsculas e minúsculas dos nomes das colunas; portanto, snake_case parece ser o melhor para o banco de dados.
Mythicalcoder

O @mythicalcoder JSON em Java não é intrínseco em seu núcleo. Java usa apenas pacotes externos para analisar Java org.json, por exemplo gson,. Recebendo dados snake_case não doer tanto assim ...JSONObject.get('snake_case_key_here')
Abel Callejo

9

Parece que há variação suficiente para que as pessoas façam o possível para permitir a conversão de todas as convenções para outras: http://www.cowtowncoder.com/blog/archives/cat_json.html

Notavelmente, o analisador Jackson JSON mencionado prefere bean_naming.


5
Correção menor: Jackson assume como padrão a convenção de nomenclatura do bean Java, que é (mais baixa) Camel Case, como beanNaming.
StaxMan


0

Como outros já declararam, não existe um padrão, então você deve escolher um. Aqui estão algumas coisas a considerar ao fazer isso:

  1. Se você estiver usando JavaScript para consumir JSON, o uso da mesma convenção de nomenclatura para propriedades em ambos fornecerá consistência visual e possivelmente algumas oportunidades para reutilização de código mais limpa.

  2. Um pequeno motivo para evitar o caso de kebab é que os hífens podem colidir visualmente com -caracteres que aparecem em valores.

    {
      "bank-balance": -10
    }

11
snake_case usa sublinhados, não traços.
percebus
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.