【技術書メモ7】Webを支える技術
技術書メモ7冊目！
いろんな方におすすめされる有名な本を読みました📕
RESTやHTTPについて曖昧だったので、読んで良かったです。
第1章 Webとは何か
・HTTP、URI、HTML
Webを支える最も基本的な技術はHTTP、URI、HTMLである。
URI⇨ショッピングサイトの商品でも、学術論文でも、あらゆる情報を指し示せる
HTML⇨上記の情報を表現する文書フォーマット
HTTP⇨プロトコル。上記の情報を取得したり発注したりする。
第2章 Webの歴史
・Webの成功の一因は、必要最低限のリンク機能だけを備えていたから。逆にWeb以前のハイパーメディアの問題点は、その複雑さにあった。
・オープンで不特定多数を相手にするのがWeb。各ユーザーのコンピュータ環境は特定のOSやハードウェアには統一されておらず、様々なブラウザやデバイスから1つのWebサービスにアクセスできる。これは、クライアントとサーバ間のインターフェースをHTTPというシンプルなプロトコルで固定したことで実現できている。
・RESTが普及していくのと並行して、Webはインターネット全体を飲み込み始める。以前の地図ソフトでは、地図をローカルのハードディスクにインストールして利用していたが、この方法では1台のPCにインストールできるだけのデータしか扱えない。しかし、現在の地図サービスでは、全世界の衛星写真と地図をいつでも最新の状態で利用できる。これは、サーバ側で地図を保管し、必要に応じてダウンロードしているので、実現できている。
第3章 REST WEBのアーキテクチャスタイル
・RESTはWebのアーキテクチャスタイル。システムは具体的なアーキテクチャを持っている。そのアーキテクチャを設計するときに、ただ闇雲に作っていくのではなく、アーキテクチャ設計の指針、作法、流儀、つまり、アーキテクチャスタイルを適用する。システムのアーキテクチャを決定する際の羅針盤となるのがアーキテクチャスタイル。
※アーキテクチャとは
ソフトウェアを設計するにあたり、最も必要であるのが機能や性能の全体像と製品本体の構成要素のバランス。「ソフトウェアアーキテクチャ」はそれぞれの役割を関係性を考慮しながら、ソフトウェアを設計していくより良いスタイルを指している。
・リソース
RESTにおける重要な概念の1つにリソースがある。
リソースとはWeb上に存在する情報
世界中の無数のリソースはそれぞれURIで一意の名前を持つ
URIを用いることでプログラムはリソースが表現する情報にアクセスできる
第4章 URIの仕様
・ベースURIを明示的に指定する方法
WebページをHTMLとして保存した時に、そのHTMLファイルがもともとどのURIだったのかは通常わからない。この問題を解決するために、<head>要素の中に<base>要素を入れる。
・URIの長さ制限
使用上はURIの長さに制限はないが、実装上は制限が存在する。特に、にInternetExplorerはバージョンを問わず2,038バイトまでという制限があり、事実上この長さに合わせて実装することが多くなる。
・URIの実装で気をつけること
第５章 URIの設計
・URIはリソースを表現する名詞にする
・URIを変更したい時
どうしてもURIを変更したいときは、できる限りリダイレクトをするようにする。
第６章 HTTPの基本
・クライアントとサーバ
・HTTPメッセージ
リクエストメッセージとレスポンスメッセージをまとめて「HTTPメッセージ」と呼ぶ。
・ステートレスの利点
ステートレスでは、クライアントがリクエストメッセージに必要な情報をすべて含める。
ステートレスなサーバはアプリケーション状態を覚える必要がないため、サーバ側のシステムは単純になる。
・ステートレスの欠点
パフォーマンスの低下
送信するデータ量が多くなる
認証など、サーバに負担がかかる処理を繰り返す
通信エラーへの対処
第7章 HTTPメソッド
・POST
POSTには3つの役割がある。
子リソースの作成
リソースへのデータの追加
他のメソッドでは対応できない処理
・べき等性と安全性
べき等性⇨ある操作を何回行っても結果が同じこと
安全⇨操作対象のリソースの状態を変化させないこと
・安全でもべき等性でもないPOST
POSTはリクエストの結果で何が起こるかわからない。クライアントはPOSTを複数回送ることに慎重でなければならない。
第8章 ステータスコード
・ステータスコードの分類と意味
1xx:処理中
2xx:成功
3xx:リダイレクト
4xx:クライアントエラー
5xx:サーバエラー
・よく使われるステータスコード
200 OK リクエスト成功
301 Moved Permanently リソースの恒久的な移動
400 Bad Request リクエストの間違い
第9章 HTTPヘッダ
・認証
あるリソースにアクセス制限がかかっている場合、ステータスコード401 UnauthorizedとWWWAuthenticateヘッダを利用して、クライアントにリソースへのアクセスに必要な認証情報を通知できる。
ユーザ名とパスワードによる認証方式。ユーザ名とパスワードをAuthorizationヘッダに入れてリクエストごとに送信する。Authorizationヘッダの内容は、認証方式に続けてBase64エンコードした文字列になる。
Base64エンコードした文字列は簡単にデコード可能である。すなわち、ユーザ名パスワードが平文でネットワーク上を流れていることを意味する。Basic認証を使う場合は、それが許される程度のセキュリティコードで良いのかを検討しなければならない。
・Digest認証
ただし、パスワードを暗号化するだけなので、メッセージ自体は平文でネットワーク上を流れる。メッセージを暗号化したいときはHTTPSを利用する。
・キャッシュ
サーバから取得したリソースをローカルストレージに蓄積し、再利用する手法のこと。
第10章 HTML
・フォーム
フォームはターゲットとなるURIを待つ。
その時に用いるメソッドは<form>要素のmethod属性で指定する。この属性の値はGETまたはPOSTになる。
・ハイパーメディアとしてのHTML
HTTPとURI、そしてハイパーメディアによるリンクの組み合わせで初めてwebが成り立つ。HTMLでリンクを設計する際は「リンクをたどることでアプリケーションの状態が遷移する」ことを強く意識する。
第11章 microformats
HTMLの中でさらに意味のあるデータを表現するための技術がmicroformatsである。
・microformatsの標準化
microformatsはHTML文書そのものにメタデータを埋め込む技術である。microformatsは「より簡単に、もっと気軽にwebページのセマンティクスを記述できるようにしよう」という目的のもと、様々なメタデータ記述の仕様を策定している。
・リソース表現としてのmicroformats
第12章 Atom
AtomSyndicationFormatは、RFC4287が規定するXMLフォーマットである。
第13章 AtomPublishingProtocol
このプロトコルを採用すると、ブラウザ以外のWebクライアントからブログを投稿したり、システム同士を連携したりといったことが簡単にできるようになる。
第14章 JSON
・JSONとは何か
JavaScriotの記法でデータを記述できるのが最大の特徴。
・クロスドメイン通信の制限
複数のドメインサーバと通信できず、単一のドメインのみと通信をしなければならないのは大きな制限。例えば、自サービスでは地図データと郵便番号データを保持せずに、それらを提供している他のWeb APIから適宜取得することができないから。
・<script>要素による解決法
HTMLの<acript>要素を用いると、複数のサイトからJavaScriptファイルを読み込める。
・コールバック関数を活用するJSONP
JSONPは、ブラウザの子の性質を利用してクロスドメイン通信を実現する手法。JSONPではオリジナルのJSONをクライアントが指定したコールバックを関数名でラップして、ドメインの異なるサーバからデータを取得する。
第15章 読み取り専用のWebサービスの設計
・リソース設計とは何か
第16章 書き込み可能なWebサービスの設計
・書き込み可能なWebサービスの難しさ
読み取り専用のWebサービスに比べると、考えなくてはいけないことがたくさんある。
たとえば、複数のユーザが同時に書き込みをしたらどうなるのか、複数の処理手順を実行するにはどうしたらいいか、など。
・リソースの削除
一般的には、親リソースに従属する子リソースは、親リソースの削除に伴って削除するべき。例えば、ブログエントリを削除した場合、そこに付随するコメント群を削除するのが一般的。
大量の郵便番号を作成したり更新したりする場合は、リクエストを一回一回送信すると、サーバへの接続回数が多くなり、パフォーマンスが問題になることがある。このようなときは、作成、更新したいリソースを一括で送信（バッチ処理）できるようにWebサービスを実装する。
・バッチ処理のレスポンス
問題になるのが、エラーが起きた時の対処方法。エラーが起きた時の対処法としては2つある。
2つめは、どのリソースの処理が成功して、どのリソースの処理が失敗したのかをクライアントに伝えること。
