皆さん、こんにちは。
私は自分でクラウドを契約してサービスを運営しており、もっとWebについて理解したい…！
と思い、『Webを支える技術』を読みましたので、紹介していきたいと思います。
読んだ後のザックリとした感想として、Webを使うすべての人（ようは全人類…）にオススメしたい内容だと思いました。
参考までに、私はWebやシステム周りを扱うITエンジニアではなく、そこまでWebと関わりが深いわけではないですが、非常に参考になる内容だったと思います。
本書の概要
本書は、私たちの生活と切っては切れない存在となった、”Web”を支えている技術について解説しています。
本書では、Webって結局何なの？という疑問に答えてくれます。
ドメイン名の先頭についてる「www」って何のためにあるの？
検索すると、URLが「&aqs=chrome..69i57j0i546.9747j0j4&sourceid=chrome&ie=UTF-8」こんな感じになるのはなんで？
など、知らなくてもいいけど、知っていると怖くない知識を沢山身に着けることが出来ます。
前半は、Webの黎明期からの変遷をたどり、後半では、実際にWebサービスを作るとしたら、どういう過程を踏むのか？といったところまで記載されています。
Webサービスを作る予定がない人（これがほとんど）にとっても、具体例がある方が理解しやすいので最後まで読むと、理解度がグッと上がると思います。
基本情報を取った後の、単語が頭に散らばってる状態に最適
全ての人に読んで欲しいとは言いましたが、さすがにある程度ITの知識は要求されますので、『基本情報を取った人』や『ITエンジニア2年生』くらいが最適なのではないでしょうか。
基本情報をはじめとする資格試験は、確かに勉強になりますし、知識も付きますが、なかなか得た知識を自分の血肉にするのは難しいでしょう。
おそらく試験を終えた後は、ITに関する単語が頭の中に点在している状態。
会話の中で、「あーそれ試験でやったかも」といった具合です。
エンジニア2年生もそれに近いのではないでしょうか。
1年間業務を通じて、様々な知識を得たけど、どれもイマイチつながってない…
そういった方にとって本書は非常に刺さると思います。
なぜWebは、どんな環境からも使えるのか
それでは本書の中で大事だと思った部分について解説します。
そもそもWebはWWWの最後のWで、World Wide WebのWebの部分です。
その理由が本書には記載されています。
8種類しかないコマンド（HTTPメソッド）
HTTPはWebの通信規則（いわゆるプロトコル）です。
現在は最新の1.1が広く一般的に使われています。
HTTPがすごいのは、ハイパーテキスト（Webページのリンクみたいなイメージ）だけでなく、動画や画像、プログラムファイルなど、コンピュータで扱える全てのファイルを載せて転送することが出来てしまいます。
これが、Web上に画像やありとあらゆるファイルをアップロードできてしまう理由です。
そしてHTTPでは基本的にクライアントからサーバーに対して指示を出し、サーバー側で全てまとめて処理して結果だけを返す、サーバー/クライアント方式を採用しています。
これにより、クライアントはいってしまえばどんな端末でも、OSでもOKで、サーバーへの支持の出し方が正しければ環境の差を気にせず作業できるということになります。
一応、クライアント側で行うことを書いておくと、以下の6ステップです。（これさえ出来ればサービスを利用できる）
このように、あくまで主役はサーバー側です。
どんな機能を載せようが、クライアント側へ返すレスポンスメッセージとHTMLを使用通りに用意できれば、世界中の端末をお客さんにできるということです。
これが世界中で同じシステムで動くWebの秘密です。
これで怖くないステータスコード
Webの秘密がわかったということで、次はそのレスポンスメッセージに着目してみたいと思います。
皆さんもサイトを使っていて、以下の様なメッセージを受け取ったことはないでしょうか。
これらはいずれも、HTTPレスポンスのステータスコードと呼ばれるもので、クライアント側の要求が通ったのか、（なぜ）通らなかったのか、を示してくれているものです。
これらを知っていれば、いつもアクセスするサイトで上記のメッセージが出たときに、自分が悪いのか、向こうが悪いのか判断することができます。
ステータスコードの大枠と頻出のものを書いておくので、ぜひ頭に入れておいてください。
この記事でステータスコードを全て記述することはありません。
また、定義を書いても仕方ないので、ザックリと意味が分かるように書いています。
各ステータスコードの定義については、下記RFC2616のドキュメントを参照してください。
https://triple-underscore.github.io/rfc-others/RFC2616-ja.html
ステータスコードの大枠
大枠としては、先頭の1文字に着目すれば大体OKです。
ほんとに世界中で使われているシステムにしては非常にシンプルだなと思います。
1xx：処理中
処理が継続していることを示しますが、私たちが見ることはほとんどありません。
ブラウザでボタンをクリックしたらグルグル～となっているような状態と思っていただければOK。
多くの場合、放置して処理が終わるのを待つか、再度リクエストを送るように「再送しますか？」とメッセージが出てくることが多いです。
2xx：成功
リクエストが成功ことを示します。
3xx：リダイレクト
こちらは「転送」を示します。
いつものサイトをクリックしたはずなのに、なぜか別のサイトに飛ばされた。というような場面が該当します。
4xx：クライアントエラー
こちらはよく見かけるエラーで、クライアント側（利用者）が問題を抱えていることを示します。
5xx：サーバーエラー
こちらもよく見かけます。
サーバー側のエラーを示すもので、アクセス過多でダウンしている時などが該当します。
ただ、クライアント側のリクエストが正しいとは限りません。（その判定すらできてない可能性もある）
頻出のステータスコード
次は頻出のステータスコードを紹介します。
「成功した」というステータスコードを見る機会はないので、割愛して、「エラー」を中心に紹介していきますね。
301 Moved Permanentry
指定したURLが新しいURLに代わっていることを示します。
サイト移転など、移行期間中に301を設定して旧サイトにアクセスした人を新しいサイトに誘導する場合などに使われます。
400 Bad Request
4xxのエラーのうち、登録されていない（何かわからないけど）、エラーが発生したときにも使われます。
あとは、パスワードを設定する際に、「パスワードが簡単すぎる」と言われて再設定しないといけない場合や、必要事項未記入の状態で次のぺージへ進もうとした時なども該当します。
401 Unauthorized
権限がない時のエラーです。
ログインが必要なURLに対して、ログインせずに直接アクセスしようとすると、このエラーが出ることがありますが、多くの場合勝手にログイン画面に返してくれると思います。（これはサーバー側で401エラーとなった場合、ログイン画面へリダイレクトする仕組みになっているものと思います。）
404 Not Found
指定したリソースがない場合のエラーです。
URLを間違えた時にこのエラーが発生しますね。
500 Internal Server Error
サーバー内部で何かしらも問題が発生している時に返ってくるエラーです。
5xxのエラーのうち登録されていない（何かわからないけど）、エラーが発生したときにも使われるため、正直クライアント側で判断できることはあまりありません。
※とはいえ、私が運営しているデータ検索サービスでは、検索条件に該当するものが1つも無かった時の分岐が設定されてなく、500エラーを返してしまいます。（検索結果はありません。という分岐を作るべきですが…）
運営側がどういう設定をしているかによりますが、リクエスト内容を見直してみるのも有効です。
503 Service Unavailable
503を直接目にすることは少ないかもしれません。
サービス停止、いわゆるメンテナンス状態であることを示します。
Webサービスの実践的な作成例も記載
本書では、Webサービスを作り際のリソース設計についても記載されています。
なかなかレスポンスとかステータスとか言われてもピンと来ないかもしれませんが、実際のWebサービスを作成する際に、どういった動線を確保するのか、どういう操作が想定されるのか考えることで、これまで学んできたことが整理されると思います。
リソース設計とは
リソースはWebページ上にある、情報のことを指します。
画像でも動画でも文字でもファイルでも、なんでもリソースと言うことになりますが、何をどう提供するのか、サービスを開始する前にしっかり決めておこう。という考え方がリソース設計です。
リソース設計について書かれている書籍は数が少ないようで、本書では『RESTful Webサービス』が紹介されています。（今度読んでみよう）
そして紹介されているリソース設計の手順は以下です。
- Webサービスで提供するデータを特定する
- データをリソースに分ける
- リソースにURIで名前を付ける
- クライアントに提供するリソースの表現を設計する
- リンクトフォームを利用してリソース同士を結び付ける
- イベントの標準的なコースを検討する
- エラーについて検討する
正直私の運営しているサービスを見直してみると①と②くらいしかできてませんでした…
非常に内部処理が重たいことから、リソース単位でURIを設定するのを嫌っている節があるのですが、一度『RESTful Webサービス』を読んで、根本から考え直す必要があるなと感じています…
データを一意に特定するURI（URL）の設計
Webサイトにアクセスした人は、サイトのリソースを求めていますので、必要な情報を得られないと存在意義はありません。
リソースにアクセスする手段として、もっとも直接的な方法が、URIでしょう。
検索窓に、URIを入力すると自分の求めている情報に直接アクセスできるのはユーザビリティの観点から非常に重要です。
そしてURIはわかりやすい必要があります。
このサイトであれば、
ドメイン/カテゴリ/記事の名称
という形で構成されており、一応、今自分がサイトのどこにいるのか把握できる仕様になっています。
英単語を組み合わせた記事の名称にしているのは、いずれも人間が読み解けるようにという意図です。
本書では郵便番号の検索サービスを例にしていますが、
トップページ→都道府県→市町村→郵便番号
トップページ→検索窓→郵便番号
トップページ→検索窓→都道府県………
といった動線を用意しており、URIは①のドメイン/都道府県/市町村という形で作成することで、可読性をキープしつつ、各ページと郵便番号を一意に特定することを可能としています。
サービスを作るときは、一度鉄板、提供するリソースを整理して、動線を考えることが必要ですね…
まとめ
Webの技術的背景から、実用的なサービス設計のための知識まで幅広く扱っており多くの方にお勧めできる内容だったと思います。
特に、基本情報を取った後の人や、ITエンジニア2年生など、色々と知識が入ってきたけど、イマイチつながってない…という方が一読すれば、Web周りの知識を1つの線でつなげて理解することが可能です。