Zenn
🚽

忙しい人のための「Webを支える技術」

2023/08/05に公開
JavaScript
Web
http
#
rest
REST API
tech

山本 陽介さん著の「Webを支える技術」を忙しいエンジニア向けにまとめました。
ですがこの記事を読むより、以下のリンクの原本を読むことを強く推奨します。
https://www.amazon.co.jp/Webを支える技術-HTTP，URI，HTML，そしてREST-WEB-PRESS-plus-ebook/dp/B07JK7FZH2
※アフィリエイトリンクではありません。

第1部 Web概論

第1章 Webとは何か

Webを支える基本的な技術はHTTP、URI、HTMLの3つである。

Webはハイパーメディアシステムと分散システムの側面を持つ。

※ハイパーメディアシステム ~ 様々な情報をリンクによって結び付けて構成するシステム

※分散システム ~ 複数のコンピュータに処理が冗長化されたシステム

第1部のテーマはWebの技術的なバックグラウンドとアーキテクチャ。

第2章 Webの歴史

1990年にTim Berners-Leeがハイパーメディアを用いたインターネットベースの分散情報管理システムとしてのWebを提案書に書いたことがはじまり。

Webの普及を一気に推し進めたのはNCSAが公開したブラウザ「Mosaic」。

ハイパーメディアの側面ではシンプルな単方向リンクが、分散システムの側面ではブラウザからHTTPというシンプルなプロトコルでアクセスできる点がここまで普及した1つの理由。

Roy Fieldingが博士論文で、Webのアーキテクチャスタイルを 「REST（Representational State Transfer）」 と命名した。

これはHTTPは「リソースの状態（Resource State）」の「 表現（Representation） 」を運んでいるという主張から名づけられた。

SOAPとRESTのWebの標準争い → これに勝ち多くのソフトウェアはWebを前提に。

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

RESTは Webのアーキテクチャスタイル。アーキテクチャスタイルはアーキテクチャ設計の指針であり流儀。アーキテクチャよりも抽象度が1つ上。

具体的にWebはネットワークシステムのアーキテクチャスタイルで、クライアント/サーバのアーキテクチャを持つ。

つまり、クライアント/サーバでもありRESTでもある。<u>素のクライアント/サーバにいくつかの制約を加えたのがREST。</u>

  • アーキテクチャスタイル
    REST
  • アーキテクチャ
    ブラウザ、サーバ、プロキシ、HTTP、URI、HTML
  • 実装
    Apache、Firefox、Tomcat

RESTアーキテクチャスタイルの構成

  • クライアント/サーバ ~ クライアントとサーバで処理を分離
  • ステートレスサーバ ~ クライアントのアプリ状態をサーバで管理しない（Cookieはグレー）
  • キャッシュ ~ クライアントで過去に使用したリソースを使いまわす
  • 統一インターフェース ~ HTTP
  • 階層化システム ~ ロードバランサでの負荷分散やプロキシでのアクセス制限など階層的に扱える
  • コードオンデマンド ~ コードをサーバからダウンロードしてクライアントで実行

私たちが作るWebサービスやWeb APIがRESTfullになると、Webは全体としてより良くなる。 → RESTfullな設計を心がけよう。

​
第2部 URI

第4章 URIの仕様

URIはUniform Resource Identifierの略。つまり「リソースを統一的に認識するＩＤ」

URIはASCII文字に対応しているため、日本語などはエンコードされて表示される。

第5章 URIの設計

