銀行員からのRailsエンジニア

銀行員からのRailsエンジニア

銀行員から転身したサービス作りが大好きなRailsエンジニアのブログです。個人で開発したサービスをいくつか運営しており、今も新しいサービスを開発しています。転職して日々感じていること、個人開発サービス運営のことなどを等身大で書いていきます。

【技術書まとめ11】Webを支える技術 〜毎週アウトプットチャレンジ〜

毎週1冊技術書を読んでブログでアウトプットすることを目標にしており、今回は第11弾です。(↓ 歴史)

1. 「プリンシプル オブ プログラミング」を読んで思ったこと、実践していくこと
2. 【技術書メモ】パーフェクトRuby on Rails 〜毎週アウトプットチャレンジ①〜
3. 【技術書メモ】Everyday Rails - RSpecによるRailsテスト入門 〜毎週アウトプットチャレンジ②〜
4. 【技術書メモ】安全なウェブサイトの作り方・安全なSQLの呼び出し方 〜毎週アウトプットチャレンジ③〜
5. 【技術書メモ】体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 〜毎週アウトプットチャレンジ④〜
6. 【技術書メモ】なるほどUnixプロセス Rubyで学ぶUnixの基礎 〜毎週アウトプットチャレンジ⑤〜
7. 【技術書メモ】オブジェクト指向設計実践ガイド 〜毎週アウトプットチャレンジ⑥〜
8. 【技術書メモ】SQL 第2版 ゼロからはじめるデータベース操作 〜毎週アウトプットチャレンジ⑦〜
9. 【技術書メモ】現場で使えるMySQL 〜毎週アウトプットチャレンジ⑧〜
10. 【技術書】実践ハイパフォーマンスMySQL 第3版 〜毎週アウトプットチャレンジ⑨〜 

今回は、Webを支える技術 を読んでまとめました。

HTTPURIHTMLRESTなどのWebの基礎となる技術を解説している有名な本です。

エンジニアとして働くにあたってWebの基礎知識は必須であり、この本は勉強になることが多いので、通算4周読んでいます。 

Webの基礎知識の概要を掴みたい方この本に興味がある方の参考になれば嬉しいです。

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

 

f:id:ysk_pro:20181014084659p:plain

第1部 Web概論

第1章 Webとは何か

  • Webを支える最も基本的な技術は、HTTP(Hypertext Transfer Protocol)とURI(Uniform Resource Identifier)、HTML(Hypertext Markup Language)である
    • URIを使えば、世界中のあらゆる情報を指し示すことができる
    • HTMLはそれらの情報を表現する文書フォーマットである
    • HTTPというプロトコルを使って、それらの情報を取得したり発注したりできる
 

第3章 REST Webのアーキテクチャスタイル

  • RESTの重要な概念の一つにリソースがある
    • リソースとは、Web上に存在する情報である
    • リソースはURIで一意の名前を持つ
    • URIを用いることで、プログラムはリソースが表現する情報にアクセスできる
  • RESTとは次の6つを組み合わせたアーキテクチャスタイルである
    • クライアント/サーバユーザインタフェースと処理を分離する
    • ステートレスサーバ:サーバ側でアプリケーション状態を持たない
    • キャッシュ:クライアントとサーバの通信回数と量を減らす
    • 統一インターフェース:インターフェースを固定する
    • 階層化システム:システムを階層に分離する
    • コードオンデマンド:プログラムをクライアントにダウンロードして実行する
  • 個別のWebサービスやWebAPIがRESTfulになると、Webは全体としてより良くなる
 

第2部 URI

第4章 URIの仕様

  • URI(Uniform Resource Identifier)とは、リソースを統一的に識別するIDである
 

第5章 URIの設計

  • 変わらないURI(シンプルなURI)が最も良いURIである
 

第3部 HTTP

第6章 HTTPの基本

  • HTTPはRESTの重要な特徴である統一インターフェース、ステートレスサーバ、キャッシュなどを実現しているWebの基盤となるプロトコルである
  • HTTPはTCP/IPをベースにしている。TCP(Transmission Control Protcol)とIP(Internet Protocol)は、インターネットの基盤を構成する重要なネットワークプロトコルである
  • クライアントでは、1つのリクエストを送信してレスポンスを受信する際に次のことを行っている
    • リクエストメッセージの構築
    • リクエストメッセージの送信
    • (レスポンスが返るまで待機)
    • レスポンスメッセージの受信
    • レスポンスメッセージの解析
    • クライアントの目的を達成するために必要な処理
  • クライアントからリクエストを受けたサーバは次のことを行っている
    • (リクエストの待機)
    • リクエストメッセージの受信
    • リクエストメッセージの解析
    • 適切なアプリケーションプログラムへの処理の委譲
    • アプリケーションプログラムから結果を取得
    • レスポンスメッセージの構築
    • レスポンスメッセージの送信
 

