一流のエンジニアを目指して

2018/08/01から駆け出したエンジニアです。2019年の3月から企業でwebエンジニアとして念願の実務につくことができました!日々の学習を進めていく中で、インプット量に対して圧倒的にアウトプットする習慣が自分には根付いていないと感じたため、この技術ブログをスタートしました。同じように駆け出しているエンジニアの方々や、ベテランのエンジニアの方々にご指導頂きながら、共に飯が食えるエンジニアを目指していきたいと思っています。何卒、よろしくお願いします。

[技術書まとめ1] Webを支える技術 ~HTTP、URI、HTML、そしてREST~

今回第一回目となる技術ブログの記事に選んだ本はWebを支える技術です。

実践的なWebサービスを設計するうえで、必要となる前提知識が網羅されています。

筆者は、まだ一周読了した程度ですが、エンジニアとして仕事をしていく中で、無くてはならない知識が詰め込まれているので、これから何周もして脳内に刷り込ませていく予定です。

この本を購入しようかどうか迷っているエンジニアの方々の参考になればと思います。

 

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

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

 

 

 

第1部 Web概論

第1章 Webとは何か

  • 前提知識
    • UI(ユーザーインターフェース): ユーザーとコンピュータとが情報をやり取りする際に接する、機器やソフトフェアの操作画面や操作方法を指す。UIは、ユーザーとデジタル機器とが上手にコミュニケーションをとることを仲介しているとも言える。もっと噛み砕いて言えば、画面や見た目、使い勝手。
    • API(Application Programming Interface): APIはソフトフェアやアプリケーションなどの一部または機能を外部に向けて公開することにより、共有できるようにしたもの。)
    • HTTP(Hypertext Transfer Protocol): HTML文書や画像データなどをWebブラウザーとWebサーバー間でやり取りするために使われるプロトコル(コンピュータ同士が通信をする際の手順や規約などの約束事)。
    • URI(Uniform Resource Identifier): 情報やサービス、機器など何らかの資源(リソース)を一意に識別するためのデータの書式を定義した標準の一つ。一般的に馴染み深い呼び名にURL(Uniform Resource Locator)があるが、URIはURLよりもさらに大きな概念である。それぞれをわかりやすく示すと、URLはLocatorという英単語からもわかるように"場所を示す書き方のルール"。対してURIは"名前または場所を識別する書き方のルールの総称(親)"である。上記を寿司を例にして落とし込むとさらにイメージしやすい。下図。
    • 寿司(URI)
      ├にぎり寿司(URL)
      └ちらし寿司(URN)
      この図からもわかるように、URIを細かく分類するとURLやURNなどに分けられるのだが、にぎり寿司も種類は違うが、大きく見れば寿司なので、WebページのアドレスのことはURLと呼んでも、URIと呼んでも構わない
       
    • ハイパーメディア : テキストや画像、音声、映像など様々なメディアをハイパーリンクで結びつけて構成したシステム。
    • 分散システム : 複数のコンピュータを組み合わせて処理を分散させる形式。
  • 重要点まとめ
    • Webを支える最も基本的な技術は、HTTP、URI、HTMLである。URIを使用すれば、世界中のあらゆる情報を指し示すことができる。HTMLはそれらの情報を表現する文書フォーマットであり、HTTPというプロトコルを使って、それらの情報を取得したり発注を行ったりする。
    • Webは情報システムとして見ると、ハイパーメディアシステムと分散システムの2つの側面を持っている。

