500

JSON命名是否有标准？
我看到大多数示例都使用下划线分隔的所有小写字母，aka snake_case，但它可以使用PascalCase还是也可以使用camelCase？

4

7 回答 7

500

在本文档Google JSON 样式指南（在 Google 构建 JSON API 的建议）中，

它建议：

  1. 属性名称必须是camelCased的 ASCII 字符串。

  2. 第一个字符必须是字母、下划线 (_) 或美元符号 ($)。

例子：

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

我的团队在构建 REST API 时始终遵循这个约定。有一些原因：

  • 首先，JSON 约定应该独立于编程语言，因为我们希望我们的 API 保持一致，这与是否有一些 API 使用某种camelCase语言（例如 Java）实现，而另一些 API 使用snake_case语言（例如 Python）实现无关。
  • 此外，我们的大多数客户都是 webapp，因此camelCase是首选
  • 如果客户愿意snake_case，它仍然可以轻松地在snake_case和之间转换数据camelCase（借助库）

但我同意，如果所有应用程序都使用相同类型的语言（例如snake_case），那么 JSON 约定也应该遵循。

于 2013-10-10T04:58:05.420 回答
333

没有 SINGLE 标准，但我见过你提到的 3 种样式（“Pascal/Microsoft”、“Java”（camelCase）和“C”（下划线， ） ）snake_case——以及至少一种，kebab-case比如longer-name

这似乎主要取决于相关服务的背景开发人员拥有什么；具有 c/c++ 背景的人（或采用类似命名的语言，包括许多脚本语言、ruby 等）通常选择下划线变体；并以类似方式休息（Java vs .NET）。例如，提到的 Jackson 库假定 Java bean 命名约定 ( camelCase)

更新：我对“标准”的定义是一个单一的约定。因此，虽然有人可以声称“是的，有很多标准”，但对我来说，有多个标准Naming Conventions，但总体上没有一个是“The”标准。其中之一可以被认为是特定平台的标准，但考虑到 JSON 用于平台之间的互操作性，这可能有意义也可能没有多大意义。

于 2011-06-09T16:53:47.800 回答
300

ECMA-404

JSON 语法对用作名称的字符串没有任何限制，...

JSON中没有标准的键命名， camelCase或snake_case应该可以正常工作。

TL;博士

这是我认为大多数开发人员都使用的经验法则。

技术栈 命名约定 原因/指南
Python  » JSON »  Python 蛇案例 一致
Python  » JSON »  PHP 蛇案例 一致
Python  » JSON »  Java snake_case 或 camelCase 依靠业务逻辑所在的位置。利用 Java 的外在风格。
Python  » JSON » 后端 JavaScript snake_case 或 camelCase 依靠业务逻辑所在的位置。
Python  » JSON » 前端 JavaScript 蛇案例 无论如何拧前端
Python  » JSON » 你不知道 蛇案例 无论如何都要搞砸解析器
PHP  » JSON »  Python 蛇案例 一致
PHP  » JSON »  PHP 蛇案例 一致
PHP  » JSON »  Java snake_case 或 camelCase 依靠业务逻辑所在的位置。利用 Java 的外在风格。
PHP  » JSON » 后端 JavaScript snake_case 或 camelCase 依靠业务逻辑所在的位置。
PHP  » JSON » 前端 JavaScript 蛇案例 无论如何拧前端
PHP  » JSON » 你不知道 蛇案例 无论如何都要搞砸解析器
Java  » JSON »  Python camelCase 或snake_case 依靠业务逻辑所在的位置。利用 Java 的外在风格。
Java  » JSON »  PHP camelCase 或snake_case 依靠业务逻辑所在的位置。利用 Java 的外在风格。
Java  » JSON »  Java 骆驼香烟盒 一致
Java  » JSON »  JavaScript 骆驼香烟盒 一致
Java  » JSON » 你不知道 骆驼香烟盒 无论如何都要搞砸解析器
后端 JavaScript  » JSON »  Python camelCase 或snake_case 依靠业务逻辑所在的位置。
前端 JavaScript  » JSON »  Python 蛇案例 无论如何拧前端
后端 JavaScript  » JSON »  PHP camelCase 或snake_case 依靠业务逻辑所在的位置。
前端 JavaScript  » JSON »  PHP 蛇案例 无论如何拧前端
JavaScript  » JSON »  Java 骆驼香烟盒 一致
JavaScript  » JSON »  JavaScript 骆驼香烟盒 原来的
JavaScript  » JSON » 你不知道 骆驼香烟盒 无论如何都要搞砸解析器

驱动因素

强加一个命名约定是非常令人困惑的，因为 JSON 本身并没有强加一个标准。但是，如果您将其分解为组件，则可以很容易地弄清楚这一点。

JSON 生成器

编程语言 命名约定
Python 蛇案例
PHP 蛇案例
爪哇 骆驼香烟盒
JavaScript 骆驼香烟盒

JSON解析器

编程语言 命名约定
Python 蛇案例
PHP 蛇案例
爪哇 骆驼香烟盒
JavaScript 骆驼香烟盒

大量业务逻辑

您必须决定哪一方的业务逻辑更重，是JSON 生成器端还是JSON 解析器端？

自然归属感

编程语言 自然归属感
Python 固有的
PHP 固有的
爪哇 外在
JavaScript 固有的

内在- 自然访问 JSON 的编程语言，类似于访问本机对象和数组。

外部- 访问 JSON 的方式不同于访问本机对象和数组的编程语言。下面是一个Java包的例子com.google.gson：

/**
 * Using a method to access a property instead of using the standard 'dot.syntax'
 */
JsonElement.getAsString("snake_cased_key");

一些实际的实现

结论

为您的 JSON 实现选择正确的 JSON 命名约定取决于您的技术堆栈。在某些情况下，您可以使用snake_case、camelCase或任何其他命名约定。

要考虑的另一件事是 JSON 生成器与 JSON 解析器和/或前端 JavaScript 的权重。一般来说，应该把更多的权重放在业务逻辑方面。

此外，如果 JSON 解析器方面未知，那么您可以声明什么可以为您工作。

于 2014-08-18T17:29:37.747 回答
20

对我来说尤其是在 NodeJS 上，如果我正在使用数据库并且我的字段名称是下划线分隔的，我也会在结构键中使用它们。

这是因为 db 字段有很多首字母缩写词/缩写，所以像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 命名约定之间的这种愉快的媒介。

于 2014-05-01T20:04:50.130 回答
9

似乎有足够的变化，人们不遗余力地允许从所有约定转换为其他约定：http: //www.cowtowncoder.com/blog/archives/cat_json.html

值得注意的是，提到的 Jackson JSON 解析器更喜欢bean_naming.

于 2011-04-04T19:51:13.653 回答
0

我认为 JSON 没有正式的命名约定，但您可以关注一些行业领导者，看看它是如何工作的。

谷歌是世界上最大的 IT 公司之一，有一个 JSON 样式指南：https ://google.github.io/styleguide/jsoncstyleguide.xml

利用这一点，您可以在此处找到 Google 定义的其他样式指南：https ://github.com/google/styleguide

于 2016-05-15T22:06:09.053 回答
0

正如其他人所说，没有标准，所以你应该自己选择一个。这样做时需要考虑以下几点：

  1. 如果您使用 JavaScript 来使用 JSON，那么对两者中的属性使用相同的命名约定将提供视觉一致性，并可能为更清晰的代码重用提供一些机会。

  2. 避免 kebab-case 的一个小原因是连字符可能会在视觉上与-出现在值中的字符发生冲突。

    {
  "bank-balance": -10
}
于 2018-07-06T15:51:48.093 回答