https://www.amazon.co.jp/Web%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93-HTTP%E3%80%81URI%E3%80%81HTML%E3%80%81%E3%81%9D%E3%81%97%E3%81%A6REST-WEB-PRESS-plus/dp/4774142042
を読んだので、自分の言葉でのまとめです
長いので１部につき１ページにまとめます。
「本書の構成」とかは飛ばしてます。
他の記事はこちら↓
２部 URI：https://qiita.com/Ohtak/items/af65c9762f67003277f3
１章 Webとは何か
1.1 全ての基盤であるWeb
現在のコンピュータでもっとも重要なソフトウェアはブラウザ。
色々なサービスにWebを通じてアクセスしている。
1.2 さまざまなWebの用途
次の３つがある
・Webサイト
もっとも身近な例。Webサイトの構成は様々だが、ユーザーからすればそれを気にしなくて済むことがWebの大きな特徴
・ユーザーインターフェースとしてのWeb
設定画面にブラウザを使っている例や、HTMLでのヘルプ記事の例が挙げられる
・APIとしてのWeb
プログラム上でデータをやり取りするためのもの。データにはプログラムが解釈しやすいxmlやjsonが使われる。
1.3 Webを支える技術
Webを構築する技術的要素は大きく分けて下記
HTTP、URI、HTML
URIはページを指し示すために、HTMLはサイトの情報を表現する文書フォーマットとして、HTTPは情報のやり取りにそれぞれ使われる。
これらはとてもシンプルな技術で、これらに支えられたWebはハイパーメディアシステムと分散システムの２つの側面を持っている
ハイパーメディア
テキストや画像、音声、映像などをハイパーリンク（あるいは単にリンクとも呼ばれる）で結びつけて構成したシステムのこと。
ユーザーが非線形にリンクを洗濯して情報を取得できる
Webには他のWebページや画像、映像へのリンクが含まれるためハイパーメディアの一例。
分散システム
複数のコンピュータをつなげて情報処理させるシステムのこと。
複数台のパワーが使えるので膨大な処理も可能になる
Webも膨大なものなので、この分散システムが使われており、プロトコルがシンプルなため、これだけの規模のシステムが実現できている。
第２章 Webの歴史
2.1 Web以前のインターネット
初期のインターネットにはWebが存在せず、当時はTCP/IPに加えバケツリレー式のUUCPもあったため、単にメールを送るだけでも遅延があった。
このときのアプリケーションは
- FTP（ファイル交換）
- telnet（UNIXホストにリモート接続）
- Gopher（コンテンツを簡単に公開するためのアプリ）
など
2.2 Web以前のハイパーメディア
Memex
1945年に発表。ハイパーメディアの起源
システムでなく構想だが、電気的に接続した本やフィルムを相互リンクし、それをたどって次々に表示するという現在のWebに似たものだった。
これがのちに影響を与えた。
Xanadu
1965年、Nelsonがハイパーメディアとハイパーテキストという言葉を考案。
現在のWebをさらに進化させた機能を持つXanaduを構想し開発を始めたが、複雑すぎて頓挫
HyperCard
1987年にBill AtkinsonがAppleで開発。
「カード」と呼ばれる文書を単位にして相互にリンクを貼り、スクリプト言語HtperTalkによるプログラムを実行できるスタンドアロンのWebサービス。
成功し、初の実用的なハイパーメディアになった。
Web以前のハイパーメディアの問題点
Webはもっとも普及したハイパーメディアの実装となった。
Googleのページランク、トラックバックもリンクを前提に設計されている
ただ、単方向リンクしかサポートしていない、リンク切れの可能性がある、バージョン管理やトランスクルージョンの機能がないなどから不完全なハイパーメディアとする声もある。
それでも成功した要因としては必要最低限のリンク機能だけを備えていたことがある。
Web以前のハイパーメディアの問題点は複雑すぎたこと。
2.3 Web以前の分散システム
初期のコンピュータは科学技術計算などの専門目的で作られていた。
1960年代にメインフレームが開発され、複数の目的で使用できるようになった。このころの利用形態はホストコンピュータに端末を接続し、ホストコンピュータで集中的に処理するというもの。
1970年代以降、ダウンサイズが進み１つ１つのコンピュータの性能が上がったことで複数のコンピュータを組み合わせて処理を分散させる手法が登場する。
RPC
リモートのサーバーで実行しているプログラムをクライアント側から呼び出せる。
有名なものとしてはSunRPC、アポロ、DCE
このころ（1980年代後半）はUNIXベンダーによる競争が激しく、各社とも自社の分散システムを標準にしようとしていた
CORBA、DCOM
RPCは関数を呼び出す仕組みだったが、オブジェクト自体をリモート側に配置する「分散オブジェクト」と呼ばれる技術が考案された。
代表例はCORBA。Microsoftは対抗してDCOMを開発。
どちらもIDL（Interface Definition Langage）でオブジェクトのメソッドを定義、実装ではネットワーク越しにシリアライズしたメッセージを交換する。
この点ではRPCと同じ。
ただ汎用的なオブジェクト機能を実現しようとした結果、非常に複雑な仕様となり、CORBAとDCOMの間の互換性もなかった。
Web以前の分散システムの問題点
RPCは今でもNFSなどの実装に使われているが、現実的に動作するのは通信相手がある程度決まっているイントラネット環境まで。
大規模な異種分散環境では動作しない。それは次の問題がRPCシステムに共通して存在するから。
性能劣化の問題
ネットワーク越しに関数を呼び出すのは同一プロセス内で行うのと比べて何倍も時間がかかる。しかも一般に関数の粒度が小さいため、何回も呼び出しする必要がある。
データ型変換の問題
プログラミングごとにサポートするデータ型が異なるため、複数の言語が混在してるとバグる
インターフェースバージョンアップ時の互換性の問題
サーバーのインターフェースを更新した場合、古いクライアントに対して下位互換性を保てない
負荷分散の問題
サーバー上にクライアントのアプリケーション状態を保存するため、サーバー間で状態を共有しなければならず、多数のサーバーで負荷分散するのが難しい。
2.4 Webの誕生
1980年代までにハイパーメディア構想が生まれ、インターネットが登場し、分散システムが構築されたタイミングでWebが生まれた。
1990年にTim Barners-LeeがWebの提案書を書き、同年のクリスマス休暇にブラウザとサーバーを完成させた。
これ以降Webが普及し始め、1993年にイリノイ大学のNSCAがブラウザMosaicを公開。これがWebの普及を一気に推し進めた。
Mosaicは本文にインラインで画像を混在させることができ、現在のIEやFirefoxの源流になっている
ハイパーメディアとしてのWeb
Webはそれ以前のハイパーメディアとは違い、インターネットを使ったハイパーメディアとして設計された。
そのため不特定多数の情報をリンクさせ合うことができ、システムを大規模化しやすいという利点を持つ。
反面、情報の集中的な管理は難しいためリンク切れを起こしやすい。
もう一つの特徴は単方向リンクだけであること。
もともとリンクの概念では外部からリンクを取り込むという拡張リンクの考え方もあり、Webにそれを取り込もうとした動きもあったが結局単方向リンクのみが使われている。
ユーザーにとってはわかりやすく、かつ実装しやすいためここまで普及したと言える。
分散システムとしてのWeb
RPCは閉じたネットワーク環境で決まった相手と通信する上では優れているが、逆にオープンな環境で不特定多数のクライアントにサービスを提供するのには向いていない。
これに向いているシステムがWeb。
OSやハードウェアがバラバラでも問題ないのはHTTPというシンプルなプロトコルに固定したため。
2.5 Webの標準化
Webの仕様策定
Web以前のインターネット標準は全てIETFとして定められていたが、Webの普及のスピードにIETFでの仕様策定が追いつかず、各社で相互運用性に欠ける状態が発生した。
そのためHTTPとURIとHTMLの標準化が求められ、Tim Barners-LeeがW3Cを設立。
W3CによってHTML, XML, HTTP, URI, CSSなどの標準化作業が行われた。
RESTの誕生
また、Baebers-Leeと共にHTTP1.0とHTTP1.1の仕様策定に関わったRoy FieldingがWebの分析を行い、１つのアーキテクチャスタイルとしてまとめ、これを「REST」と名付けた。
さまざまなハイパーメディアフォーマットの誕生
初期のWebではHTMLが唯一のハイパーメディアフォーマットだったが、その後もHTMLで対応できない要望が出てくるにつれて新しいハイパーメディアフォーマットが誕生した。
HTMLに様々な意味を持たせるmicroformat、Webページの新着情報をサーバーで配信、それをチェックするRSSが提案された
（RSSについては最終的にIETFでAtomが標準化される。）
HTMLやAtomはXMLベースのため表記が冗長すぎるためより単純なデータフォーマットがいくつか提案された。
その中でJSONがデファクトスタンダードとなった。
2.6 Web APIを巡る議論
Webの用途が多様化するとプログラムから自動処理を行いたいという要望が出始める。
1990年代後半から2000年代前半にかけてWeb APIの議論が起こった。
SOAPとWS-*
様々なグループがWebをプログラムから利用できるように拡張しようとした。
特に大きかったのがRPC/分散オブジェクトのグループで、RPCと同じ方法論でWeb上の分散オブジェクトを実現しようとした。
基本的なプロトコルはSOAPで、これはHTTPをアプリケーションプロトコルでなくトランスファープロトコルとして扱い、HTTP上で独自のメッセージを転送する。
これはメッセージ転送の方法だけを定めた仕様なので、サービスごとのプロトコルも定義しなくてはならない。
これを各社ばらばらに定義するとまた失敗するため、WS-Security、WS-TransactoinなどWS-*と呼ばれる仕様群が次々に提案された。
が、同じような仕様が複数乱立したためまた標準化競争が起こった。
SOAP 対 REST
SOAPとRESTに関する論争は2003年ごろがピークだったよう。
RESTの普及に弾みをつけたのは2002年に登場したAmazon Webサービスだった。
Amazonは自社が扱う書籍やそのほかの商品の情報をWebを通じてプログラムから取得できるようにした
その際、SOAPを用いた形式とURIをHTTPでGETする形式（便宜上、REST形式と呼ばれた）の二つを用意した。
その結果、SOAP：RESTの利用比率が20:80だったことで論争が激化。
また、2004年から始まったWeb2.0の流れの中でGoogleやAmazonがREST形式のWeb APIを提供し始める。
ここで重要だったのはいろいろなAPIが提供する情報を組み合わせて１つのアプリケーションを実現するマッシュアップという手法。
ここで手軽さが求められ、最終的にRESTスタイルの方が受け入れられていった。
SOAPとWS-*の敗因
SOAPとWS-*の問題点としては、RPCの技術的問題点をさらに広げてしまったことと、SOAPが標準として確定しないうちに各社が実装を始めてしまい、結果的に相互運用性に欠けたことがあげられる。
2.7 すべてがWebへ
RESTが普及してくのに並行してユーザーインターフェースはWebで統一され始め、エンドユーザはWebだけを意識するようになった
背景にajaxとCometなどの技術的ブレークスルーがある。
これによりユーザーイインターフェースの使い勝手が向上しつつある。
例えば、以前はローカルに保存するしかなかった地図データをリモートからとってくることにより、全世界の衛星写真を最新の状態で利用できる。
サーバー側では地図データをまとめて保管し、必要に応じて画像をダウンロードしてるからこそ実現できる。
第３章 REST
3.1 アーキテクチャスタイルの重要性
RESTはWebのアーキテクチャスタイル。
アーキテクチャスタイルとは、複数のアーキテクチャに共通する性質、様式、作法、流儀を指す言葉。
具体的には、MVC、パイプ＆フィルタ、イベントシステムなど
実際にアーキテクチャを構築する際の指針になるもので、とても重要
3.2 アーキテクチャスタイルとしてのREST
Webのアーキテクチャスタイルはクライアント/サーバーでもあり、RESTでもある。
RESTはクライアント/サーバーにいくつかの制約をつけて構築されたスタイル。
ソフトウェアアーキテクチャはコンポーネントを組み合わせて実現するが、その動作を協調させるために制約が必要
よって、個別だろうがアーキテクチャスタイルを守ることが大事
以降、RESTの実装例としてWebを用いる
3.3 リソース
RESTにおける重要な概念の一つにリソースがある。
リソースは「Web上に存在する名前を持ったあらゆる情報」のこと。
リソースが名前を持つことで一意に区別できるようになる。
リソースの名前としてのURI
この一意の名前というのがURI。
これを使うことでほかのリソースと区別してアクセスすることが可能になる。
URIが備える「リソースを簡単にさししめる性質」のことを「アドレス可能性」という。
１つのリソースは複数のURIを持てる。
複数つけることでクライアントがアクセスしやすくなるが、反面どれが正式なURIかがわかりにくくなる
リソースの表現と状態
クライアントとサーバーで通信するときは具体的なデータを送信し合うことになるが、このときやり取りするデータを「リソースの表現」という。
一つのリソースは複数の表現を持てる。
また、リソースには状態があり、それが変化すると表現も変化する。
3.4 スタイルを組み合わせてRESTを構築する
クライアント/サーバー
WebはHTTPというプロトコルでクライアントとサーバーが通信するクライアント/サーバーのアーキテクチャスタイルを採用している。
クライアントはサーバーにリクエストを送り、サーバーはレスポンスを返す。
利点としては処理をクライアントとサーバーに分割できること。
これによってクライアント側をマルチプラットフォームにできる。
クライアント側ではユーザーインターフェースを担当することでサーバー側ではデータを送るだけで良くなる。
また、複数のサーバーを組み合わせて冗長性をあげることで可用性もあげられる。
このクライアント/サーバーにスタイルを追加していくことでRESTを構築する。
下記に追加するスタイルと特徴を挙げる。
ステートレスサーバー
クライアントの状態をサーバーで管理しないことで、サーバー側の実装を簡略化できる。
簡略化することでクライアントからのリクエストに答えた後すぐに計算機リソースを解放できる。
しかし現実にはステートレスでないサーバーが多く存在する。代表例としてはCookieを使っているサーバー。
もちろんCookieならではの利点もあるので必ずしも排除する必要はないが、スタイルに反することは事実。
使うならそのことを理解した上で、必要最小限で使うべき。
キャッシュ
リソースの鮮度に基づいて一度取得したリソースをクライアント側で使い回す。
こうすることで通信の手間を省き、より効率的な処理ができるが、反面情報の信頼度が落ちる
統一インターフェース
URIで指し示したリソースに対する操作を統一した限定的なインターフェースで行うスタイルのこと。
例えばHTTP1.1では８つのメソッドのみが定義されており、通常それ以上増やせない。
こうしてインタフェースの柔軟性に制約を加えることで全体のアーキテクチャがシンプルになる。
Webが多様なクライアントやサーバーの実装で構成できているのは、統一インターフェースが一役買っている。
階層化システム
統一インターフェースによりシステムが階層化しやすくなる。
クライアントとサーバーの間にロードバランサやプロキシを噛ませても、サーバーにもプロキシにも同じプロトコルでアクセスできるのでクライアント側では接続先を意識する必要がなくなる。
コードオンデマンド
プログラムをサーバーからダウンロードし、クライアント側でそれを実行するスタイル。
例えばjsvascriptやFlash、javaアプレッドなどが該当する。
利点としてはクライアント側を後から拡張できること。
ただし、プログラムをクライアント側で実行してしまうことでアプリケーションプロトコルの可視性は低下する。
REST
ここまで追加したアーキテクチャスタイルをRESTと呼ぶ。
上述した通り一つ二つ違反する（＝スタイルを除外する）分には構わないが、ほとんど除外するならほかのアーキテクチャスタイルを検討すべき。
例えばP2Pは代表的なRESTでないアーキテクチャスタイル。
3.5 RESTの二つの側面
ハイパーメディア、分散システム両方の面でRESTとの関係を考える
RESTとハイパーメディア
Webではリンクをいくつか辿ることで機能を実現している。
この特徴をRESTでは「アプリケーション状態エンジンとしてのハイパーメディア」と呼ぶ
例えばブックマークアプリであればユーザーが「ブックマーク一覧を表示してる」「新しいブックマークを追加しようとしている。」といった状態がある。
この状態はリンクを辿ることによって遷移する。
このようなハイパーメディアを用いたアプリケーションには、リソースのURIがわかればほかのアプリケーションでもリソースを再利用できるという利点がある。
リソースをリンクで接続することで１つのアプリケーションを構成するという考え方はRESTの基幹をなす思想で、「接続性」とも呼ばれる
RESTと分散システム
RPCは先述した通り、多くの関数を呼び出すためシステム全体の性能劣化を引き起こす。
対してRESTではリソース同士をリンクで辿ることでアプリケーションを実現する。
このリソースはRPCでやり取りするデータよりも粒度が大きいため、全体として性能劣化を抑えられる。
また、RPCでは互換性の問題もあったがRESTでは統一インターフェースが使われてるため、マイナーバージョンアップ程度では互換性の問題が発生しない。
3.6 RESTの意義
RESTはWeb全体のアーキテクチャスタイルであり、RESTという理論があったからこそWebは成功している。
WebサービスがRESTfulになればWeb全体が良くなるので、Webサービスを作る際は意識するべき
私見
今使われている技術の勝因、使われていない技術の敗因を知ることでどのような技術が求められるかがわかりました。
特にアーキテクチャスタイルを守ることで色々なメリットがあるので意識して設計に活かします