第2章 Webの歴史

  • 前提知識
    • W3C(World Wide Web Consortium) : ウェブサイト構築などで使われるウェブに関する様々な技術の標準化を目指す非営利団体。
  • 重要点まとめ
    • Webの成功の一因は必要最低限のリンク機能だけを備えていたことにある。逆にWeb以前のハイパーメディアの最大の問題点は高機能ゆえの複雑さにある。ユーザーにとってわかりやすく、かつ実装が簡単なリンクだからこそ、Webはここまで普及したと言える。
    • Web以前のインターネット標準は全てIETF(Internet Engineering Task Force)のRFC(Request for Comments)として定められていたが、Webがあまりにも急速に普及してしまったため、IETFでの仕様策定が追いつかず、相互運用性に欠ける事態が発生していた。そこで新たにWeb技術を実装している各社が集まって標準化を行う団体として1994年にW3Cを設立。
    • Webの創世期から携わってきたRoy Fieldingが、Webがなぜこんなにも成功したのかソフトウェアアーキテクチャの観点から分析を行い、1つのアーキテクチャスタイルとしてまとめた。2000年、彼はこのスタイルにREST(Representational State Transfer)と名付け、博士論文として提出する。
    • HTTPはもともとハイパーテキストを転送するためのプロトコルであったが、実際にはハイパーテキスト以外の様々なものを運んでいる。それが何なのかというと「リソースの状態」である。

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

  • 前提知識
    • アーキテクチャ : 情報システムの設計方法。設計思想、およびその設計思想に基づいて構築されたシステムの構造。
    • アーキテクチャスタイル : 複数のアーキテクチャに共通する性質、様式、作法、あるいは流儀のこと。
    • MVC : UIと内部ロジックを分離するデザインパターン。
    • リソース :  Web上に存在する、名前を持ったありとあらゆる情報。
    • クライアント/サーバ : HTTPというプロトコルでクライアントとサーバが通信するアーキテクチャ。
    • キャッシュ : リソースの鮮度に基づいて、一度取得したリソースをクライアント側で使い回すアーキテクチャスタイル。
    • 統一インターフェース : URIで指し示したリソースに対する操作を、統一した限定的なインターフェースで行うアーキテクチャスタイル。
    • 階層化システム : システムをいくつかの階層に分離するアーキテクチャスタイル。
    • コードオンデマンド : プログラムコードをサーバからダウンロードし、クライアント側でそれを実行するアーキテクチャスタイル。Javascriptなどがこれにあたる。
  • 重要点まとめ
    • RESTはWebのアーキテクチャスタイルである。MVCもアーキテクチャスタイルにあたる。
    • RESTは複数のアーキテクチャスタイルを組み合わせて構築した複合アーキテクチャスタイルである。クライアント/サーバのアーキテクチャスタイルに①ステートレスサーバ、②キャッシュ、③統一インターフェース、④階層化システム、⑤コードオンデマンドの5つのアーキテクチャスタイルを追加して組み合わせている。
    • 全てのリソースはURIで一意に指し示されている。
    • 統一インターフェースにより、あえてリソースに対する操作がHTTPのGETやPOSTなど8つのメソッドに統一(制限)することで、インターフェースの柔軟性を縮小し、全体のアーキテクチャをシンプルにしている。

第2部 URI 

第4章 URIの仕様

  • 前提知識
    • DNS(Domain Name System): IPアドレスとドメイン名の相互変換を行い、人間が理解しやすいドメイン名と、コンピュータが扱うIPアドレスの紐つけを行うシステム。
    • プロトコルコンピューターネットワークで通信を行うための手順や約束事。
  • 重要点まとめ
    • Web上に存在するリソースは、全てURIで指し示すことができ、かつHTTPで操作することができる。
    • http://yohei:pass@blog.example.jp:8000/search?q=test&debug=true#n10
    • 上記のURIを構成するパーツは以下である。
      • URIスキーム          : http
      • ユーザ情報          : yohei:pass
      • ホスト名                : blog.example.jp
      • ポート番号          : 8000
      • パス                       : /search
      • クエリパラメータ : q=test&debug=true
      • URIフラグメント  : #n10

