JSON Naming Convention (snake_case, camelCase or PascalCase) [closed]
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:
{ "thisPropertyIsAnIdentifier": "identifier value"}
My team follows this convention.
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.
ECMA-404
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.
JSON generator
Programming language | Naming convention |
---|---|
Python | snake_case |
PHP | snake_case |
Java | camelCase |
JavaScript | camelCase |
JSON parser
Programming language | Naming convention |
---|---|
Python | snake_case |
PHP | snake_case |
Java | camelCase |
JavaScript | camelCase |
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
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");
Some actual implementations
- Google Maps JavaScript API - camelCased
- Facebook JavaScript API - snake_cased
- Amazon Web Services - snake_cased & camelCased
- Twitter API - snake_cased
- JSON-LD - camelCased
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.