🙌

新米エンジニアが「webを支える技術」をまとめてみた

2021/01/03に公開

はじめに

今の会社に入ってもうすぐ一年になるので、会社で勧められたて読んだ"webを支える技術"を自分が分かりやすいようにまとめてみようと思う

このまとめで分かること

webの基本
REST
URI
HTTP
ハイパーメディアフォーマット

Webとは

Webとは同じネットワーク上に置かれた文章や画像、音楽や映像などの情報に住所を与え、それらをリンクで繋いで情報の発信、閲覧ができる仕組みのこと。正式名称は「World Wide Web(ワールド ワイド ウェブ)」。

インターネットとWebは違う?

インターネットとWebは現代では一緒に使われることが多いからわかりに厳密
Webは同じネットワーク上にある情報のやりとりをする仕組みのため、外部のネットワーク上にいるコンピュータには情報を伝達することが出来ない。
インターネットによって世界中のコンピュータをネットワークに乗っけることでインターネット上でWebを最大限活用することができる。

インターネット:世界中に張り巡らされたネットワークの海
Web:インターネットの海に浮かぶ、島や街や建物・情報。そしてそれをつなぐ橋

Webの様々な用途

  • Webサイト
    • Yahoo!のようなポータルサイトからAmazonのようなショッピングサイト、Googleに代表される検索サイト
  • UIとしてのWeb
    • 各種デバイスの設定画面です。ルータやテレビ、ハードディスクレコーダ、プリンタなど、ネットワークに接続するデバイスの設定をブラウザで行う場合など
  • プログラムAPIとしてのWeb
    • XMLやJSONなどを使ったプログラム用インターフェースとしてのWeb。

Webを支える技術

  • URI(UniformResourceIdentifier)
    • Web資源を一意に表す識別子。URI(宛先)=URL(web上の住所)+URN(web上の名前)
  • HTML(HyperText Markup Language)
    • Web情報を表示するための文書フォーマット。
  • HTTP(HypertextTransferProtocol)
    • Webで扱うリソースをコントロールする仕組み。HTTPがURIで操作する対象を指定し、HTMLやJsonなどのデータのやりとりを行う

ハイパーメディアと分散システム

Webシステムで重要な役割を担っているのがハイパーメディアと分散システム。

ハイパーメディアとは、テキストや画像、音声、映像などさまざまなメディアをハイパーリンク(HyperLink)で結び付けて構成したシステムの事。Webはハイパーメディアの一種。

分散システムとは、複数のコンピュータを組み合わせて処理を分散させる形式の事。Webは、世界中に配置されたサーバに世界中のブラウザがアクセスする分散システム。Webはとてもシンプルなプロトコルなためインターネットを使った巨大なシステムを扱うことができる。

Webで使われるアーキテクチャスタイル

アーキテクチャスタイルとは、システムを構築する際の設計思想の事。
代表的なものはRESTとSOAPがあるが、2002年にAmazonがRESTを元に作成したWeb APIをきっかけに現在ではRESTが主流となっている。

アーキテクチャスタイルとアーキテクチャと実装の関係

実装から一つ抽象度をあげたのがアーキテクチャで、アーキテクチャから抽象度を1つ上げたのがアーキテクチャスタイル(表3.1)。ただし、現実にはRESTと言えばWebのアーキテクチャスタイルを指す場合が多いので、以降ではRESTの実装例としてWebを用いる。

REST

RESTは数あるアーキテクチャスタイルの中でも、特にネットワークシステムのアーキテクチャスタイル。ネットワークシステムのアーキテクチャスタイルとして最も有名なのはクライアント/サーバ(ClientServer)があり、RESTはクライアント/サーバを元にいくつかの制約を組み合わせて生まれた複合アーキテクチャスタイル。以下がRESTを構成するアーキテクチャスタイルとなる。

1.クライアント/サーバ
2.ステートレスサーバ
3.キャッシュ
4.統一インターフェース
5.階層化システム
6.コードオンデマンド

1.クライアント/サーバ

Webは、HTTPというプロトコルでクライアントとサーバが通信するクライアント/サーバのアーキテクチャスタイルを採用している。すなわち、クライアントはサーバにリクエストを送り、サーバはそれに対してレスポンスを返す。これにより複数のコンピュータで分散して処理を行うことができる。

2.ステートレスサーバ