第5章 URIの設計

  • 重要点まとめ
    • リンク切れなどを起こさない変わらないURIこそが最上のURIである。
    • 変わらないURIにするための設計指針
      • URIにプログラミング言語依存の拡張子を利用しない(.pl、.rb、.do、.jspなど)
      • URIに実装依存のパス名を利用しない(cgi-bin、servletなど)
      • URIにプログラミング言語のメソッド名を利用しない
      • URIにセッションIDを含めない
      • URIはそのリソースを表現する名詞である
    • どうしてもURIを変更したいときはリダイレクトにより、古いURIから新しいURIに転送する仕組みを設け、古いURIにアクセスした際に自動的に新しいURIを取得しにいくよう設計する。

第3部 HTTP 

第6章 HTTPの基本

  • 前提知識
    • TCP/IP(Transmission Control Protocol/Internet Protocol): インターネットで標準的に利用されている通信プロトコル。TCPとIPという2つのプロトコルで構成される。TCPは接続相手を確認してからデータを送受信することで、信頼性の高い通信を実現する。IPは相手を確認せずにデータを送受信することで、高速なデータの転送を実現する。TCP/IPの通信では、IPがネットワークから自分宛のパケットを取り出してTCPに渡し、TCPはパケットに誤りがないか確認してから元のデータに戻す。
    • スケールアウト システムのパフォーマンスを向上させるためにサーバの台数を増やし分散処理によって、システム全体の処理能力を高めるアプローチ。
  • 重要点まとめ
    • HTTPはステートレスなプロトコルとして設計されている。
    • ステートレスにすることで、サーバはリクエストの処理だけに集中でき、スケールすることが容易になる。

第7章 HTTPメソッド

  • 前提知識
    • HTTPメソッドはGET、POST、PUT、DELETE、HEAD、OPTIONS、TRACE、CONNECTの8つに限定されている。
  • 重要点まとめ
    • GETは指定したURIの情報を取得する。Webページの取得、画像の取得、映像の取得など、最も利用頻度が高い。
    • POSTはGETに次いで使用頻度が高い。POSTには3つの役割がある。
      • あるリソースに対する子リソースを作成する。(ブログ内の記事など)
      • 既存リソースへデータを追加する。
      • 他のメソッドでは対応できない処理。
    • PUTはリソース内容の更新と、リソースの作成の2つの役割を持っている。
    • DELETEはリソースを削除する。
    • HEADはリソースのヘッダだけを取得するメソッド。
    • OPTIONSはそのリソースがサーポートしているメソッドの一覧を返す。

第8章 ステータスコード

  • よく使われるステータスコードまとめ
    • 200 OK : リクエストが成功したことを示す。
    • 201 Created : リソースの作成成功を示す。
    • 301 Moved Permanently : リクエストで指定したリソースが新しいURIに移動したことを示す。
    • 303 See Other : リクエストに対する処理結果が別のURIで取得できることを示す。
    • 400 Bad Request : リクエストの構文やパラメータが間違っていることを示す。
    • 401 Unauthorized : 適切な認証情報を与えずにリクエストを行ったことを示す。
    • 404 Not Found : 指定したリソースが見つからないことを示す。
    • 500 Internal Server Error : サーバー側に何らかの異常が生じていて正しいレスポンスが返せないことを示す。
    • 503 Service Unavailable : サーバーがメンテナンスで一時的にアクセスできないことを示す。

