Konwencja nazewnictwa JSON

[1]}w tym dokumencie Google JSON Style Guide (Zalecenia dotyczące budowania interfejsów API JSON w Google),

Zaleca:

1. Nazwy właściwości muszą być camelCased , ciągami ASCII.

2. Pierwszy znak musi być literą, podkreślnikiem ( _ ) lub znakiem dolara ($).

Przykład:

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

Nasz zespół używa tej konwencji.

Założenie

Jest Brak standardowego nazewnictwa kluczy w JSON.

Czynniki napędowe

Narzucanie konwencji nazewnictwa JSON jest bardzo mylące. Można to jednak łatwo zorientować, jeśli podzielisz je na komponenty.

1. Język programowania do generowania JSON

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

2. Sam JSON nie ma standardowego nazewnictwa kluczy

3. Język programowania do parsowania JSON

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

Mix-dopasuj komponenty

1. Python "JSON" Python - snake_case
2. Python "JSON" PHP - snake_case
3. Python "JSON" Java - snake_case lub camelCase
4. Python "JSON" JavaScript - snake_case będzie miało sens; wkręć front-end tak czy inaczej
5. Python "JSON" nie wiesz - snake_case będzie miało sens; wkręć parser tak czy inaczej
6. PHP "JSON" Python - snake_case
7. PHP " JSON " PHP - snake_case
8. PHP "JSON" Java - snake_case lub camelCase
9. PHP "JSON" JavaScript - snake_case będzie miało sens; wkręć front-end tak czy inaczej
10. PHP "JSON" PHP - snake_case
11. PHP "JSON" nie wiesz - snake_case będzie miało sens; wkręć parser tak czy inaczej
12. Java " JSON "Python - camelCase lub snake_case
13. Java "JSON" PHP - camelCase lub snake_case
14. Java "JSON" Java - camelCase
15. Java "JSON" JavaScript - camelCase
16. Java "JSON" nie wiesz - camelCase będzie miało sens; wkręć parser tak czy inaczej
17. JavaScript " JSON " Python - snake_case będzie miało sens; wkręć front-end tak czy inaczej
18. JavaScript "JSON" PHP - snake_case będzie miało sens; wkręć front-end tak czy inaczej
19. JavaScript "JSON" Java - camelCase
20. JavaScript "JSON" JavaScript - camelCase

Niektóre rzeczywiste implementacje

• Google Maps JavaScript API - camelCased
• Facebook JavaScript API - snake_cased
• Amazon Web Services - snake_cased & camelCased
• Twitter API - snake_cased
• JSON-LD - camelCased & ProperCamelCased

Wnioski

Wybór właściwej konwencji nazewnictwa JSON dla implementacji JSON zależy od stosu technologii. Istnieją przypadki, w których można użyć snake_case, camelCase , lub jakiejkolwiek innej konwencji nazewnictwa.

Kolejną rzeczą, którą należy wziąć pod uwagę, jest waga, jaką należy umieścić na generatorze JSON vs parserze JSON. Ogólnie rzecz biorąc, większą wagę należy położyć po stronie JSON-generatora, a nie po stronie JSON-parsera. Dzieje się tak, ponieważ logika biznesowa zwykle znajduje się po stronie JSON-generatora.

Ponadto, jeśli strona JSON-parsera jest nieznana, możesz zadeklarować, co kiedykolwiek może dla Ciebie zadziałać.

Szczególnie dla mnie w NodeJS, jeśli pracuję z bazami danych i moje nazwy pól są oddzielone podkreśleniem, używam ich również w kluczach struct.

Dzieje się tak dlatego, że pola db mają wiele akronimów/skrótów, więc coś w stylu appsnsinterfacertest wygląda trochę niechlujnie, ale app_sns_interface_rr_test jest ładniejsze.

W Javascript wszystkie zmienne są camelCase, a nazwy klas (konstruktory) są ProperCase, więc zobaczysz coś jak

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

Lub

generalLedgerTask = new GeneralLedgerTask( devTask );

I oczywiście w JSON klucze / łańcuchy są zawinięte w podwójne cudzysłowy, ale wtedy po prostu używasz JSON.stringify i pass w obiektach JS, więc nie musisz się o to martwić.

Trochę się z tym zmagałem, dopóki nie znalazłem tego szczęśliwego medium między konwencjami nazw JSON i JS.

Wydaje się, że jest wystarczająco dużo wariacji, że ludzie wychodzą ze swojej drogi, aby umożliwić konwersję ze wszystkich konwencji do innych: http://www.cowtowncoder.com/blog/archives/cat_json.html

W szczególności wspomniany Jackson JSON parser preferuje bean_naming.

Myślę, że nie ma oficjalnej konwencji nazewnictwa dla JSON, ale możesz śledzić niektórych liderów branży, aby zobaczyć, jak to działa.

Google, która jest jedną z największych firm IT na świecie, ma JSON style guide: https://google.github.io/styleguide/jsoncstyleguide.xml

Korzystając z tego, można znaleźć inne style guide, które definiuje Google, tutaj: https://github.com/google/styleguide

Jak inni stwierdzili, nie ma standardu, więc powinieneś wybrać jeden samodzielnie. Oto kilka rzeczy, które należy wziąć pod uwagę przy robieniu tego:

1. Jeśli używasz JavaScript do używania JSON, użycie tej samej konwencji nazewnictwa dla właściwości w obu zapewni wizualną spójność i ewentualnie pewne możliwości czystszego ponownego użycia kodu.

2. Mały powód, aby uniknąć Kebab-case jest to, że myślniki mogą kolidować wizualnie z - znaków, które pojawiają się w wartości.

   {
     "bank-balance": -10
   }