#概要（著作、著者、著者経歴）
Webを支える技術
の読書レポートです。
[参考にした書き方]
(http://ledsun.hatenablog.com/entry/2013/01/21/165013)
著者：山本陽平
著者経歴：
1975年生まれ。株式会社リコーグループ技術開発本部にてWebに関連した研究開発に従事。
山本さんのブログ
http://yohei-y.blogspot.jp/
#要約
Webエンジニアであれば、誰もが知っている用語「HTTP」「URI」「HTML」「JSON」などの詳細、歴史的経緯、実用例を解説しながら、
「REST」というWebサービスの設計思想を教えてくれる本です。
#面白かった章と解説
第一部 1~3章
Webは現代社会ではなくてはならない存在であり、多くの人が常に使っている。
そのWebの根幹であるRESTは、とてもシンプルに構成されていて、
シンプルさがWebに受け入れられている点が面白いと感じました。
##RESTはシンプル
###一言でまとめると
RESTというアーキテクチャスタイル（設計モデル）は
「統一されたインターフェースを用いて、
クライアント/サーバ間で処理を分けるステートレスな分散処理モデル」
###詳しく説明すると
RESTとは、下記の6つの特徴を併せ持つ。
- クライアント / サーバ：見た目（ユーザインタフェース）と処理を分断する。
- ステートレスサーバ：サーバはクライアントの情報を持たないことにより、サーバ同士でクライアントの情報を共有する必要がなくなる。
- 統一されたインターフェース：一意に決められたリソースの場所に対して、統一されたインターフェースで操作する。
- 階層化システム：クライアントとサーバ間にプロキシやロードバランサを挟むことが出来る。
- キャッシュ：更新頻度の少ないリソースは、キャッシュから使用する。
- コードオンデマンド：クライアント側での実行処理は、サーバからダウンロードして実行。
###具体的には
RESTfulな（RESTに基づいた設計）Webサービスを作る場合、
「HTTP」プロトコル（統一インターフェース）で
「URI」（一意に決められたリソースの場所）を指定して、
「HTML」や「JSON」をCRUD（作成,読み込み,更新,削除）するサービスとなる。
#疑問点
##RESTに反すること
p.32
RESTfulなシステムであっても、完全にRESTに合わせることは難しいので、
例外も発生するとの記述があった。（セッション管理を使うことで、ステートレスではなくなるなど）
例えば、RedisなどのDBでユーザ情報を持たせることもステートレスと反するのか？
https://qiita.com/hash/items/1b0abe07544b81457ad0
##Cool URIではないもの
p.64
いいURIとは、リソースの場所を示す名詞であるべきとの記述があったのだが、
Railsの標準ルーティングのeditやnewは名詞ではないので、いいURIではないのか？
##リソース設計をするタイミングがよくわからない
今回、リソース設計の紹介がありましたが、この設計をするタイミングが分からない
Webサービスを設計するに当たって、
- クラス設計
- テーブル設計
- リソース設計
とアプリケーション側で三つも存在することになり、
新規でWebサービスを構築するときは、
どの設計から始めればいいのか？
もしくは三つの設計を少しずつ繰り返し作って、完成させればいいのか？
がよく分からない。
#仕事に活かせそうな知識、活かせそうな状況と活かし方
##HTTPヘッダを用いたデバッグ
HTTPヘッダを確認することにより、
Ajaxなどで、どのURIにリクエストを送って、何のレスポンスが返ってきているのかを確認することが出来るようになった。
サーバのログやクライアントのコンソールだけでは、分からない部分もデバッグ出来る。
###例
- レスポンスのステータスコードの確認
- TwitterなどのAPIをクライアントから叩いたときに、返ってくる値をJSONで確認
- クライアントがPostした内容の確認など
また、この本を読んだあとに、Chromeからリクエストとレスポンスの中身は読めるようにしておいた。
###ChromeでのPostリクエスト,レスポンス確認方法
https://qiita.com/CASIXx1/items/4ec20d9f463fd3d390de
##URI設計
今まで、ディレクトリマップ、Webディレクターに任せることが多かったのだが、
良いURIの定義を学ぶことにより、エンジニアでもディレクトリマップを設計やレビューをすることが可能となる。
###良いURIとは？
- URIはリソースを指すので、動詞ではなく名詞であるべき
- 言語やサーバに依存させないなど
##APIやフレームワークの評価
- どのメソッドとURIから、どのアクションを呼び出すべきなのか
（CRUDとHTTPのメソッドの対応関係） - RESTfulになっているかどうか
- リソース設計出来ているかどうかの検討
#次に読みたい関連書籍
今回は、REST,HTTP,URI,HTMLに関しての基本を学ぶことが出来たので、
その知識を活かして、Web APIに関する本を読みたい。
他には
Real World HTTP ―歴史とコードに学ぶインターネットとウェブ技術