URIの設計を考える

丁寧に学習しようと決めたのでかなりスローペース。

とりあえず基本ルールなどを学ぶ

https://qiita.com/NagaokaKenichi/items/6298eb8960570c7ad2e9

たちまちはこんな設計のサイトに遭遇。

そしてHTTPメソッドに関してはこれらのどれに当たるか、リソースがわかりやすく明示されているURIを設計する必要があると。

httpメソッド	何をするの？
POST	対応するURIをリクエストし、リソースを作成する
GET	リソースを照会して、当該ドキュメントの詳細情報を取得する
PUT	当該リソースを変更する
DELETE	リソースを削除する

そして基本ルールとして、

• アンダーバーは使わない
• 小文字でお願い
• ファイル拡張子は含めない

などがある。

インターネット層

階層	どんなのがある？
アプリケーション層	HTTP,NTP,SSH,SMTP,DNS
トランスポート層	UDP,TCP
インターネット層	IP
ネットワークインタフェース層	イーサネット

ステートフルサーバーとステートレスサーバー

ステートフルサーバーな状態

この前こんなことがあった。ランチを食べにちょっとおしゃれな注文式バイキングのところに入ったら60代ほどの女性2人がオーダーしていた。

ディスプレイに20種近く並ぶおかずを自分で5つ選びワンプレートに盛り付ける。

A：「私これとこれと・・・。」 B：「私はこれとこのカボチャのやつと」 A：「それからこれも！」 B：「やっぱりさっきのカボチやめて，こっちに」 A：「それからこれと・・・アイスコーヒーと，あと何品だっけ？」

・・・

いっぺんに言え！

てなる。

これがステートフルです。

途中の状態をサーバが常に覚えてないといけない。

ステートレスサーバーな状態

同様の状態で奥様方をステートレスにしましたら，

A：「私はこれとこれとこれ，あとこれとこれ。そしてカフェラテでお願い。」 B：「私はね、これとこれ、あとこれ。そしてこれとれ。アイスコーヒーをお願いします。」

一つの会話ですみますね。

提携文に沿って1クライアントから注文を全て受けるイメージ。 一発で言ってくれるのでサーバはアプリケーション状態を保持しておく必要がない。 便利！

ただ欠点もある

ステートレスの欠点はパフォーマンス低下が挙げられる。 理由としては、 - 送信するデータ量が多くなる - 認証など、サーバに負荷がかかる処理を繰り返す

アプリケーション状態を保持しないということは全てきっちり承るよ、だからその分は一回の送受信が大きくなるから、クライアント数が多いとしんどいな〜という印象。

HTTPって何？

HTTPメソッドではクライアントが行いたい処理をサーバーに伝える任務がある。

8つあるけど前に主要な4つは書いたので省略。

前回の記事の続きで細かいところを見ていくと、

POST

GETに次いで利用頻度が高いメソッド。 代表的な機能は、子リソースの作成。

#リクエスト
POST /URIの直下のディレクトリとしてこの名前で作成してね HTTP/1.1
HOST: ホスト名.com とか
Contents-Type : テスキトなのか画像なのかなんなのか

内容物をここに書くよ

こんな感じで子リソースを作ります。

あああ、ツイート作成ってこんな感じなのかーとなった。

またデータの追加や他のメソッドでは対応できない処理もできるのでPOSTは結構使うみたい。