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?
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?
Respostas:
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-case
como 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.
Neste documento, o Google JSON Style Guide (recomendações para a criação de APIs JSON no Google),
Recomenda que:
Os nomes das propriedades devem ser cadeias ASCII camelCased .
O primeiro caractere deve ser uma letra, um sublinhado (_) ou um cifrão ($).
Exemplo:
{
"thisPropertyIsAnIdentifier": "identifier value"
}
Minha equipe segue esta convenção.
Property Name Guidelines->Property Name Format->Choose meaningful property names.
.
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.
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.
Linguagem de programação para gerar JSON
O próprio JSON não possui nomes padrão de chaves
Linguagem de programação para analisar JSON
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")
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ê.
"Person":
não é camelCase :)
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.
org.json
, por exemplo gson
,. Recebendo dados snake_case não doer tanto assim ...JSONObject.get('snake_case_key_here')
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
.
beanNaming
.
Acho que não existe uma convenção oficial de nomes para o JSON, mas você pode seguir alguns líderes do setor para ver como está funcionando.
O Google, que é uma das maiores empresas de TI do mundo, tem um guia de estilo JSON: https://google.github.io/styleguide/jsoncstyleguide.xml
Aproveitando, você pode encontrar outro guia de estilos, que o Google define, aqui: https://github.com/google/styleguide
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:
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.
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
}