簡単な (そして役に立たない) 答えは、どちらの方法でも問題なく動作するということです。
誰もが一度はこの決定に出くわすと思います.あなたが下す決定は、ウェブサイトの将来の可能性に依存します...つまり、時期尚早の最適化になりがちです...しかし、それは常に問題です.
おそらくご想像のとおり、「home」はある意味では名詞であると同時に動詞でもあるため、何をすべきかを理解するのに苦労しているのです。
答えは、ウェブサイトの構造の解釈と、どれだけの時間を利用できるかの組み合わせによって異なります...
これに取り組む時間がほとんどない場合...「ホーム」アクションを別のコントローラーに詰め込むことが、多くの場合、適切なオプションと見なされます。それは機能し、他の (おそらくより生産的な) タスクに移ることができます。
しかし、時には一歩下がって、自分がしていることと、それが「より良い」ことができるかどうかについて考えるのが良いことに同意します...この場合、「より良い」を定義するのは難しいですが、新しいコントローラーのホーム アクションは測定可能なほど高速になります...そして、それがコントローラー内の唯一のアクションである場合...構造的に、既存のコントローラーに追加するだけの方が良いかどうかは議論の余地があります...
そこで、ほとんどが哲学的な議論から始めます... 言い換えれば、他の答えよりも「より正しい」答えはありません - それは好みと状況の問題です. この場合、議論は構造をより RESTful にすることにかかっています。
RESTful アーキテクチャに忠実であるためには、実際にアクションを独自のコントローラーに移動することになりますが、最初にエンティティが何であるかを特定する必要があります。「ホーム」ページは、特定の db エンティティとして容易に識別できないことがよくあります...それはより多くの場合、ポータル ページです。
エンティティを選択できる場合もあります。たとえば、オンライン ショップには、実際には "products#index" のバリエーションであるホームページがあったり、"home" ページが UserAccount#show ページである場合もありますが、多くの場合、あなたのホームページは単純ではなく、複数のエンティティからの情報を組み合わせます...したがって、「正しい」アーキテクチャを決定するのが難しいのはなぜですか。
特定のエンティティを識別できない場合は、アクションを特定のコントローラーに移動するかどうかについて有効な議論があります。
ただし、サイトのアーキテクチャを中心とした新しい「エンティティ」をいつでも作成できます。これは、サイトのエンティティ固有ではない他のページ (T&C や「会社について」ページなど) を考え出す場合に特に可能性があります。
通常のフォールバックは、Active Recordモデルにリンクされていない「PageController」(または類似の名前) ですが、よりあいまいなエンティティ (この場合は、Web サイトのユーザーが認識できる「ページ」) にリンクされています (例: 「ホームページ」および「T&C ページ」および「概要ページ」)。各アクションは特定のページに対するものです...
したがって、これがあなたのシステムのアーキテクチャーに対するあなたの見解によりよく適合するかどうか、そして努力する価値があるかどうかはあなた次第です... しかし、それは議論に対する私の見解です. :)