営業職の俺がエンジニアになる〜群馬Web化計画編〜

2017年に未経験からエンジニアに転職をした私が群馬でイノベーションを起こすまでの備忘録です。

今週腹落ちしたこと

先日の記事の後半で記載したように、Railsの参考書を購入した読み進めていて、色々な疑問にぶつかっています。その中でも、疑問にぶつかった結果、腹落ちした内容を記載していきます。(記載することにより自分の理解を再度定着させつつ、間違いがあればそれを正せるため)

記載している内容としてはかなり基礎中の基礎レベルの話ですので、ご容赦くださいませ。

HTTPのザクッとした動き方

当たり前かもしれませんが、クライアント側からHTTPリクエストを送り、送られてきた内容に対してHTTPレスポンスを返す、という動きを今更ながらに理解しました。

そしてHTTPリクエストの中身にはいくつかあり、HTTPメソッドやURLを載せるリクエスト行、クライアント側の環境情報を載せるHTTPヘッダー、場合により(POSTメソッドにより情報が送られる等)情報を載せるHTTPボディ、この3つで構成されているとのこと。

また、同様にHTTPレスポンスも3つの要素で構成されており、サーバーのステータス(200、404、500等)を載せたレスポンス行、レスポンス時と同様に環境情報などを載せたHTTPヘッダー、HTMLや情報を載せたHTTPボディ、サーバーから送られてくる。

サーバーのステータスはこちら側で設定もできるため、必ずしもデフォルトのステータスで対応をする必要があるわけではない。

ルーティングにおけるresourcesとresourceの使い分け

Ruby on Rails 5 アプリケーションプログラミングでは下記のように記載がありました。

resourcesは複数のリソースを管理するために定義をし、resourceは単数のリソースを管理するために定義する。

まぁ、読んで字のごとくですね。でも、どういう時に複数のリソースを定義して、どういう時に単数のリソースを定義すべきなのか、がイマイチわかりませんでし。

なんならresourcesの方がindexアクションも含まれてるし、こっちの方がいいんじゃない?大は小を兼ねるでしょ。という発想でした。

でも、それじゃあかんですね。プロのエンジニアを目指すのであれば、なぜそのコードを書いたのか、ということを説明できなければならない、勉強中の身でありながらそうした姿を目指すのは何よりも大事だと思います。

ということで、色々調べ、師匠にも聞いてみたところ、腹落ちしました。

resourcesで定義すべき場合

1人のユーザーがひとくくりの情報(例えばPost)を複数の管理する必要性があるのであればresourcesで定義する方が良い。なぜならば、resoursesで定義するとposts/:idというURLが生成され:id単位で管理しやすくなるめ。

resourceで定義すべき場合

1人のユーザーが1つの情報(極端な話Userとか)しか管理しない場合はresourceで定義した方が良い。resourcesで定義できなくもないが、users/21などでURLを叩くと意図しない形でユーザー情報が表示されることになってしまう。もちろん何か意図がありresourcesで定義する分には問題ないですが。

まぁ、何でもかんでもresourcesやresourceで管理すればいいという問題でもなさそうなので、resourceでの定義とそうじゃない定義をどう使い分けて行くのか、についても考えなければならなさそうです。

というのが、ここ最近で腹落ちした内容です。学んだばかりのため解釈の違いがあった場合は、ご指摘いただけますと幸いです。