第9章 HTTPヘッダ

  • 前提知識
    • HTTPヘッダ : ヘッダはメッセージのボディに対する付加的な情報、いわゆるメタデータを表現する。
    • 例 => Content-Type: Text/Plain; charset=UTF-8(黒字部分がヘッダ)
    • MIMEメディアタイプ : メッセージでやり取りするリソースの表現の種類を指定するのがMIMEメディアタイプである。
    • SSL : インターネット上の通信を暗号化する技術。SSLを導入すると、訪問者のブラウザとサーバー間のデータ通信が暗号化される。
    • ハッシュ関数 : データからそのデータを代表する数値を求める関数を指す。ハッシュ関数を使用して得られた数値のことをハッシュ値という。
    • 例 => 「明日の天気は晴れです」という文章がある。これをハッシュ関数に通すと「d5a4508fdc93cac73a5eb91ab96c020e」というハッシュ値になる。
    • ダイジェスト : メッセージダイジェストの略。あるメッセージに対してハッシュ関数を適用した結果のハッシュ値を指す。
  • よく使われるヘッダまとめ
    • 日時ヘッダ
      • 値に日時をもつヘッダ。DateやExpiresなどが相当する。
      • 例 => Date: Tue
    • Content-Typeヘッダ
      • メッセージのボディの内容がどのような種類なのかをメディアタイプで指定する。
      • 例 => Content-Type: application/xhtml+xml; charset=utf -8(黒字の部分がメディアタイプである)/の左側をタイプ、右側をサブタイプと呼ぶ。
      • メディアタイプはchrsetパラメータを持てる。
      • charset=utf-8などと指定した場合、文書内をutf-8でエンコードしていることを示す。
    • Acceptヘッダ
      • クライアントが自分の処理できるメディアタイプをサーバに伝える場合に使用する
      • 例 => Accept: text/html,application/xhtml+xml
    • Accept-Charsetヘッダ
      • クライアントが自分の処理できる文字エンコーディングをサーバに伝える場合に使用する
      • 例 => Accept-Charset: Shift_JIS
    • Accept-Languageヘッダ
      • クライアントが自分の処理できる言語タグをサーバに伝える場合に利用する
      • 例 => Accept-Language: ja
    • Content-Lengthヘッダ
      • メッセージがボディを持っている場合、Content-Lengthヘッダを利用してサイズをバイトで示す。
      • 例 => Content-Length: 5538
  • 重要点まとめ
    • Basic認証 : ユーザー名とパスワードによる認証方式。ユーザー名とパスワードはauthorizationヘッダに入れてリクエストごとに送信する。ユーザー名とパスワードが平文でネットワーク上を流れるため、SSLなどを使用し、HTTPS通信による暗号化を検討しなければならない。
    • Digest認証 : Basic認証よりも、さらにセキュアな認証方式。クライアントはまず、認証情報なしでリクエストを送信し、サーバーから認証に必要な情報を含んだレスポンスを得る。サーバー認証に必要な情報を得たクライアントは、自分のユーザー名とパスワードを使ってダイジェストを生成し、生成したダイジェストをresponceというフィールドに入れて、リクエストを送信する。Basic認証とは違い、サーバ上にはパスワードそのものではなく、パスワードのハッシュ値を保管しているため、セキュリティリスクを大きく下げ流といったメリットがある。ただし、Digest認証はパスワードを暗号化するだけで、メッセージ自体は平文でネットワーク上を流れるため、メッセージも同様に暗号化する場合は、Basic認証同様、HTTPSの導入を検討する必要がある。

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

第10章 HTML

  • 前提知識
    • HTML(Hypertext Markup Language): タグで文書の構造を表現するマークアップ言語。
    • フォーム : 入力や送信を作成する際に使用する要素。
  • 重要点まとめ
    • ボディに入る要素は、文書の段落や見出しなど、ある程度大きなかたまりを表現するブロック要素、ブロック要素の中に入る強調や改行、画像埋め込みなどを表現するインライン要素の2つに分けられる。
    • HTMLの全ての要素はclassとidを持つことができる。
    • HTMLのフォームではリンク先のURIに対してGETとPOSTを発行できる。
    • フォームによるGETは、キーワード検索などユーザーからの入力によってURIを生成する時に使う。
    • フォームによるPOSTはリソースの作成など、ユーザーの入力をターゲットURIに送信する時に利用する

第11章 microformats

  • 前提知識
    • セマンティックWeb : 人間が読んで理解するWebページの意味を、プログラムからも処理できるように形式的に意味を記述するための技術。
  • 重要点まとめ
    • HTMLは文章構造こそ表すことはできるが、意味までは表現できない。例えば人の名前や住所、電話番号といったものにマークアップを施すことはできないのである。microformatsは、このようなデータの意味づけを可能にする技術。例として、classに英名を代入、href属性にリンクを入れるなど。
    • microformatsはより簡単に、もっと気軽にセマンティックWebを記述できるようにしたもの。
    • 従来のHTML表現は主に人がブラウザで読むために利用しているため、プログラムでの処理が難しいという問題があった。microformatsはこの弱点を補うリソース表現であり、既存のWebページをそのままWeb APIとして提供することを可能にした。
    • 必要最低限のコストでWebサービスをWeb API化できることが、microformatsの最大の特徴である。