第7章 HTTPメソッド

  • HTTPメソッドには、クライアントが行いたい処理をサーバに伝えるという役割があるが、メソッドは8つしか存在していない(内2つは利用頻度が高くないので割愛)
    • GET:指定したURIの情報を取得する、最も仕様頻度の高いメソッド
    • POST:GETに次いで利用頻度の高いメソッドで3つの役割がある
      • 子リソースの作成
      • 既存リソースへのデータの追加
      • 他のメソッドでは対応できない処理
    • PUT:リソースの内容の更新と、リソースの作成という機能がある
    • DELETE:リソースを削除する
    • HEAD:リソースのヘッダを取得する。GETはリソースを取得するが、HEADはリソースのヘッダだけを取得するという違いがある
    • OPTION:そのリソースがサポートしているHTTPメソッドの一覧を返す
  • リソースの作成についてのPOSTとPUTの使い分け
    • POST:クライアントはリソースのURIを指定できず、URIの決定権はサーバ側にある。よって、URIをサーバ側で決定するWebサービスの場合は、POSTを使うのが一般的である
    • PUT:リソースのURIはクライアントが決定する。よって、クライアントが決めたタイトルがそこままURIになるWebサービスの場合は、PUTを使うことが適切である
  • POSTでPUT/DELETEを代用することができる
 

第8章 ステータスコード

  • ステータスコード3桁の数字であり、先頭の数字によって次の5つに分類される
    • 1xx:処理中
    • 2xx:成功
    • 3xx:リダイレクト...レスポンスメッセージのLocationヘッダを見て新しいリソースへ接続する
    • 4xx:クライアントエラー...エラーの原因がクライアントのリクエストにある
    • 5xx:サーバエラー...エラーの原因がサーバ側にある
 

第9章 HTTPヘッダ

  • HTTP認証方式には、Basic認証とDigest認証がある
    • Basic認証:ユーザ名とパスワードによる認証方式。ユーザ名とパスワードをAuthorizationヘッダでリクエストごとに送信する。ユーザ名とパスワードが平文でネットワーク上を流れるため、HTTPS通信などの検討が必要となる
    • Digest認証Basic認証よりもセキュアな認証方式。Digestとはメッセージダイジェストの略で、あるメッセージに対してハッシュ関数を適用したハッシュ値のこと。クライアントはまず認証情報なしでリクエストを送信して、そのレスポンスの情報・ユーザ名・パスワードを使ってダイジェストを生成して、それをリクエストとして送信して送信する。サーバ上にハッシュ値のみを保管しておけば良いというメリットはあるが、毎回はじめに認証情報なしでリクエストを送信して、レスポンスを得なければいけないというデメリットもある
  • リソースがキャッシュ可能かどうか、その有効期限がいつまでなのかは、Pragma、Expires、Cache-Controlヘッダを用いてサーバが指定する
 

第4部 ハイパーメディアフォーマット

第10章 HTML

  • HTMLはハイパーメディアのため、テキストだけでなく画像や映像なども埋め込むことができる。歴史的経緯により、一般的に画像の埋め込みには<img>要素を、それ以外のオブジェクトの埋め込みには<object>要素を利用する
  • フォームはターゲットとなるURIを持ち、結果はそのURIに送られる。その時に用いるメソッドは<form>要素のmethod属性で指定し、GETまたはPOSTになる。GETの場合はターゲットURIとフォームへの入力結果からリンク先のURIを生成する。POSTの場合は、リクエストメッセージのボディにフォームの内容が入る
 

第11章 microformats

  • HTMLの中でさらに意味のあるデータを表現するための技術がmicroformatsである。microformatsを用いると、リンクの細かい意味やイベント情報などを表現できる
  • microformatsを用いると、既存のWebページをそのままWebAPIとして提供できる。必要最低限のコストでWebサービスをWebAPI化できるのがmicroformatsの最大の特徴である
 

第12章 Atom

  • Atomはブログなどの更新情報を配信するためのフィードとして知られているが、実際には幅広い分野で応用が可能な汎用XMLフォーマットである。様々なWebサービスのWebAPIとして利用することができる
 

第13章 Atom Publishing Protocol

  • AtomAtom Publishing Protocol(AtomPub)と組み合わせることで、リソースの表現だけでなくHTTPを活用した操作もできるようになる
 

第5部 Webサービスの設計

第15章 読み取り専用のWebサービスの設計

  • リソース設計とは、クライアントとサーバの間のインタフェースの設計、つまりWebサービスやWebAPIの外部設計である。どのようにリソースを分割し、URIで名前をつけ、相互にリンクを持たせるかが設計の勘所になる
  • リソース設計の指針として唯一存在しているのは、リソース指向アーキテクチャの設計アプローチで、次のステップからなる
    • Webサービスで提供するデータを特定する
    • ② データをリソースに分ける
    • (以下、各リソースに対して)
    • ③ リソースにURIで名前をつける
    • ④ クライアントに提供するリソースの表現を設計する
    • ⑤ リンクとフォームを利用してリソース同士を結びつける
    • ⑥ イベントの標準的なコースを検討する
    • ⑦ エラーについて検討する

 

おわりに

ここまで読んでいただきありがとうございます。

HTTP、URI、HTML、RESTなどについてまだ理解できてないなと思われる方は、この本を読んでみることをオススメします!

僕もエンジニアの先輩の方々に、よくこの本をオススメされていました。

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

 

次は、達人プログラマー を読む予定です。

こちらもよく話題になる本なので読むのが楽しみです。

来週も頑張ります!