My team consistently follows this convention when building REST APIs. There are some reasons:
First, the JSON convention should be independent of the programming languages because we want our APIs to be consistent doesn't matter whether there are some APIs implemented using a camelCase language (e.g. Java), some others using snake_case language (e.g. Python).
Also, most of our clients are webapp so camelCase is preferred
If the client prefers snake_case, it still can easily convert data between snake_case and camelCase (with the help of libraries)
But I agree that if all the applications use the same type of language (e.g. snake_case), the JSON convention should also follow.
The JSON syntax does not impose any restrictions on the strings used as names,...
There is no standard naming of keys in JSON and that camelCase or snake_case should work fine.
TL;DR
Here is a rule-of-a-thumb which I think most of the developers use.
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
Driving factors
Imposing a naming convention is very confusing because JSON alone does not impose a standard. However, this can easily be figured out if you break it down into components.
You have to decide which side has the heavier business logic, is it the JSON generator side or the JSON parser side?
Natural belongingness
Programming language
Natural belongingness
Python
intrinsic
PHP
intrinsic
Java
extrinsic
JavaScript
intrinsic
Intrinsic - Programming language where JSON is accessed naturally similar to accessing native objects and arrays.
Extrinsic - Programming language where JSON is accessed differently than accessing native objects and arrays. Below is an example of Java's com.google.gson package:
/**
* Using a method to access a property instead of using the standard 'dot.syntax'
*/
JsonElement.getAsString("snake_cased_key");
Choosing the right JSON naming convention for your JSON implementation depends on your technology stack. There are cases where you can use snake_case, camelCase, or any other naming convention.
Another thing to consider is the weight to be put on the JSON-generator vs the JSON-parser and/or the front-end JavaScript. In general, more weight should be put on business logic side.
Also, if the JSON-parser side is unknown then you can declare what ever can work for you.
Personal opinion
I know we are not meant to do opinions here in SO but it is the best way to distinguish us humans from AIs. My take is that we all should at least favor snake_case. The reason is that if you take into account the database storage aspect, huge chance is that the data are stored in snake_case keys/columns.
There is no SINGLE standard, but I have seen 3 styles you mention ("Pascal/Microsoft", "Java" (camelCase) and "C" (underscores, snake_case)) -- as well as at least one more, kebab-case like longer-name).
It mostly seems to depend on what background developers of the service in question had; those with c/c++ background (or languages that adopt similar naming, which includes many scripting languages, ruby etc) often choose underscore variant; and rest similarly (Java vs .NET). Jackson library that was mentioned, for example, assumes Java bean naming convention (camelCase)
UPDATE: my definition of "standard" is a SINGLE convention. So while one could claim "yes, there are many standards", to me there are multiple Naming Conventions, none of which is "The" standard overall. One of them could be considered the standard for specific platform, but given that JSON is used for interoperability between platforms that may or may not make much sense.
Notably for me on NodeJS, if I'm working with databases and my field names are underscore separated, I also use them in the struct keys.
This is because db fields have a lot of acronyms/abbreviations so something like appSNSInterfaceRRTest looks a bit messy but app_sns_interface_rr_test is nicer.
In Javascript variables are all camelCase and class names (constructors) are ProperCase, so you'd see something like
generalLedgerTask = new GeneralLedgerTask( devTask );
And of course in JSON keys/strings are wrapped in double quotes, but then you just use the JSON.stringify and pass in JS objects, so don't need to worry about that.
I struggled with this a bit until I found this happy medium between JSON and JS naming conventions.
As others have stated there is no standard so you should choose one yourself. Here are a couple of things to consider when doing so:
If you are using JavaScript to consume JSON then using the same naming convention for properties in both will provide visual consistency and possibly some opportunities for cleaner code re-use.
A small reason to avoid kebab-case is that the hyphens may clash visually with - characters that appear in values.
发布评论
评论（7）
在本文档中 Google JSON 样式指南（构建 JSON API 的建议(Google)，
它建议：
属性名称必须为驼峰式、ASCII 字符串。
第一个字符必须是字母、下划线 (_) 或美元符号 ($)。
示例：
我的团队在构建 REST API 时始终遵循此约定。有一些原因：
snake_case语言（例如Python）。camelCasesnake_case，它仍然可以轻松地在snake_case和之间转换数据>camelCase（在库的帮助下）但我同意，如果所有应用程序都使用相同类型的语言（例如
snake_case），则也应该遵循 JSON 约定。In this document Google JSON Style Guide (recommendations for building JSON APIs at Google),
It recommends that:
Property names must be camelCased, ASCII strings.
The first character must be a letter, an underscore (_), or a dollar sign ($).
Example:
My team consistently follows this convention when building REST APIs. There are some reasons:
camelCaselanguage (e.g. Java), some others usingsnake_caselanguage (e.g. Python).camelCaseis preferredsnake_case, it still can easily convert data betweensnake_caseandcamelCase(with the help of libraries)But I agree that if all the applications use the same type of language (e.g.
snake_case), the JSON convention should also follow.ECMA-404
JSON 中的键没有标准命名，并且 camelCase 或 snake_case< /em> 应该可以正常工作。
TL;DR
这是我认为大多数开发人员都使用的经验法则。
驱动因素
强加命名约定非常令人困惑，因为 JSON 本身并没有强加标准。但是，如果将其分解为多个组件，就可以很容易地弄清楚这一点。
JSON 生成器
JSON 解析器
大量业务逻辑
你必须决定哪一边业务逻辑比较重，是JSON生成器端还是JSON解析器端？
自然归属感
内在 - 访问 JSON 的编程语言自然类似于访问本机对象和数组。
Extrinsic - 访问 JSON 的编程语言与访问本机对象和数组不同。以下是 Java 的
com.google.gson的示例 包：一些实际实现
结论
为 JSON 实现选择正确的 JSON 命名约定取决于您的技术堆栈。在某些情况下，您可以使用snake_case、camelCase或任何其他命名约定。
另一件需要考虑的事情是 JSON 生成器与 JSON 解析器和/或前端 JavaScript 的权重。一般来说，应该更加重视业务逻辑方面。
另外，如果 JSON 解析器端未知，那么您可以声明什么对您有用。
个人观点
我知道我们不应该在这里发表意见，但这是区分我们人类和人工智能的最佳方式。我的看法是，我们至少都应该支持
snake_case。原因是，如果考虑到数据库存储方面，数据很有可能存储在snake_case键/列中。ECMA-404
There is no standard naming of keys in JSON and that camelCase or snake_case should work fine.
TL;DR
Here is a rule-of-a-thumb which I think most of the developers use.
Driving factors
Imposing a naming convention is very confusing because JSON alone does not impose a standard. However, this can easily be figured out if you break it down into components.
JSON generator
JSON parser
Bulk of business logic
You have to decide which side has the heavier business logic, is it the JSON generator side or the JSON parser side?
Natural belongingness
Intrinsic - Programming language where JSON is accessed naturally similar to accessing native objects and arrays.
Extrinsic - Programming language where JSON is accessed differently than accessing native objects and arrays. Below is an example of Java's
com.google.gsonpackage:Some actual implementations
Conclusions
Choosing the right JSON naming convention for your JSON implementation depends on your technology stack. There are cases where you can use snake_case, camelCase, or any other naming convention.
Another thing to consider is the weight to be put on the JSON-generator vs the JSON-parser and/or the front-end JavaScript. In general, more weight should be put on business logic side.
Also, if the JSON-parser side is unknown then you can declare what ever can work for you.
Personal opinion
I know we are not meant to do opinions here in SO but it is the best way to distinguish us humans from AIs. My take is that we all should at least favor
snake_case. The reason is that if you take into account the database storage aspect, huge chance is that the data are stored insnake_casekeys/columns.没有单一的标准，但我看到了你提到的 3 种样式（“Pascal/Microsoft”、“Java”（
camelCase）和“C”（下划线、snake_case） ) -- 以及至少还有一个，kebab-case像longer-name）。这似乎主要取决于相关服务的开发人员的背景；具有c/c++背景的人（或采用类似命名的语言，包括许多脚本语言，ruby等）通常选择下划线变体；其余部分类似（Java 与 .NET）。例如，提到的 Jackson 库假设 Java bean 命名约定 (
camelCase)更新：我对“标准”的定义是单一约定。因此，虽然有人可能会说“是的，有很多标准”，但对我来说，有多种
命名约定，但总体而言，没有一个是“标准”。其中之一可以被视为特定平台的标准，但考虑到 JSON 用于平台之间的互操作性，这可能有也可能没有多大意义。There is no SINGLE standard, but I have seen 3 styles you mention ("Pascal/Microsoft", "Java" (
camelCase) and "C" (underscores,snake_case)) -- as well as at least one more,kebab-caselikelonger-name).It mostly seems to depend on what background developers of the service in question had; those with c/c++ background (or languages that adopt similar naming, which includes many scripting languages, ruby etc) often choose underscore variant; and rest similarly (Java vs .NET). Jackson library that was mentioned, for example, assumes Java bean naming convention (
camelCase)UPDATE: my definition of "standard" is a SINGLE convention. So while one could claim "yes, there are many standards", to me there are multiple
Naming Conventions, none of which is "The" standard overall. One of them could be considered the standard for specific platform, but given that JSON is used for interoperability between platforms that may or may not make much sense.特别是对于 NodeJS 上的我来说，如果我正在使用数据库并且我的字段名称是下划线分隔的，我也会在结构键中使用它们。
这是因为数据库字段有很多首字母缩写词/缩写词，因此像 appSNSInterfaceRRTest 这样的东西看起来有点混乱，但 app_sns_interface_rr_test 更好。
在 Javascript 中，变量都是驼峰命名法，类名（构造函数）都是 ProperCase，所以你会看到类似
or 的
东西，当然在 JSON 中，键/字符串用双引号括起来，但是你只需使用 JSON.stringify 并传入 JS对象，所以不必担心。
我在这个问题上遇到了一些困难，直到我找到了 JSON 和 JS 命名约定之间的折衷方案。
Notably for me on NodeJS, if I'm working with databases and my field names are underscore separated, I also use them in the struct keys.
This is because db fields have a lot of acronyms/abbreviations so something like appSNSInterfaceRRTest looks a bit messy but app_sns_interface_rr_test is nicer.
In Javascript variables are all camelCase and class names (constructors) are ProperCase, so you'd see something like
or
And of course in JSON keys/strings are wrapped in double quotes, but then you just use the JSON.stringify and pass in JS objects, so don't need to worry about that.
I struggled with this a bit until I found this happy medium between JSON and JS naming conventions.
似乎有足够的变化，人们不遗余力地允许从所有约定转换为其他约定： http://www.cowtowncoder.com/blog/archives/cat_json.html
值得注意的是，提到的 Jackson JSON 解析器更喜欢
bean_naming。Seems that there's enough variation that people go out of their way to allow conversion from all conventions to others: http://www.cowtowncoder.com/blog/archives/cat_json.html
Notably, the mentioned Jackson JSON parser prefers
bean_naming.我认为 JSON 没有正式的命名约定，但您可以跟随一些行业领导者了解它是如何工作的。
Google 是世界上最大的 IT 公司之一，有一个 JSON 样式指南：https:// /google.github.io/styleguide/jsoncstyleguide.xml
利用这一优势，您可以在此处找到 Google 定义的其他样式指南：https://github.com/google/styleguide
I think that there isn't a official naming convention to JSON, but you can follow some industry leaders to see how it is working.
Google, which is one of the biggest IT company of the world, has a JSON style guide: https://google.github.io/styleguide/jsoncstyleguide.xml
Taking advantage, you can find other styles guide, which Google defines, here: https://github.com/google/styleguide
正如其他人所说，没有标准，因此您应该自己选择一个。这样做时需要考虑以下几点：
如果您使用 JavaScript 来使用 JSON，那么对两者中的属性使用相同的命名约定将提供视觉一致性，并可能为更清晰的代码重用提供一些机会。
避免使用短横线的一个小原因是连字符可能与值中出现的
-字符在视觉上发生冲突。<前><代码>{
“银行余额”：-10
}
As others have stated there is no standard so you should choose one yourself. Here are a couple of things to consider when doing so:
If you are using JavaScript to consume JSON then using the same naming convention for properties in both will provide visual consistency and possibly some opportunities for cleaner code re-use.
A small reason to avoid kebab-case is that the hyphens may clash visually with
-characters that appear in values.