たつのおとしごのしっぽ

技術に楽しくしがみつく えんじにあ の備忘録

Webを支える技術 -HTTP、URI、HTML、そしてREST読んだのでまとめてみた

技術書感想 Web開発

Webを支える技術 -HTTP、URI、HTML、そしてREST を初めて読んだので、まとめや感想などを書きます。

Webの用途

  • Webサイト
  • UIとしてのWeb
    例えばデバイスの設定画面やHTMLによるヘルプなユーザー用IFとしての使い方。
  • APIとしてのWeb
    例えばブログサービスなどプログラム用IFとして使い方。

HTTP

情報を取得したり発注したりするプロトコル。
HTTP 1.1だとメソッドは8つになり、かなりシンプル。

HTML

情報を表現する文書フォーマット。
Webは、ハイパーメディアシステムと分散システムの2つの側面がある。

ハイパーメディア

メディアをハイパーリンクで結びつけて構成したシステム。
非線形的にユーザーがリンクを選択して情報を取得する。
ハイパーリンクとは、情報同士を結びつける機構。

分散システム

複数のPCを組み合わせて処理を分散させる形式。
Webは、世界中のサーバーに世界中のブラウザがアクセスするため、分散システムといえる。

REST

ネットワークシステムのアーキテクチャスタイル。
ネットワークシステムのアーキテクチャスタイルであるクライアント/サーバから派生したアーキテクチャスタイル。
ただし、RESTはWebのアーキテクチャスタイルを指す場合が多い。

リソース

Web上にある名前をもった情報のこと。
リソースの名前はURIのこと。

アーキテクチャスタイル

(1)クライアント/サーバー
プロトコルHTTPでクライアントとサーバーが通信する。
メリット:
クライアントとサーバーの処理が分離される。
クライアントをマルチプラットフォームに出来る。

(2)ステートレスサーバー
サーバーがクライアントのアプリケーション状態を管理せず、通信の度に全情報を送る。
メリット:
サーバーの実装が簡単になる。

(3)キャッシュ
一度取得したリソースをクライアントが使いまわせるようにする。
メリット:
クライアント、サーバー間の通信を減らせる。

(4)統一インターフェース
リソースに対する操作を統一されたインターフェイスで行う。
HTTPのインターフェイスは、HTTPメソッドGET、POST、PUT、DELETEを利用する。
メリット:
クライアントとサーバーの独立性が増す。
クライアント/サーバーを実現するために必要な制約。

(5)階層化システム
統一インターフェイスが実現されていれば、システムが階層になっていても接続先を変える必要がない。
メリット:
HTTPが実現されていないようなシステムでも、Webアプリケーションサーバーを挟めばHTTPインターフェイスを介してクライアント接続できる。

(6)コードオンデマンド
プログラミングをクライアントにダウンロードして実行する。
メリット:
クライアントを後から拡張できる。

上記の制約はいくつか除外しても構わない。
ほとんどの制約が外れるならば、P2Pなど他のアーキテクチャスタイルを検討するべき。

また、アドレス可能性(URIによって情報が表現できている)や接続性(リソースをリンクで接続する)もRESTの思想の一つ。
詳しくは、
RESTful APIとは何なのか
プラットフォームとしてのWeb 2.0とRESTの関係 | 日経クロステック（xTECH）

URI

URIは、情報を指し示す識別子。

URIとURLとURN

URNは、リソースを識別する恒久的な名前を示す。
リソースに恒久的なIDをふるための仕様が検討された。

URLは、リソースの場所を示す。最近はURLで十分永続的になっている。

URI = URL + URNなイメージ。
サイトのアドレスは、URLでありURIである。
詳しくは、 URL と URI の違い - Qiita

URIの設計

大きく分けると以下の点に注意するべきである。

HTTP

同期型プロトコル。
クライアントがリクエストを出したらレスポンスが返るまで待つ。

ステートフルとステートレス

ステートフルだと、セッション状態をサーバーで管理しなければいけないためクライアント数が増えたときにスケールアウトさせにくい。

ステートレスは、サーバー側のシステムが単純になる。しかし、データ量が多くなったり、認証などサーバーに負荷のかかる処理を繰り返すなどパフォーマンスは低下する。
ネットワークトラブルが起きたときに、そのリクエストが正しく処理されたかが知れない。