「Cool URIs Don`t change」（クールなURIは変わらない）

クールなURLにするために..

  • プログラミング言語に依存した拡張子やパスを含めない
  • メソッド名やセッションIDを含めない
  • URIはリソースを表現する名刺にする

URIを変更するくらいならリダイレクトするほうがクール。

第3部 HTTP

第6章 HTTPの基本

HTTPはTCP/IPをベースとしたプロトコルで、最新バージョンは1.1である。

HTTPの名前こそハイパーテキストの転送用プロトコルだが、実際にはHTMLやXML、静止画や動画、JSプログラムなどPCで扱えるデータは大体転送できる。

RESTの特徴のうち、統一インターフェース、ステートレスサーバ、キャッシュを実現している。

TCP/IPとはインターネットで標準的に利用されている通信プロトコルのセット。TCPは信頼性の高いデータ転送を提供し、IPはデータのルーティングとアドレッシングを担っている。

※プロトコルとは通信の各側面に関連する動作やフォーマットを定義し、通信の参加者が互いにデータを理解し、交換するための共通の基盤を提供するもの。

TCP/IPの階層ごとのプロトコルは以下。

  • アプリケーションン層
    HTTP、NTP、SSH、DNS
  • トランスポート層
    UDP、TCP
  • インターネット層
    IP
  • ネットワークインターフェース層
    イーサネット

Webはクライアント（ブラウザ）からのリクエストをサーバ（Webサーバ）が受け取り、解析してレスポンスを返す。レスポンスをもとに目的を達成するための処理を行う。というクライアント/サーバのアーキテクチャスタイル。

HTTPリスエスト・レスポンスにはフォーマットがある。
HTTPはステートレスなプロトコルなので、サーバがクライアントのアプリケーション状態を保存しない。 → リクエストの処理に必要な情報をすべて含めてリクエストメッセージを送る。

ステートレスなアーキテクチャはスケーラビリティの面で大きな威力を発揮する。

第7章 HTTPメソッド

HTTPメソッドは8個しかない。内訳は以下。

  1. GET ~ リソースの取得
  2. POST ~ 子リソースの取得、リソースへのデータの追加、その他の処理
  3. PUT ~ リソースの更新、リソースの作成
  4. DELETE ~ リソースの削除
  5. HEAD ~ リソースのヘッダの取得
  6. OPTIONS ~ リソースがサポートしているメソッドの取得
  7. （TRACE ~ 自分宛にリクエストメッセージを返す試験（ループバック））
  8. （CONNECT ~ プロキシ動作のトンネル接続への変更）

    ※ほとんどGETとPOSTが使用される。POSTは万能メソッド。

CRUDでいうと<u>Create（POST/PUT）Read（GET）Update（PUT）Delete（DELETE）</u>となる。

ちなみにGETメソッドの実行例は以下。

リクエスト

GET /test HTTP/1.1
Host: example.jp

レスポンス

HTTP/1.1 200 OK
Content-Type: application/xml; charset=uft-8

<test>test1<test>

HTTPメソッドにおけるぺき等性と安全性とは以下の内容を指す。この2つは通信エラー時にリクエストをどう回復するかにおいて重要みたい。

  • べき等性 ~ 何度実行しても結果が同じであるかという特性
  • 安全性 ~ サーバ上のリソースの状態を変化させないという特性

    ※GETはべき等かつ安全だが、POSTはべき等でも安全でもない。

第8章 ステータスコード

レスポンスメッセージの１行目にあるステータスラインはプロトコルバージョン、ステータスコード、テキストフレーズから成る。以下の例では200がステータスコード。

HTTP/1.1 200 OK
Content-Type: application/xhtml+xml: charset=uft-8

<html xmlns="http://www.w3.org/1999/xhtml>...</html>

ステータスコードの分類と意味は以下。

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

第9章 HTTPヘッダ

HTTPヘッダはメッセージのボディに対する付加的な情報を表現する。<u>リソースへのアクセス認証やキャッシュの機能はヘッダで実現する。</u>

リクエストヘッダやレスポンスヘッダなどの種類がある。

代表的なHTTPヘッダは以下。

  • 日時 ~ Dateヘッダはメッセージを生成した日時を記載する
  • MIMEメディアタイプ ~ Content-Typeヘッダはxmlなどのメディアタイプを指定する。charsetヘッダはuft-8などの文字コーディングを指定する。
  • 言語タグ ~ Content-Languageヘッダはリソースの言語を指定する。
  • コンテントネゴシエーション ~ クライアントが処理できるメディアタイプ（Acceptヘッダ）、文字エンコーディング（Accept-Charsetヘッダ）、言語（Accept-Language）をサーバに伝えるヘッダ。
  • Content-Lengthとチャンク転送 ~ Content-Lengthヘッダはメッセージボディの長さを指定する。Transfer-Encodingヘッダはボディを分割して転送できるようにする。
  • 認証 ~ Basic認証とDigest認証のいずれもAuthorizationヘッダにID・PASSを暗号化（Basic認証は平文）してリクエストを送信する。
  • キャッシュ ~ Pragmaヘッダでキャッシュ可能なリソースか指定して、Expiresヘッダでキャッシュの有効期限を示す。この2つはCache-Controlヘッダで代用可能。
  • 条件付きGET ~ If-Modified-Sinceヘッダでリソースの更新日時を条件にするか、If-None-MatchヘッダでリソースのETagを条件にすることで条件付きGETは実装される。
  • 持続的接続 ~ ConnectionヘッダでTCPのコネクションを継続利用するか設定できる。

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

第10章 HTML

ハイパーメディアフォーマットとしてのHTMLに主眼を置く。

HTML ⇒ Hypertext Markup Language。拡張子は基本的に.htmlである。

HTMLのメディアタイプはSGMLベースのHTMLを指す「text/html」と、XMLベースのXHTMLを指す「application/xhtml+xml」の２つがある。

HTMLの構成要素はヘッダとボディで、ブロックレベル要素で段落などを表現し、インライン要素で強調や改行などを表現する。また共通の属性としてid属性とclass属性を有する。

ハイパーメディアフォーマットとしてのHTMLの特徴は以下。

  • < a > ~ 最も基本的なリンクの記法。アンカータグという。
詳細な情報は<a href="http://hoge.jp">ホゲのWebページ</a>を参照してください。
  • < link > ~ HTMLのヘッダでWebページ同士の関係を指定するために使う。<u>CSSへのリンクなど。</u>
<head>
	<link rel="index" href="http://hoge.jp/index.html"/>
	<link rel="prev" href=http://hoge.jp/1.html"/>
	<link rel="next" href=http://hoge.jp/3.html"/>
</head>
  • < img > ・ < object > ~ オブジェクトの埋め込み。ハイパーメディアなので画像・映像も埋め込める。画像の埋め込みはimgタグを、その他のオブジェクトの埋め込みにはobjectタグを利用する。
<img src="http://test.jp/hoge.png" alt="ホゲ"/>
<object date="http://hoge.jp/hoge.mpeg">ホゲ</object>

他にもフォーム（< form >）ならGETだけでなく、POSTも発行できる。

またリンクの関係を表すものとして、rel属性やmicroformatsなどもある。

HTMLで実現できる機能はシンプルなハイパーメディアのみだが、その効果は絶大。ハイパーメディアによるリンクとHTTP、URIの組み合わせで初めてWebが成り立つ。

第11章 microformats

ずいぶん昔から、RDF（Resouce Description Framework）をベースとしたセマンティックなWebがWeb上の情報に意味を与え、検索エンジンやエージェントといったプログラムが利用するようになると言われてきた。

そんなセマンティックなWebを地に足のついた方向に導くのがmicroformatsみたい。

（ChatGPT）マイクロフォーマットは、現存するHTMLのフレームワークの中で、ウェブ上の情報に意味を与えるための簡単で実用的な方法を提供します。これは、セマンティックウェブの理念と一致しています。
セマンティックウェブは、ウェブ上の情報に明確な意味を付け加えて、機械がそれを理解し処理できるようにするためのコンセプトで、その実現の一環として、RDF(Resource Description Framework)が考案されました。しかし、RDFは抽象度が高く、その導入にはかなりの労力が必要なため、一般のウェブ開発者にはなかなか受け入れられませんでした。
一方で、マイクロフォーマットは既存のHTMLに簡単に追加できるため、手軽にセマンティックウェブを実現するための道具として使われてきました。HTML要素に特定のクラス名を追加するだけで、その要素が表す情報に意味を付け加えることができます。このように、マイクロフォーマットはセマンティックウェブの理念をより現実的かつ実用的なものにする役割を果たしています。
ただし、マイクロフォーマットはあくまで一つの手段であり、ウェブ全体がセマンティックウェブに移行するためには、さまざまなアプローチが必要です。これには、マイクロデータやJSON-LDなどの他の技術も含まれます。

コンピュータの分野では、プログラミング言語が持つ意味を確定されるための理論のことを プログラム意味論 と呼ぶ。プログラミング言語が何を表すのか（すなわち 意味 ）を正確に理解し、記述するための理論と手法について研究することを指す。

Webにおける意味論は リソースが持つ意味を確定させる ための理論。⇒ HTMLなどのテキストがどのような意味をもつのかプログラムでも解釈できるようにすることがゴール。

⇒ セマンティックWeb

RDF（Resource Description Framework）は情報をWeb上で共有し、再利用するためのフレームワーク。トリプル（主語・述語・目的語）で情報を表現する ⇒ <u>記述が複雑・統一的に記述しずらい</u>などでほとんど普及せず。

RDFの問題点を解決し、HTMLそのものにメタデータを埋め込む形の技術が microformats 。

microformatsはHTMLタグのclass属性に付けることで、そのタグに書かれた意味を確定させる。 ⇒ プログラムにも解釈可能。

microformatsは<u>elemental microformatsとcompound microformats</u>に分類することができる。

  • elemental microformats ⇒ リンク関係で目だデータを表現するフォーマット
    • rel-license（ライセンス情報）
  • compound microformats ⇒ class属性で階層構造のあるメタデータを表現するフォーマット
    • hCalendar（イベント情報）

microformatsの問題点と解決するために標準化が進んでいるのが、RDFa（RDF-in-attributes）みたい。
microformatsは必要最低限のコストでWebサービスをWeb API化できる。 → XMLやJSONを使用しなくてもよい。

第12章 Atom

Atomとはブログ投稿やニュース記事など、Web上の更新情報を提供するためのXMLフォーマットで、Webフィードのひとつ。

※フィードとは新しい情報を迅速に提供すること。

Atom = Atom Syndication Format。RSSの仕様が乱立したので標準フォーマットとして策定しようとした。WebサービスのWeb APIとして利用できる。

Atomの論理構成はメンバリソース（エントリリソース・メディアリソース）、コレクションリソースに大別できる。

Atomはタイトル・著者・更新日時などの基本的なメタデータを備えたリソース表現のためのフォーマット。

第13章 Atom Publishing Protocol

ここの章はスキップ。

第14章 JSON

JSONはJavaScript Object Notationの略。プログラミング言語間でもデータを受け渡せる。またWebサービスはブラウザでJavaScriptが実行できるので相性がいい。

JSONのメディアタイプは application/json である。拡張子は .json 。

※メディアタイプはファイルの内容を表す２部構成の識別子。Type（text, image, applicationなど）とSubtype（plain, html, jsonなど）で構成される。⇚ <u>メディアタイプをレスポンスの Content-Type ヘッダに指定することでブラウザが適した処理を行う。</u>

JSONで用意しているデータ型は以下の6つ。

  • オブジェクト
  • 配列
  • 文字列
  • 数値
  • ブーリアン（真偽値）
  • null

※日時もリンクも専用の型がないので文字列で対応。

JSONでリソース表現を提供するとJSONP（JSON with Padding）を利用出来ることがある。

JSONPはブラウザでクロスドメイン通信を実現する手段 ⇚ クロスドメイン通信とはブラウザが異なるドメインからリソースをリクエストするプロセスのこと。悪意のあるサイトが他のサイトのリソースにアクセスすることを防ぐ。

※ちなみにドメインは www.google.com とか。

JSONはデータ記述に適したフォーマットだが、ハイパーメディアフォーマットとして扱うにはリンクを表現するメンバを入れる必要がある。

第5部 Webサービスの設計

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

第16章 書き込み可能なWebサービスの設計

第17章 リソースの設計

Discussion