クライアント/サーバに最初に追加するアーキテクチャスタイルはステートレスサーバ。ステートレスとは、クライアントのアプリケーション状態をサーバで管理しないこと。サーバ側での管理を減らすことで大量のクライアントとの並行処理を可能にする。

3.キャッシュ

キャッシュとは、リソースの鮮度に基づいて、一度取得したリソースをクライアント側で使いまわす方式。キャッシュの利点は、サーバとクライアントの間の通信を減らすことでネットワーク帯域の利用や処理時間を縮小し、より効率的に処理できること。

4.統一インターフェース

URIで指し示したリソースに対する操作を、統一した限定的なインタフェースで行うアーキテクチャスタイルのこと。たとえばHTTP1.1ではGETやPOSTなど8個のメソッドだけが定義されている。統一インタフェースはRESTを最も特徴づけるアーキテクチャスタイル。

5.階層化システム

統一インターフェースを用いてシステム全体を断層化する。
サーバやプロキシなどの各コンポーネント間のインタフェースをHTTPで統一することでシステム同士の接続を容易にできる。

6.コードオンデマンド

コードオンデマンドは、プログラムコードをサーバからダウンロードし、クライアント側でそれを実行するアーキテクチャスタイル。たとえばJavaScriptやFlash、Javaアプレットなどがこれに該当する。

URI

URIとは「リソースを統一的に識別するID」のこと。URIを使うとWeb上に存在するすべてのリソースを一意に示す事ができる。

URIの構文

最もシンプルなURIの例

