JSONの命名に関する標準はありますか？
ほとんどの例では、アンダースコア（別名）で区切られたすべての小文字を使用してsnake_caseいますが、使用することもできますPascalCaseかcamelCase？
397104 次
7 に答える
500
このドキュメントでは、 Google JSONスタイルガイド（GoogleでJSON APIを構築するための推奨事項）、
次のことをお勧めします。
プロパティ名は、キャメルケース、ASCII文字列である必要があります。
最初の文字は、文字、アンダースコア（_）、またはドル記号（$）である必要があります。
例：
{
"thisPropertyIsAnIdentifier": "identifier value"
}
私のチームは、REST APIを構築する際に、一貫してこの規則に従います。いくつかの理由があります：
camelCaseまず、JSON規則はプログラミング言語から独立している必要があります。これは、APIの一貫性を保つために、言語（Javaなど）を使用して実装されたAPIと、言語（snake_casePythonなど）を使用して実装されたAPIがあるかどうかは関係ありません。- また、ほとんどのクライアントはwebappであるため
camelCase、 - クライアントが希望する場合でも、との間で
snake_caseデータを簡単に変換できます（ライブラリの助けを借りて）snake_casecamelCase
ただし、すべてのアプリケーションが同じタイプの言語（たとえばsnake_case）を使用する場合は、JSON規則にも従う必要があることに同意します。
于 2013-10-10T04:58:05.420 に答える
333
SINGLE標準はありませんが、あなたが言及している3つのスタイル（ "Pascal / Microsoft"、 "Java"（camelCase）、 "C"（アンダースコア、snake_case））と、少なくとも1つ以上のスタイル（のkebab-caseようにlonger-name）を見てきました。
それは主に、問題のサービスのバックグラウンド開発者が何を持っていたかに依存しているようです。c / c ++のバックグラウンドを持つ人（または多くのスクリプト言語、ルビーなどを含む同様の名前を採用する言語）は、アンダースコアのバリエーションを選択することがよくあります。同様に休憩します（Javaと.NET）。たとえば、言及されたJacksonライブラリは、Java Beanの命名規則を前提としています（camelCase）
更新：私の「標準」の定義は単一条約です。したがって、「はい、多くの基準があります」と主張することはできますが、私には複数Naming Conventionsあり、そのどれもが全体として「The」基準ではありません。それらの1つは特定のプラットフォームの標準と見なすことができますが、JSONがプラットフォーム間の相互運用性に使用されていることを考えると、あまり意味がない場合もあります。
于 2011-06-09T16:53:47.800 に答える
300
ECMA-404
JSON構文は、名前として使用される文字列に制限を課しません。
JSONには標準的なキーの命名法はなく、camelCaseまたはsnake_caseは正常に機能するはずです。
TL; DR
これは、ほとんどの開発者が使用していると思う経験則です。
| テクノロジースタック | 命名規則 | 理由/ガイド |
|---|---|---|
| Python »JSON» Python | snake_case | 全会一致 |
| Python »JSON» PHP | snake_case | 全会一致 |
| Python »JSON» Java | snake_caseまたはcamelCase | ビジネスロジックが存在する場所に頼ります。Javaの外部スタイルを利用します。 |
| Python »JSON»バックエンド JavaScript | snake_caseまたはcamelCase | ビジネスロジックが存在する場所に頼ります。 |
| Python »JSON»フロントエンド JavaScript | snake_case | とにかくフロントエンドをねじ込みます |
| Python »JSON» あなたは知らない | snake_case | とにかくパーサーをねじ込みます |
| PHP »JSON» Python | snake_case | 全会一致 |
| PHP »JSON» PHP | snake_case | 全会一致 |
| PHP »JSON» Java | snake_caseまたはcamelCase | ビジネスロジックが存在する場所に頼ります。Javaの外部スタイルを利用します。 |
| PHP »JSON»バックエンド JavaScript | snake_caseまたはcamelCase | ビジネスロジックが存在する場所に頼ります。 |
| PHP »JSON»フロントエンド JavaScript | snake_case | とにかくフロントエンドをねじ込みます |
| PHP »JSON» あなたは知らない | snake_case | とにかくパーサーをねじ込みます |
| Java »JSON» Python | キャメルケースまたはスネークケース | ビジネスロジックが存在する場所に頼ります。Javaの外部スタイルを利用します。 |
| Java »JSON» PHP | キャメルケースまたはスネークケース | ビジネスロジックが存在する場所に頼ります。Javaの外部スタイルを利用します。 |
| Java »JSON» Java | キャメルケース | 全会一致 |
| Java »JSON» JavaScript | キャメルケース | 全会一致 |
| Java »JSON» あなたは知らない | キャメルケース | とにかくパーサーをねじ込みます |
| バックエンド JavaScript »JSON» Python | キャメルケースまたはスネークケース | ビジネスロジックが存在する場所に頼ります。 |
| フロントエンド JavaScript »JSON» Python | snake_case | とにかくフロントエンドをねじ込みます |
| バックエンド JavaScript »JSON» PHP | キャメルケースまたはスネークケース | ビジネスロジックが存在する場所に頼ります。 |
| フロントエンド JavaScript »JSON» PHP | snake_case | とにかくフロントエンドをねじ込みます |
| JavaScript »JSON» Java | キャメルケース | 全会一致 |
| JavaScript »JSON» JavaScript | キャメルケース | オリジナル |
| JavaScript »JSON» あなたは知らない | キャメルケース | とにかくパーサーをねじ込みます |
推進要因
JSONだけでは標準が課されないため、命名規則を課すことは非常に混乱します。ただし、これをコンポーネントに分解すると、簡単に理解できます。
JSONジェネレーター
| プログラミング言語 | 命名規則 |
|---|---|
| Python | snake_case |
| PHP | snake_case |
| Java | キャメルケース |
| JavaScript | キャメルケース |
JSONパーサー
| プログラミング言語 | 命名規則 |
|---|---|
| Python | snake_case |
| PHP | snake_case |
| Java | キャメルケース |
| JavaScript | キャメルケース |
ビジネスロジックの大部分
ビジネスロジックが重い側を決定する必要があります。それはJSONジェネレーター側ですか、それともJSONパーサー側ですか。
自然な帰属
| プログラミング言語 | 自然な帰属 |
|---|---|
| Python | 固有 |
| PHP | 固有 |
| Java | 外因性 |
| JavaScript | 固有 |
Intrinsic-ネイティブオブジェクトや配列へのアクセスと同様に、JSONに自然にアクセスするプログラミング言語。
Extrinsic-ネイティブオブジェクトや配列へのアクセスとは異なる方法でJSONにアクセスするプログラミング言語。以下は、Javaのcom.google.gsonパッケージの例です。
/**
* Using a method to access a property instead of using the standard 'dot.syntax'
*/
JsonElement.getAsString("snake_cased_key");
いくつかの実際の実装
- Google MapsJavaScriptAPI-キャメルケース
- Facebook JavaScript API - snake_cased
- アマゾンウェブサービス-snake_cased ＆camelCased
- TwitterAPI - snake_cased
- JSON- LD-キャメルケース
結論
JSON実装に適切なJSON命名規則を選択することは、テクノロジースタックによって異なります。snake_case、camelCase、またはその他の命名規則を使用できる場合があります。
考慮すべきもう1つのことは、JSONジェネレーターとJSONパーサーおよび/またはフロントエンドJavaScriptにかかる重みです。一般に、ビジネスロジック側により多くの重みを置く必要があります。
また、JSONパーサー側が不明な場合は、何が機能するかを宣言できます。
于 2014-08-18T17:29:37.747 に答える
20
特にNodeJSの私にとって、データベースを操作していて、フィールド名がアンダースコアで区切られている場合は、それらを構造体キーでも使用します。
これは、dbフィールドに多くの頭字語/略語があるため、 appSNSInterfaceRRTestのようなものは少し厄介に見えますが、app_sns_interface_rr_testの方が優れているためです。
Javascriptでは、変数はすべてキャメルケースであり、クラス名（コンストラクター）は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
特に、前述のJacksonJSONパーサーはを優先しbean_namingます。
于 2011-04-04T19:51:13.653 に答える
0
JSONには正式な命名規則はないと思いますが、業界のリーダーをフォローして、JSONがどのように機能しているかを確認できます。
世界最大のIT企業の1つであるGoogleには、JSONスタイルガイドがあります：https ：//google.github.io/styleguide/jsoncstyleguide.xml
これを利用して、Googleが定義する他のスタイルガイドをここで見つけることができます：https ：//github.com/google/styleguide
于 2016-05-15T22:06:09.053 に答える
0
他の人が述べているように、標準はないので、自分で選択する必要があります。その際に考慮すべきことがいくつかあります。
JavaScriptを使用してJSONを使用している場合は、両方のプロパティに同じ命名規則を使用すると、視覚的な一貫性が得られ、コードをよりクリーンに再利用できる可能性があります。
ケバブケースを避ける小さな理由は、ハイフンが
-値に表示される文字と視覚的に衝突する可能性があるためです。{ "bank-balance": -10 }
于 2018-07-06T15:51:48.093 に答える