ハイフン(ケバブケース)を使用するJSONキーへのアクセスを巡る多くの質問が表示されますが、今ではキーにキャメルケースまたはsnake_caseを使用するべきか疑問に思っています。ハイフンは、言語間で移植したときに複雑なマッピングを作成することもあります。一部のJSONデシリアライズライブラリがこれらのキーをcamelCaseスタイルに変換するのを見てきました。
例:
var something = {
"some-value": 'thing'
}
対
var something = {
"someValue": 'thing',
"some_other_value": 'thing_two'
}
JSONキーとしてanythingを使用できますが、有効なUTF-8であり、コードポイントが含まれていないため、プログラミングでキーを文字列として表すことができれば便利です。お好みの言語。同じ文字列の異なるUnicode表現を使用しないことをお勧めします(たとえば、「Ä」は1つまたは2つのコードポイントとして記述されます)。
コメントを読む:JSON辞書のキーと一致するインスタンス変数を持つクラスを作成しようとする人がいるようです。もちろん、COBOLを書かない限り、キーが「何らかの値」の場合は機能しません。これは見当違いです。 [〜#〜] i [〜#〜]必要な方法で設計されたモデルクラスがあります。 JSONは、モデルクラスを埋めるために使用されます。サーバーの担当者がキーに使用することに決めたものは何でも取り、それをmyモデルオブジェクトに入れます。
多くのJSONシリアル化システムがあり、それらが統合する言語での使用に適さないフィールド名間のマッピングを処理する以上の能力があります。ほとんどの場合、それらは使用するのが難しくなく、ほんの少しの追加の労力しか必要としません。理想的な世界ではそうする必要はありませんが、APIがすでにダッシュを使用している場合、それを変更することで病気よりも治癒が悪くなります。また、ダッシュの使用は特定の言語、特にLISPに基づく言語で最も一般的なスタイルであるため、APIのコンシューマーには、他の形式ではなくダッシュを喜んで表示する少数派がいる可能性があります。
業界でしばらく時間を過ごし、いくつかのシステムで作業した後。 JSONキーのベストプラクティスや適切な大文字小文字の区別はないと思います。書式設定(ケーシング/コードスタイルなど)の最も重要な側面は、一貫性とチームの採用です。
コードベースが断片化されており、一貫性がない場合は、チームとして会合し、一貫したスタイルについて合意してから、フォーマットをまとめて監視します。