HTTPメッセージ

リクエストメッセージ

GET /background.png HTTP/1.0

リクエストライン: リクエストメッセージの一行目。メソッド、リクエストURI、プロトコルバージョンから構成される

リクエストヘッダーは下記の画像が参考になります。
https://mdn.mozillademos.org/files/13821/HTTP_Request_Headers2.png HTTP メッセージ - HTTP | MDN

レスポンスメッセージ

HTTP/1.1 404 Not Found.

リクエストライン: リクエストメッセージの一行目。プロトコルバージョン、ステータスコード、テキストフレーズから構成される

レスポンスヘッダーは下記の画像が参考になります。
https://mdn.mozillademos.org/files/13823/HTTP_Response_Headers2.png

HTTP メッセージ - HTTP | MDN

POSTとPUTの使い分け

POST
リソースを作成する時、クライアントがリソースのURIを指定できない。サーバー側で決定する。
URIを自動で決定して良い場合はPOSTが一般的。

PUT
リソースを作成する時、クライアントがリソースのURIを指定できる。
ただし、リソースの上書きを避けるためクライアント側でURIが存在するかチェックする必要がある。
また、クライアントがURIの制約を知る必要があるためサーバーと密な関係になる。 特別な理由がなければリソース作成はPOSTが一般的。

べき等性と安全性

べき等性: ある操作を何度行っても結果が同じ
安全性: 操作対象のリソース状態を変化させない

PUT、DELETE
べき等だが安全でない。
PUTとDELETEは何度行っても同じ結果が返る。
同じ内容であればリソースを何度更新しても何度削除しても同じ結果である。
よって、クライアントが重複を恐れず何度も送信できる。

POST
べき等でも安全でもない。
POSTを複数回送るときは慎重になる必要がある。
メソッドの誤用に注意。
それぞれのべき等性や安全性を守ること。
万能なPOSTで他のメソッドを実現しないこと。

HTTP認証

リソースにアクセス制限がかかっている場合、ステータスコード401 Unauthorizedが返ってWWW-Authenticateヘッダーにリソースへのアクセスに必要な認証情報を通知する。

WWW-Authenticateヘッダー

WWW-Authenticate: <type> realm=<realm>

type : 認証の種類。Basic認証など。
realm: リソースが属しているURI空間の名前。
ヘッダーの値をチャレンジと呼ぶ。
HTTP 認証 - HTTP | MDN

Basic認証

Base64 を使用してエンコードされたユーザー ID とパスワードのペアによる認証方法。
Basic64は簡単にデコードが可能。利用するときはBasic 認証と組み合わせて HTTPS/TLS を使用する必要があります。
TLS : インターネット上のデータ通信を暗号化するプロトコル。SSLはTLSの後継。
HTTPS: SSL/TLSを使って通信をする。

キャッシュ

サーバーから取得したリソースをローカルストレージに蓄積して再利用する。
ヘッダーからキャッシュしても良いかどうか、有効期限はどれくらいかなど指定される。

microformats

HTMLの中でさらに意味のあるデータ、ライセンス情報などを表現するための技術。
プログラムで処理可能な情報の意味を記述する仕様RDFの問題点（記述が複雑、統一した記述がしにくい、RDFが対象とは独立したメタデータになる）を解消した技術でもある。
microformatsの問題点を解決するRDFaという技術もある。
詳しくは、
Big Sky :: 今さら聞くのは恥ずかしい「microformatsとは何か？」
microformats の利点と欠点 – カラクリ.jp

Atom

Atomは、XMLフォーマット、データフォーマットの規定。様々なWebサービスのWebAPIとして利用できる。
AtomPubは、Atomを利用したリソース編集プロトコルの既定。CRUD操作を実現する。

AtomPubに向いているWeb API
ブログサービスや検索機能を持つデータベースAPIなど

AtomPubに向いていないWeb API
リアルタイム性が重要なAPIや映像のストリーム配信など、HTTP以外のプロトコルを必要とするAPIなど
また、「タイトル」「作者」「更新日時」など、Atom フォーマットが用意するメタデータが不要なAPI

