Соглашение об именах JSON
существует ли стандарт на именование JSON? Я вижу большинство примеров, использующих весь нижний регистр, разделенный подчеркиванием (lower_case). Но, вы можете использовать PascalCase или camelCase?
7 ответов
нет единого стандарта, но я видел 3 стиля, которые вы упомянули ("Pascal / Microsoft"," Java" (camelCase
) и "C" (подчеркивание, snake_case
)) -- а также, по крайней мере, еще один,kebab-case
как longer-name
).
это в основном, похоже, зависит от того, какие фоновые разработчики рассматриваемой службы имели; те, кто с фоном c/C++ (или языки, которые принимают подобное именование, которое включает в себя многие языки сценариев, ruby и т. д.), часто выбирают вариант подчеркивания; и аналогично (Java vs .NET). Библиотека Джексона, которая была упомянута, например, предполагает соглашение об именовании Java bean (camelCase
)
UPDATE: мое определение "стандарта" - это одно соглашение. Поэтому, хотя можно утверждать: "да, есть много стандартов", для меня есть несколько Naming Conventions
, ни один из которых не является "стандартом" в целом. Один из них можно считать стандартом для конкретной платформы, но учитывая, что JSON используется для взаимодействия между платформами, которые могут иметь или не иметь большого смысла.
в этом документе руководство по стилю Google JSON (рекомендации по созданию API JSON в Google),
он рекомендует:
имена свойств должны быть camelCased, строки ASCII.
первым символом должна быть буква, символ подчеркивания (_) или знак доллара ($).
пример:
{
"thisPropertyIsAnIdentifier": "identifier value"
}
наша команда использует настоящую конвенцию.
помещения
здесь нет стандартного именования ключей в JSON.
факторы
навязывание соглашения об именах JSON очень запутанно. Однако это можно легко выяснить, если разбить его на компоненты.
-
язык программирования для генерации JSON-формате
- Python-snake_case
- PHP-snake_case
- Java - camelCase
- JavaScript-camelCase
сам JSON не имеет стандартного именования ключей
-
язык программирования для разбора JSON
- Python-snake_case
- PHP-snake_case
- Java-camelCase
- JavaScript-camelCase
Mix матч компоненты
- Python "JSON"Python - snake_case
- Python "JSON"PHP - snake_case
- Python "JSON"Java - snake_case или camelCase
- Python "JSON"JavaScript - snake_case будет иметь смысл; винт передний конец короче
- Python "JSON" вы не знаете -snake_case будет иметь смысл; винт парсер в любом случае
- PHP "JSON"Python - snake_case
- PHP "JSON"PHP - snake_case
- PHP "JSON"Java - snake_case или camelCase
- PHP "JSON"JavaScript - snake_case будет иметь смысл; винт переднего конца в любом случае
- PHP "JSON"PHP - snake_case
- PHP "JSON" вы не знаете -snake_case будет иметь смысл; винт парсер в любом случае
- Java "JSON"Python - camelCase или snake_case
- Java "JSON"PHP - camelCase или snake_case
- Java "JSON"Java - camelCase
- Java "JSON"JavaScript - camelCase
- Java "JSON" вы не знаете -camelCase будет иметь смысл; винт парсер в любом случае
- JavaScript "JSON"Python - snake_case будет иметь смысл; винт переднего конца в любом случае
- JavaScript "JSON"PHP - snake_case будет иметь смысл; винт переднего конца в любом случае
- JavaScript "JSON"Java - camelCase
- 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 предпочитает bean_naming
.
Я думаю, что нет официального соглашения об именах для JSON, но вы можете следить за некоторыми лидерами отрасли, чтобы увидеть, как это работает.
Google, которая является одной из крупнейших ИТ-компаний мира, имеет руководство по стилю JSON:https://google.github.io/styleguide/jsoncstyleguide.xml
воспользовавшись, вы можете найти другие стили руководства, которые Google определяет, здесь:https://github.com/google/styleguide
Как заявили другие, стандарта нет, поэтому вы должны выбрать его сами. Вот несколько вещей, которые следует учитывать при этом:
Если вы используете JavaScript для использования JSON, то использование одного и того же соглашения об именах для свойств в обоих обеспечит визуальную согласованность и, возможно, некоторые возможности для повторного использования более чистого кода.
-
небольшая причина, чтобы избежать кебаб-дело в том, что дефисы могут столкнуться визуально с
-
символы, отображаемые в значениях.{ "bank-balance": -10 }