Is there a standard on JSON naming?
I see most examples using all lower case separated by underscore, aka snake_case, but can it be used PascalCase or camelCase as well?
7 s
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.
