Соглашение об именовании JSON

в этом документе руководство по стилю Google JSON (рекомендации по созданию JSON API в Google),

он рекомендует:

1. имена свойств должны быть camelCased, строки ASCII.

2. первый символ должен быть буквой, подчеркиванием ( _ ) или знаком доллара ($).

пример:

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

наша команда использует настоящую конвенцию.

помещения

здесь нет стандартного именования ключей в JSON.

факторы

навязывание соглашения об именовании JSON очень запутанно. Однако это можно легко понять, если разбить его на компоненты.

1. язык программирования для генерации JSON-формате

   • Python-snake_case
   • PHP-snake_case
   • Java - верблюжьего
   • JavaScript-camelCase

2. сам JSON не имеет стандартного именования ключей

3. язык программирования для разбора JSON

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

Mix-match компоненты

1. Python "JSON"Python - snake_case
2. Python "JSON" PHP - snake_case
3. Python "JSON"Java - snake_case или camelCase
4. Python "JSON"JavaScript - snake_case будет иметь смысл; винт передний конец в любом случае
5. Python "JSON" вы не знаете - snake_case будет иметь смысл; винт парсер в любом случае
6. PHP "JSON"Python - snake_case
7. PHP "JSON" PHP - snake_case
8. PHP "JSON"Java - snake_case или camelCase
9. PHP "JSON"JavaScript - snake_case будет иметь смысл; винт передний конец в любом случае
10. PHP "JSON" PHP - snake_case
11. PHP "JSON" вы не знаете - snake_case будет иметь смысл; винт парсер в любом случае
12. Java "JSON"Python - camelCase или snake_case
13. Java "JSON" PHP - camelCase или snake_case
14. Java "JSON"Java - camelCase
15. Java "JSON"JavaScript - camelCase
16. Java "JSON" вы не знаете - camelCase будет иметь смысл; винт парсер в любом случае
17. JavaScript "JSON"Python - snake_case будет иметь смысл; винт передний конец в любом случае
18. JavaScript "JSON" PHP - snake_case будет иметь смысл; винт передний конец в любом случае
19. JavaScript "JSON"Java - camelCase
20. JavaScript "JSON"JavaScript - camelCase

некоторые фактические реализации

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

выводы

выбор правильного соглашения об именовании JSON для реализации JSON зависит от вашего технологического стека. Есть случаи, когда можно использовать snake_case, camelCase, или любой другой соглашение об именах.

еще одна вещь, которую следует учитывать, - это вес, который нужно поставить на JSON-генератор против JSON-парсера. В общем, больше веса должно быть поставлено на стороне JSON-генератора, а не на стороне JSON-парсера. Это связано с тем, что бизнес-логика обычно находится на стороне JSON-генератора.

кроме того, если сторона JSON-parser неизвестна, вы можете объявить, что когда-либо может работать для вас.

особенно для меня на NodeJS, если я работаю с базами данных и мои имена полей разделены подчеркиванием, я также использую их в ключах структуры.

Это потому, что поля БД имеют много аббревиатур / сокращений, так что что-то вроде appSNSInterfaceRRTest выглядит немного грязно, но app_sns_interface_rr_test приятнее.

в переменных Javascript все camelCase и имена классов (конструкторы) являются ProperCase, так что вы увидите что-то как

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

или

generalLedgerTask = new GeneralLedgerTask( devTask );

и, конечно, в JSON ключи/строки заключены в двойные кавычки, но тогда вы просто используете JSON.stringify и передать в JS объекты, так что не нужно беспокоиться об этом.

Я немного боролся с этим, пока не нашел эту счастливую среду между соглашениями об именах JSON и JS.

Кажется, что есть достаточно вариаций, что люди выходят из своего пути, чтобы разрешить преобразование из всех конвенций в другие: http://www.cowtowncoder.com/blog/archives/cat_json.html

Примечательно, что упомянутый Jackson JSON parser предпочитает bean_naming.

Я думаю, что нет официального соглашения об именах для JSON, но вы можете следить за некоторыми лидерами отрасли, чтобы увидеть, как это работает.

Google, которая является одной из крупнейших ИТ-компаний мира, имеет руководство по стилю JSON:https://google.github.io/styleguide/jsoncstyleguide.xml

воспользовавшись этим, вы можете найти другое руководство по стилям, которое определяет Google, здесь:https://github.com/google/styleguide

как другие заявили, что нет стандарта, так что вы должны выбрать один самостоятельно. Вот несколько вещей, которые следует учитывать при этом:

1. Если вы используете JavaScript для использования JSON, то использование одного и того же соглашения об именах для свойств в обоих случаях обеспечит визуальную согласованность и, возможно, некоторые возможности для повторного использования более чистого кода.

2. небольшая причина, чтобы избежать kebab-case является то, что дефисы могут столкнуться визуально с - символы, которые появляются в значениях.

   {
     "bank-balance": -10
   }