(http://blog.example.jp/entries/1)

構成パーツ

  • URIスキーム:http
  • ホスト名:blog.example.jp
  • パス:/entries/1

URIはURIスキーム(URIScheme)で始まります。URIスキームは、そのURIが利用するプロトコルを示すのが一般的。この場合はHTTPを使ってリソースにアクセスする。
次に表示されているホスト名はDNS(DomainNameSystem)で名前が解決できるドメイン名かIPアドレスで、インターネット上で必ず一意になる。
ホスト名のあとには階層を表すパスが続き、そのホストの中で一意のリソースを指し示す。

URIで使用できる文字

  • アルファベット:AZaz
  • 数字:0~9
  • 記号:.~:@!$&'()

使える文字列はASCII文字に限られ、日本語などのASCII以外の文字をURIに入れるときは、%エンコーディングで変換される。

URIの設計

Cool URI

「URIは変わらないべきである。変わらないURIこそが最上のURIである」by TimBernersLee
変わらないURIを作るためには以下の点に注意する。

  • URIにプログラミング言語依存の拡張子を利用しない(.pl、.rb、.do、.jspなど)
  • URIに実装依存のパス名を利用しない(cgibin、servletなど)
  • URIにプログラミング言語のメソッド名を利用しない
  • URIにセッションIDを含めない
  • URIはそのリソースを表現する名詞である

HTTP

HTTPはTCP/IPをベースとしたプロトコル。

TCP/IP

TCP/IPとはインターネットの基盤を構成する重要なネットワークプロトコル。
TCP/IPの通信は、上位のレイヤーから以下4つの階層に分かれている。

TCP/IPの機能階層 主なプロトコル
アプリケーション層 HTTP,DNS,SMTP,FTP
トランスポート層 TCP
インターネット層 IP
ネットワークインターフェイス層 Ethernet

各レイヤーの役割

ネットワークインターフェース層
一番下。物理的なケーブルやネットワークアダプタに相当する部分。

インターネット層
ネットワークでデータを実際にやり取りする部分。TCP/IPでIPが相当。 IPはデータの基本的な通信単位 「パケット」 と呼ばれる。 IPはデータを送り出すことだけを保証。それが届くかどうかは保証しない。

トランスポート層
IPが保証しなかったデータの転送を保証。TCP/IPでTCPが相当。TCPは接続先の相手に対してコネクションを張る。データの抜け漏れをチェックし、データの到達保証。 転送するデータがどのアプリケーションに渡るかを決定するのが ポート番号(1~65535の数値)。

アプリケーション層
具体的なインターネットアプリケーション。
例:メールやDNS、HTTPを実現する層。 TCPでプログラムを作るときは ソケット(Socket) と呼ばれるライブラリを使うことが一般的。 ソケットはネットワークでのデータのやり取りを象徴化したAPI[接続、送信、受信、切断など]

クライアントとサーバ

Webはアーキテクチャスタイルにクライアント/サーバを採用している。すなわち、クライアント(Webブラウザ)が情報を提供するサーバ(Webサーバ)に接続し、各種のリクエスト(Request、要求)を出してレスポンス(Response、返答)を受け取る。

リクエストとリスポンス

HTTPではクライアントが出したリクエストをサーバで処理してレスポンスを返す。このようなプロトコルのことをリクエスト/レスポンス型プロトコルと呼ぶ。

クライアントで行われること

1.リクエストメッセージの構築
2.リクエストメッセージの送信
3.(レスポンスが返るまで待機)
4.レスポンスメッセージの受信
5.レスポンスメッセージの解析
6.クライアントの目的を達成するために必要な処理

サーバで行われること

1.(リクエストの待機)
2.リクエストメッセージの受信
3.リクエストメッセージの解析
4.適切なアプリケーションプログラムへの処理の委譲
5.アプリケーションプログラムから結果を取得
6.レスポンスメッセージの構築
7.レスポンスメッセージの送信

HTTPメッセージ

リクエストメッセージとレスポンスメッセージをまとめて「HTTPメッセージ」と呼ぶ。

リクエストメッセージ

例.
GET /test HTTP/1.1
Host:example.jp

  • リクエストライン:1行目。メソッド(GET)、リクエストURI(/test)、プロトコルバージョン(HTTP/1.1)
  • ヘッダ:2行目。メッセージのメタデータ。例では名前「Host」に値「example.jp」が結び付けられている。
  • ボディ:3行目以降。例ではボディはないが、メッセージを表す本質的な情報が入る部分。たとえばリソースを新しく作成したり更新したりするときは、リクエストのボディにリソースの表現そのものが入る。

レスポンスメッセージ

例.
HTTP/1.1 200 OK
ContentType:application/xhtml+xml;charset=utf8 <htmlxmlns="http://www.w3.org/1999/xhtml">
...
</html>

  • ステータスライン:1行目。プロトコルバージョン(HTTP/1.1)、ステータスコード(200)、テキストフレーズ(OK)から成る。
  • ヘッダ:2行目以降。リクエストメッセージと同様にヘッダ。この例では、ContentTypeヘッダでHTMLのMIME、メディアタイプ(application/xhtml+xml)、文字エンコーディング方式(utf8)を指定している。
  • ボディ:この例ではボディにHTMLが含まれている。

HTTPメソッド

HTTPメソッドは、クライアントが行いたい処理をサーバに伝える役割を果たす。HTTP1.1は表7.1に示す合計8つのメソッドを定義している。その中で主に使うメソッドは5つか6つ。

ステータスコード

HTTPはリクエスト/レスポンスで成り立っていて、ステータスコードはクライアントの挙動を左右する重要な役割を担っている。WebサービスやWebAPIを設計するにあたって、ステータスコードをどのように選択するかは重要となる。

ステータスコードの種類

  • 1xx:処理中
  • 2xx:成功
  • 3xx:リダイレクト
  • 4xx:クライアントエラー
  • 5xx:サーバエラー

HTTPヘッダ

ヘッダは、メッセージのボディに対する付加的な情報、いわゆるメタデータを表現する。クライアントやサーバはヘッダを見てメッセージに対する挙動を決定。メディアタイプや言語タグなど、フレームワークではなく実装者が具体的に設定しなければならないヘッダも多い。また、リソースへのアクセス権を設定する認証や、クライアントとサーバの通信回数と量を減らすキャッシュなどのHTTPの機能はヘッダで実現する。主でヘッダで扱われる情報には以下のものがある

  • 日時:DateやExpiresで表す
  • メディアタイプ:Content-Typeで示される。タイプとサブタイプがあり"/"で区切られる。
  • charsetパラメータ:文字エンコーディングを指定
  • 言語タグ:リソース表現の自然言語を指定
  • 認証:Basic認証とDigest認証などの認証方式を指定
  • キャッシュ:Pragma、Expires、CacheControlヘッダにより指定

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

WebサービスやWeb APIを設計するときに利用できる主要なハイパーメディアフォーマット。

  • HTML
  • microformats
  • Atom
  • Atom Publishing Protocol
  • Json

Discussion