第12章 Atom

  • 前提知識
    • Atom(Atom Syndication Format)はRFC4287が規定するXMLフォーマットである。
    • メンバリソース : Atomにおける最小のリソース単位。例えばブログであれば1つ1つの記事がメンバリソースにあたる。メンバリソースはさらに、XMLで表現できるエントリリソースとそれ以外のメディアリソースに分けられる。
    • エントリリソース : ブログに例えるならば、ブログ記事の本文と、それに対応するメタデータ(タイトル、日時、著者など)
    • メディアリソース : 画像や映像などテキストでは表現できないリソース。
    • コレクションリソース : 複数のメンバリソースを含むリソース。コレクションリソースは<feed>要素で表現し、これをフィードという。
  • 重要点まとめ
    • Atomの構成要素はメンバリソースとコレクションリソースに分けられる。
    • AtomはID、タイトル、著者、更新日時といった基本的なメタデータを備えたリソース表現のためのフォーマットであり、多様なアプリケーション用の拡張が用意されているため、ブログ以外の用途にも用いられる。
    • そのため、ブログだけでなく、検索エンジンや写真管理など、AtomはさまざまなWebサービスでWeb APIとして利用できる。

第13章 Atom Publishing Protocol

  • 重要点まとめ
    • AtomPub(Atom Publishing Protocol):  Atomが規定したフィードやエントリで表現するリソースのCRUD操作を実現できる。
    • AtomPibはRESTスタイルに基づいたプロトコル仕様。
    • AtomPubはWebAPIのためのプロトコルだが、万能ではない。以下にAtomPubに向いているAPIと向いていないAPIをまとめる。
    • AtomPubに向いているWeb API
      • ブログサービスのAPI
      • 検索機能を持つデータベースのAPI
      • マルチメディアファイルのリポジトリのAPI
      • タグを使ったソーシャルサービスのAPI
    • AtomPubに向いていないWeb API
      • 映像のストリーム配信など、HTTP以外のプロトコルを必要とするAPI
      • データの階層構造が重要なAPI
      • 「タイトル」、「作者」、「更新日時」など、Atomフォーマットが用意するメタデータが不要なAPI
    • Web APIを開発するときは、Webサービスの特性に合わせてベースとなるプロトコルやデータフォーマットを選ぶ必要がある。

第14章 JSON

  • 前提知識
    • JSON(Javascript Object Notation): RFC4627が規定するデータ記述言語。Javascriptの記法で、データを記述できる。
  • 重要点まとめ
    • JSONはより軽量なデータ表現形式であり、XMLのように文書をマークアップすることには向いていないが、ハッシュや配列といったプログラミング言語から扱いやすいデータ構造を記述できることが特徴。

まとめ

 

今回、「Webを支える技術」を読了したことで、今まで曖昧になっていたWebに関する細かい知識を深めることができたと思います。現場で活躍するエンジニアの方々にとって、読んで損はない一冊だと感じました。

また、今回自分が読み終えている技術書の中の1冊をブログ記事として落とし込むことで、アウトプットによる深い知識の定着を感じることができました。

ただ読み終えて終わる。ただ技術書に書かれているソースコードを叩いて終わるだけでなく、こうしたブログ記事への落とし込みや、ソースコードを工夫しながら自ら思考してコーディングしていくアウトプットが手元に技術を定着させてくれるのではないのかなと感じられました。

 

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

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

 

 

続けていこうと思います。

次回は「パーフェクトRuby on Rails」、「プログラマの数学」を読み進めていこうと思います。