JSON命名有标准吗?我看到大多数例子使用所有小写字母由下划线分隔,又名snake_case,但它可以使用PascalCase或camelCase以及?
似乎有足够的变化,人们走出自己的方式,允许从所有约定转换到其他:http://www.cowtowncoder.com/blog/archives/cat_json.html
值得注意的是,上面提到的Jackson JSON解析器更倾向于bean_naming。
没有单一的标准,但我见过你提到的3种风格(“Pascal/Microsoft”,“Java”(camelCase)和“C”(下划线,snake_case))——以及至少一种,像长名称一样的串式大小写)。
这似乎主要取决于相关服务的开发人员的背景;那些有c/c++背景的人(或采用类似命名的语言,包括许多脚本语言,ruby等)通常选择下划线变体;和rest相似(Java vs . net)。例如,上面提到的Jackson库采用了Java bean命名约定(camelCase)
更新:我对“标准”的定义是一个单一的约定。因此,虽然有人可能会说“是的,有很多标准”,但对我来说,有多个命名约定,没有一个是“整体”标准。其中一个可以被认为是特定平台的标准,但考虑到JSON用于平台之间的互操作性,这可能有意义,也可能没有多大意义。
在本文档谷歌JSON风格指南(在谷歌构建JSON api的建议)中,
它建议:
属性名必须是驼峰大小写,ASCII字符串。 第一个字符必须是字母、下划线(_)或美元符号($)。
例子:
{
"thisPropertyIsAnIdentifier": "identifier value"
}
我的团队在构建REST api时始终遵循这个约定。原因如下:
首先,JSON约定应该独立于编程语言,因为我们希望api保持一致,不管有些api是使用camelCase语言(如Java)实现的,有些api是使用snake_case语言(如Python)实现的。 此外,我们的大多数客户都是web应用程序,所以camelCase是首选 如果客户端更喜欢snake_case,它仍然可以轻松地在snake_case和camelCase之间转换数据(借助库)
但是我同意如果所有的应用程序都使用相同类型的语言(例如snake_case),那么JSON约定也应该遵循。
特别是对于我在NodeJS上,如果我使用数据库,我的字段名是下划线分隔的,我也在结构键中使用它们。
这是因为db字段有很多首字母缩写/缩写,所以像appSNSInterfaceRRTest这样的东西看起来有点乱,但app_sns_interface_rr_test更好。
在Javascript中,变量都是camelCase,类名(构造函数)是ProperCase,所以你会看到类似
var devTask = {
task_id: 120,
store_id: 2118,
task_name: 'generalLedger'
};
or
generalLedgerTask = new GeneralLedgerTask( devTask );
当然,在JSON中键/字符串是用双引号括起来的,但你只需要使用JSON。stringify和传入JS对象,所以不需要担心这个。
我为此挣扎了一会儿,直到我在JSON和JS命名约定之间找到了这个愉快的媒介。
ecma - 404
JSON语法对用作名称的字符串没有任何限制,…
JSON中没有标准的键名,camelCase或snake_case应该可以正常工作。
博士TL;
以下是我认为大多数开发者都会使用的经验法则。
Technology stack | Naming convention | Reason/guide |
---|---|---|
Python » JSON » Python | snake_case | Unanimous |
Python » JSON » PHP | snake_case | Unanimous |
Python » JSON » Java | snake_case or camelCase | Lean on where the business logic resides. Take advantage of the extrinsic style of Java. |
Python » JSON » back‑end JavaScript | snake_case or camelCase | Lean on where the business logic resides. |
Python » JSON » front‑end JavaScript | snake_case | Screw the front-end anyway |
Python » JSON » you do not know | snake_case | Screw the parser anyway |
PHP » JSON » Python | snake_case | Unanimous |
PHP » JSON » PHP | snake_case | Unanimous |
PHP » JSON » Java | snake_case or camelCase | Lean on where the business logic resides. Take advantage of the extrinsic style of Java. |
PHP » JSON » back‑end JavaScript | snake_case or camelCase | Lean on where the business logic resides. |
PHP » JSON » front‑end JavaScript | snake_case | Screw the front-end anyway |
PHP » JSON » you do not know | snake_case | Screw the parser anyway |
Java » JSON » Python | camelCase or snake_case | Lean on where the business logic resides. Take advantage of the extrinsic style of Java. |
Java » JSON » PHP | camelCase or snake_case | Lean on where the business logic resides. Take advantage of the extrinsic style of Java. |
Java » JSON » Java | camelCase | Unanimous |
Java » JSON » JavaScript | camelCase | Unanimous |
Java » JSON » you do not know | camelCase | Screw the parser anyway |
back‑end JavaScript » JSON » Python | camelCase or snake_case | Lean on where the business logic resides. |
front‑end JavaScript » JSON » Python | snake_case | Screw the front-end anyway |
back‑end JavaScript » JSON » PHP | camelCase or snake_case | Lean on where the business logic resides. |
front‑end JavaScript » JSON » PHP | snake_case | Screw the front-end anyway |
JavaScript » JSON » Java | camelCase | Unanimous |
JavaScript » JSON » JavaScript | camelCase | Original |
JavaScript » JSON » you do not know | camelCase | Screw the parser anyway |
驱动因素
强加命名约定非常令人困惑,因为JSON本身并没有强加标准。但是,如果将其分解为多个组件,就可以很容易地计算出这一点。
JSON发电机
Programming language | Naming convention |
---|---|
Python | snake_case |
PHP | snake_case |
Java | camelCase |
JavaScript | camelCase |
JSON解析器
Programming language | Naming convention |
---|---|
Python | snake_case |
PHP | snake_case |
Java | camelCase |
JavaScript | camelCase |
大量业务逻辑
您必须决定哪一方具有更重的业务逻辑,是JSON生成器一方还是JSON解析器一方?
自然的归属感
Programming language | Natural belongingness |
---|---|
Python | intrinsic |
PHP | intrinsic |
Java | extrinsic |
JavaScript | intrinsic |
内在的——访问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");
一些实际的实现
谷歌映射JavaScript API - camelcases Facebook JavaScript API - snake_cases Amazon Web Services - snake_wrapped & camelwrapped Twitter API - snake_wrapped JSON-LD - camelcases
结论
为JSON实现选择正确的JSON命名约定取决于您的技术堆栈。在某些情况下,您可以使用snake_case、camelCase或任何其他命名约定。
另一件需要考虑的事情是json生成器与json解析器和/或前端JavaScript的权重。一般来说,应该把更多的重量放在业务逻辑方面。
此外,如果json解析器方面是未知的,那么您可以声明任何对您有用的东西。
我认为JSON没有官方的命名约定,但是您可以跟随一些行业领导者来了解它是如何工作的。
谷歌是世界上最大的IT公司之一,它有一个JSON风格指南:https://google.github.io/styleguide/jsoncstyleguide.xml
利用这一点,你可以在这里找到谷歌定义的其他风格指南:https://github.com/google/styleguide
正如其他人所说,没有标准,所以你应该自己选择一个。这样做的时候需要考虑以下几点:
如果您使用JavaScript来使用JSON,那么使用相同的命名约定将提供视觉一致性,并可能有一些机会更清晰地重用代码。 避免串式大小写的一个小原因是,连字符可能在视觉上与出现在值中的-字符冲突。 { “银行存款余额:-10 }
推荐文章
- 从JSON生成Java类?
- 使用Jackson将Java对象转换为JSON
- Javascript对象Vs JSON
- 在Swift中将字典转换为JSON
- 如何使用新的PostgreSQL JSON数据类型中的字段进行查询?
- 将类实例序列化为JSON
- JSON和对象文字表示法的区别是什么?
- 是否有与XQuery/XPath等价的JSON ?
- 对bash脚本函数中定义的变量使用curl POST
- 从Json转换为类型数组列表<T>
- REST API最佳实践:查询字符串中的参数vs请求体中的参数
- 打印JSON解析对象?
- JSON有查询语言吗?
- 无法加载文件或程序集'Newtonsoft。Json或其依赖项之一。清单定义与程序集引用不匹配
- 如何通过JSON文件传递有效载荷卷曲?