Existe algum motivo prático para usar strings entre aspas para chaves JSON?

De acordo com o json.org de Crockford , um objeto JSON é composto de membros , que são compostos de pares .

Cada par é feito de uma string e um valor , com uma string sendo definida como:

Uma string é uma sequência de zero ou mais caracteres Unicode, colocados entre aspas duplas, usando escapes de barra invertida. Um caractere é representado como uma única string de caracteres. Uma string é muito parecida com uma string C ou Java.

Mas, na prática, a maioria dos programadores nem sabe que uma chave JSON deve estar entre aspas duplas, porque a maioria dos navegadores não exige o uso de aspas duplas.

Faz algum sentido se preocupar em colocar o JSON entre aspas duplas?

Exemplo válido:

{
  "keyName" : 34
}

Ao contrário do inválido:

{
   keyName : 34
}

O verdadeiro motivo pelo qual as chaves JSON devem estar entre aspas é a semântica dos Identificadores do ECMAScript 3.

Palavras reservadas não podem ser usadas como nomes de propriedade em literais de objeto sem aspas, por exemplo:

({function: 0}) // SyntaxError
({if: 0}) // SyntaxError
({true: 0}) // SyntaxError
// etc...

Se você usar aspas, os nomes das propriedades serão válidos:

({"function": 0}) // Ok
({"if": 0}) // Ok
({"true": 0}) // Ok

O próprio Crockford explica isso nesta palestra , eles queriam manter o padrão JSON simples e não gostariam de ter todas essas restrições semânticas nele:

....

Foi quando descobrimos o problema do nome não citado. Acontece que o ECMA Script 3 tem uma política de palavras reservadas do tipo whack. As palavras reservadas devem ser citadas na posição chave, o que é realmente um incômodo. Quando comecei a formular isso em um padrão, não queria ter que colocar todas as palavras reservadas no padrão, porque pareceria muito estúpido.

Na época, eu estava tentando convencer as pessoas: sim, você pode escrever aplicativos em JavaScript, na verdade vai funcionar e é uma boa linguagem. Eu não quis dizer, então, ao mesmo tempo: e olhe só que bobagem eles fizeram! Então decidi, em vez disso, vamos apenas citar as chaves.
Dessa forma, não precisamos contar a ninguém sobre o quão maluco é.

É por isso que, até hoje, as chaves são citadas em JSON.

...

O ECMAScript 5th Edition Standard corrige isso, agora em uma implementação ES5, mesmo palavras reservadas podem ser usadas sem aspas, em ambos, literais de objeto e acesso de membro ( obj.functionOk em ES5).

Apenas para registro, este padrão está sendo implementado atualmente por fornecedores de software. Você pode ver quais navegadores incluem esse recurso nesta tabela de compatibilidade (consulte Palavras reservadas como nomes de propriedade )

Sim, é JSON inválido e será rejeitado em muitos casos, por exemplo, jQuery 1.4+ tem uma verificação que faz com que o JSON não citado falhe silenciosamente. Porque não ser compatível?

Vamos dar outro exemplo:

{ myKey: "value" }
{ my-Key: "value" }
{ my-Key[]: "value" }

... tudo isso valeria com aspas, por que não ser consistente e utilizá-las em todos os casos, eliminando a possibilidade de um problema?

Mais um exemplo comum no mundo do desenvolvedor da web: Existem milhares de exemplos de HTML inválido que são renderizados na maioria dos navegadores ... isso torna menos doloroso depurar ou manter? De forma alguma, muito pelo contrário.

Além disso, @Matthew faz o melhor ponto de todos nos comentários abaixo, isso já falha, as chaves não citadas irão lançar um erro de sintaxe com JSON.parse()em todos os principais navegadores (e quaisquer outros que as implementem corretamente), você pode testá-lo aqui .

YAML, que na verdade é um superconjunto de JSON, oferece suporte ao que você deseja fazer. Embora seja um superconjunto, permite mantê-lo tão simples quanto você deseja.

YAML é uma lufada de ar fresco e pode valer a pena dar uma olhada nele. O melhor lugar para começar é aqui: http://en.wikipedia.org/wiki/YAML

Existem libs para todos os idiomas existentes, incluindo JS, por exemplo, https://github.com/nodeca/js-yaml