Architecture Decision Recordアーキテクチャ決定記録: REST API における snake_case 対 camelCase?
決定: REST API のエンドポイントには snake_case の命名規則を使用する
状態: 承認済み
コンテキスト
REST API の命名規則には、snake_case と camelCase という 2 つの一般的な形式があります。snake_case は名前の各単語がアンダースコアで区切られる形式であり、camelCase は名前の最初の単語が小文字で、それ以降の単語の最初の文字が大文字になる形式です。この決定は、REST API にどちらの命名規則を使用すべきかを決定します。
決定の推進要因
プロジェクト内の既存の命名規則との一貫性
API に取り組む可能性のあるすべての人にとっての可読性と明確さ
REST API の命名規則に関する業界のベストプラクティスとの整合性
実装と保守のしやすさ
決定
REST API のエンドポイントには snake_case の命名規則を使用します。この選択は、次の要因によって推進されています:
一貫性: プロジェクトは既にすべてのエンドポイントに snake_case の命名規則を使用しており、プロジェクト全体の一貫性を確保するために、この規則を維持することが有益です。
可読性と明確さ: snake_case の規則はより読みやすく、理解しやすいです。アンダースコアにより単語間が明確に区切られるため、名前の意味を解析して理解しやすくなります。
業界のベストプラクティスとの整合性: snake_case の規則は業界で広く使用されており、REST API のベストプラクティスと考えられているため、プロジェクトにとって良い選択です。
実装と保守のしやすさ: 既存の命名規則を維持する方が、実装と保守が容易です。新しい規則を選択した場合、既存のすべてのコードと文書を更新する必要があるためです。
結果
この決定には、潜在的な結果があります。
プロジェクトに参加する新しいチームメンバーが snake_case の命名規則に慣れていない場合、開発に混乱やミスが生じる可能性があります。しかし、snake_case は広く使用されている規則であるため、そのようなリスクは最小限です。
camelCase の規則に大きく基づいた他のツールやフレームワークがプロジェクトで使用されている場合、命名規則間の変換に余分な労力が必要になる可能性があります。しかし、プロジェクトは snake_case の規則に標準化しているため、大きな懸念ではありません。
全体として、REST API のエンドポイントに snake_case の命名規則を使用するという決定は、一貫性があり、読みやすく、業界標準のアプローチとなる一方で、実装と保守も容易です。