JSON

JSONは、データ記述言語。

メリット
XMLに比べて冗長性が低く、データ表現のフォーマットとして利用される。 クロスドメイン通信ができ、Ajaxでは必須の技術。

Webサービスの設計

ここからが設計者として一番重要な章。
WebサービスとWebAPIは分けて考えないことが重要。

リソース指向アーキテクチャ(ROA)

本書では、まずリソース指向アーキテクチャ(ROA)でアプローチしている。
詳しくは、
リソース指向アーキテクチャ(ROA)とは何なのか - Qiita

本書では、以下の手順で設計している。
1.Webサービスで提供するデータを特定する
2.データをリソースに分ける
3.リソースにURIので名前を付ける
4.クライアントに提供するリソースの表現を設計する
5.リンクとフォームを利用してリソース同士を結び付ける
6.イベントの標準的なコースを検討する
7.エラーについて検討する

以下にそれぞれの手順での注意点を示す。

1.Webサービスで提供するデータを特定する, 2.データをリソースに分ける
このWebサービスでは、どんな情報を提供するのか？を基準に機能をリソースに落とし込む。
この時、機能の結果をリソースとしてとらえることが重要。例えば、検索結果が1つのリソースになる。

3.リソースにURIので名前を付ける
URIは、人間にとって読みやすいURIとプログラムにとって読みやすいURIが異なる場合がある。
その時は、代替リソースとしてプログラムにとって読みやすいURIとすることも考える。

4.クライアントに提供するリソースの表現を設計する
適切なXML表現やフォーマット、マルチメディア表現などを選択する。
XML表現は独自のフォーマットを作り出さないように選択する。

5.リンクとフォームを利用してリソース同士を結び付ける
リンク関係を図にまとめるなどする。

6.イベントの標準的なコースを検討する
Webサービスが提供すると思われる利用コースを検討する。矛盾などがないか検討する。

7.エラーについて検討する
エラーを検討してステータスコードを検討する。

また、書き込み可能なWebサービスの場合、以下の検討が新たに必要になる。

他の設計手法

リソース指向アーキテクチャ(ROA)での以下の2つが一番の肝のためある程度確立されている手法で補う。
1.Webサービスで提供するデータを特定する
2.データをリソースに分ける

本書では、以下の方法をあげている。それぞれの導出できないものがあるため特徴を知って使うようにする必要がある。
a.関係モデルのER図
b.オブジェクト指向モデルのクラス図
c.情報アーキテクチャ

a.関係モデルのER図
リソースの設計は、正規化を崩す。
Webサービスは、一度のリクエストでクライアントが必要な情報が取得できるように設計するため。
リソースの導出はしやすいイメージ。

ただ、トップレベルリソース、URI階層構造や一部リソースを導出できない。

b.オブジェクト指向モデルのクラス図
階層やリソース間のリンク関係の検討はしやすいイメージ。

ただ、トップレベルリソースを導出できない。

c.情報アーキテクチャ
本書では、おすすめの手法。
情報アーキテクチャをもつWebサイトの構造は、ほぼWebサービスにそのまま適用できる。
ROAの苦手なリソース分類を補える。
詳しくは、
情報アーキテクチャとは | murashun.jp
ホームページ制作に役立つ「情報アーキテクチャ（IA）」とは。インフォメーションアーキテクトとの違いと基本的なポイントを解説｜ferret
情報アーキテクチャ（IA）の基礎と基本 | ブログ | 株式会社モンゴロイド｜Webマーケティング

感想

簡単な技術が流行るという話が本書ではあるが、まさにソフトウェアの設計はシンプルこそ正義だなと普段開発してて思います……。

認証関係もあまり詳しくないため以下のサイトとか見て勉強しました。
認可と認証、その種類 - 研鑽の日々

あと、情報アーキテクチャはどうやるかは本書では分かりにくいです。本書でも詳しくは、Web情報アーキテクチャ 第2版へと書かれています。
今は、Web情報アーキテクチャ 第4版でしょうか？

基本的なWebってどんな技術で成り立ってるの？と設計がどうやってしているの？が知れました。
本格的にWebサービスを作るなら設計についてはもうちょっと情報が欲しいなと思いました。