Zenn
💭

Webを支える技術の第3部まで読んで

2021/01/10に公開
Web
idea

この記事は、

プログラムは突然に。任意の数列から合計がXXXになる組み合わせを求めよ。 と同じ日に書いたものであるが、

私は先輩が決算書を作ってる間、暇だったので、本屋に行き本を買って、隣で本を読んでた。

タイトルはWebを支える技術（一応、アフィリリンクです）

上司が本を持っていることを知り、購入したいなと狙っていた本である。
ただ、購入した後に気づいたが、2010年と思ったより古い本であった。

しかし、古い本を読んでる自分が好きという変態的な性格を持ち合わせているので、逆に古くて嬉しいと思った。（笑）

気になった部分をピックアップ形式で、記録を残しておく。

RESTの視点からするとCookieを使ったセッション管理は間違ったHTTPの拡張である

それが問題ということではないが、RESTの思想からすると誤っている、と。

コードオンデマンド Code on Demand

例えば、JavaScriptはコードオンデマンドである。

初め、え？ってなったのが、言われてみれば、確かにである。

なぜなら、ブラウザなどのクライアントで実行されるJavaScriptは、バックエンドのサーバからもらって、クライアントで実行するからである。

必要なJavaScriptをもらって実行するので、コードオンデマンド。

もはや、コードオンデマンドを言いたいだけになってきた。

REST = ULCODC$SS

RESTとは、

クライアント/サーバ: ユーザインタフェースと処理を分離する
ステートレスサーバ: サーバ側でアプリケーション状態を持たない
キャッシュ: クライアントとサーバの通信回数と量を減らす
統一インタフェース: インタフェースを固定する
階層化システム: システムを階層に分離する
コードオンデマンド: プログラムをクライアントにダウンロードして実行する

の６つを組み合わせたアーキテクチャスタイルのことで、

初め、「ULCODC$SS」んってなったのだが、

  • 統一インタフェース (Unified interface)
  • 階層化システム (Layerd system)
  • コードオンデマンド (Code On Demand)
  • クライアント/サーバ (Client server)
  • キャッシュ (Cache)
  • ステートレスサーバ (Stateless Server)

の頭文字を取ったらしい。
なんとも強引であった。（嫌いじゃない。むしろ好き）

Cool URI's don't change by Tim Berners-Lee in 1998

クールじゃないURI見つけたら、言ってみたい一言である。

クライアントネゴシエーション (Client Negotiation)

HTTPの機能

GET /2010/05/01/press HTTP/1.1
Host: example.jp
Accept-Language: ja,en_us;q=0.7,en;q=0.3

と言った形で、クライアントは希望する言語を指定できる。
サーバが利用するかどうかはサーバ次第。

HTTPヘッダのAccept-Languageは知っていたが、クライアントネゴシエーション。という単語を知らなかった。
これも今後、言ってみたい。

マトリクスURIの;と,の違い

;は、順序に意味がない
,は、順序に意味がある

なので、例えば、緯度経度を表したい場合は、
http://example.jp/map/35.705471,139.751898

と言った形で、順序ありを使うべき。

URIフラグメントはクライアント側で処理するので、リクエストメッセージに含めない

例えば、
http://example.jp:8080/search?q=test#n10

のリクエストメッセージは

GET /search?q=test HTTP/1.1
Host: example.jp

になるとのこと。

FTPはステートフル

意識したことがなかったが、これも言われてみればであった。

ステートフルで、サーバがクライアントのディレクトリの場所を覚えてるので、ディレクトリ移動で相対パスが利用できる。

リソース作成におけるPOSTとPUTの使い分けは、URIの決定権がサーバにあるかどうか

Twitterみたいに、URIがTwitter指定の場合は、POST

wikiみたいに、URIを自分で決めたい場合は、PUT

というのが、慣習？らしい。
何で定められてるのか明確な記載はなかった。

ただ、URIを自分で決める イコール クライアントがサーバのことを把握しており、結合度が高まるので、特別な理由がない場合はPOST推奨とのこと。

503の時にRetry-Afterでサービス再開時期を伝える

HTTP/1.1 503 Service Unavailable
Content-Type: text/plain; charset=utf-8
Retry-After: 3600

とすることで、3,600秒後に、サービス再開しますよと伝えられるらしい。
使ったこともなかったし知らなかった。

リソースがないのに200と返すのはSEO的に微妙

アプリケーションの設計によっては、ファイルが見つからなくても200を返して、メッセージにFile not foundと伝えることがあるらしい。
私はみたことがないが。

閉じた世界にいる分には問題ないが、検索エンジンのロボットがリソースがあると間違えることがあるので、注意が必要とのこと。

最後に

基礎知識でも、改めて読むと知らないことや、ちゃんと理解していなかったことが分かり、とても勉強になる。
ただし、RFCの原文を読むなど深くは読み込んでいないが。

現在、150/370ページと半分に満たないが、連休中に読み切れるかな。

Discussion