📖
【初学者によるまとめ】この一冊で全部わかるWeb技術の基本 「Chapter1」>「10. Webの設計思想」
目的:「イラスト図解式 この一冊で全部わかるWeb技術の基本」の要点を自分なりにまとめアウトプットして理解力の向上に努める。
注意点 |
---|
🤔 ←この絵文字の文章は個人的な見解になります。的外れなこともあるかと思います。 |
(参考書籍)
イラスト図解式 この一冊で全部わかるWeb技術の基本
(参考サイト)
Claude
talend
RedHat
IBM
so-zou.jp
IT用語辞典
Webの設計思想 - Web技術で推奨される2つの思想
標準化という扱いをされた規格以外にも、Web技術の世界における"思想"がある。
(現実世界でいう信仰とかにあたる考え方の話)」
RESTful
REST
(REpresentational State Tranfer):「表現的状態遷移(Google翻訳)」
- REST は4つの原則からなるシンプルな設計のこと
- 調べたところ「標準化された設計のルールではない」らしい
だから設計の"思想"という言い方が適切
- 調べたところ「標準化された設計のルールではない」らしい
- RESTfulなシステムは「前回のやりとり結果を保持しない」のが第一特徴
- 例)セッション情報、クッキー など
- 「前回のやりとり結果を保持しない」という思想の恩恵として、『システムがシンプルな構造になりやすい』
以下、RESTfulの原則[1]
RESTの原則 | 補足 | |
---|---|---|
統一インターフェース | あらかじめ定義・共有された方法での情報のやり取りがされている | WebにおいてはHTTPプロトコル(=定義)、GETメソッド、POSTメソッドら(=方法)が該当 |
アドレス可能性 | すべての情報が一意なURLの構文で示される | https://〜 を採用している |
接続性 | やりとりされる情報にはリンクを含めることができる | HTMLにおけるハイパーリンクのこと(<a href="PATH"></a> ) |
ステートレス性 | やりとりは1回ごとに完結し、前のやりとりの結果に影響を受けない | "統一インターフェース"で定義したHTTP自体にはステート(状態)を保持するためのセッション機能は無いため。(セッションはサーバーで生成・保存される。) |
::: note info
昨今の多くのWebアプリにおいて、RESTful設計が採用されている
:::
セマンティックWeb
"semantic":「意味の、語義の、意味論の、意味的な」
-
Webページの情報に意味を付け加えたもの
- コンピューターが自律的に情報の意味を理解して処理できるようになることを期待する
- 情報を検索するときの精度向上などを目的に「情報に対する"意味付け"」をメタデータと呼ぶ
- "情報の上位(メタ)情報" > 「人間宛にWebページを造形するためのHTMLという情報」に対して「検索エンジンなどの機械宛に検索されやすくするためのXMLという上位情報」を付加する
::: note info
メタデータの付与によってより高度な処理が期待されるが、作業が手間な点もあり普及していない。
:::
- "情報の上位(メタ)情報" > 「人間宛にWebページを造形するためのHTMLという情報」に対して「検索エンジンなどの機械宛に検索されやすくするためのXMLという上位情報」を付加する
個人的疑問・所感など
🤔<(...。さっぱりイメージつかん。情報の正否の問題はあるがAIに聞いてみよう。)
<details><summary>"Claude"に質問してとりあえずイメージを掴む...</summary>
参考として Claude に聞いてみた(1)
【Claudeへの質問】
RESTfulという思想について端的に教えてください
-----
【Claudeによる回答】
RESTfulという思想について端的に教えてくださいRESTful(REpresentational State Transfer)は、Web上でリソース(データ)を操作するための設計思想です。以下の特徴があります。
1. リソース重視のデータ設計
データをURIによって一意に識別される「リソース」として扱います。
例: /users/1 というURIはユーザーリソース1を表します。
2. HTTPメソッドの適切な使用
リソースに対する操作をHTTPメソッド(GET, POST, PUT, DELETE)で表現します。
GET: リソースを取得
POST: 新規リソースを作成
PUT: リソースを更新
DELETE: リソースを削除
3. 無状態(Stateless)
リソースとリソースの状態は別物であり、サーバーはリクエストだけで処理を完結させます。
状態はリソースに含まれる。
4. リソースの表現の転送
リソースの状態は、JSONやXMLなどで表現され、クライアントとサーバー間で転送されます。
この設計思想に従うことで、Web APIのインターフェースが明確で理解しやすくなり、疎結合なシステムを構築しやすくなります。現在のWebサービス・クラウドサービスでは広く採用されています。
参考として Claude に聞いてみた(2)
【Claudeへの質問】
「ステートフルなシステム」の例を"ECサイト"を例題に教えてください
-----
【Claudeによる回答】
ECサイトはよくステートフルなシステムの代表例として挙げられます。
ECサイトにおけるステートフルな設計の例を挙げると、以下のようになります。
・ショッピングカートの管理
カートに追加した商品をサーバー側のセッションに保持し、ユーザーが別のページに移動しても情報が失われないようにします。
セッションIDを使ってユーザーの状態を特定します。
・購入履歴の保持
過去に購入した商品の履歴をデータベースなどに永続的に保存しておきます。
ユーザーはその履歴を参照でき、継続的な体験ができます。
・ログイン認証と個人情報の管理
ユーザーのログイン状態やプロフィール情報など、認証に関する情報はセッションやデータベースに保持されます。
リクエストごとにその情報を確認します。
・実時間在庫管理
商品の在庫数は絶えず変化するステートフルな情報です。
注文処理と連動して在庫数を都度更新し、最新の情報を表示する必要があります。
・リアルタイムチャット
カスタマーサポートのチャットなどでは、サーバーとクライアント間で永続的なコネクションを維持し、
メッセージのやり取りの状態を保持し続ける必要があります。
このように、ECサイトではユーザーエクスペリエンスを改善したり、
継続的なサービスを提供したり、リアルタイムな情報を扱ったりするために、
ステートフルなシステム設計が不可欠となっています。
参考として Claude に聞いてみた(3)
【Claudeへの質問】
「ステートレスなシステム」の例を"ECサイト"を例題に教えてください
-----
【Claudeによる回答】
ECサイトにおけるステートレスな設計の例を挙げると、以下のようになります。
・検索機能
検索ワードを受け取り、そのワードに基づいて商品情報を引き出すだけの単純な検索機能はステートレスです。ユーザーの状態を考慮する必要はありません。
・商品の詳細ページ
特定の商品IDを受け取り、その商品の情報を表示するだけの静的なページはステートレスになります。他のリソースに依存しないため、RESTfulな設計が可能です。
・広告の表示
クッキーなどを使わず、単にリクエストを受け取って広告を返すだけの機能はステートレスです。ユーザー情報は考慮しません。
・非会員購入
会員登録を行わずに、都度、購入者情報と購入商品を投げ渡すだけのシンプルな購入フローはステートレスにできます。
・注文履歴の表示
注文IDを引数にとり、その注文の履歴情報を参照するだけのシンプルな機能はステートレスにできます。
このように、一部の軽量な機能や副次的な機能では、ステートレスでRESTfulなAPIの設計が可能です。
ただしECサイト本体の主要機能(カート、認証、在庫管理など)ではユーザー状態を考慮する必要があり、
ステートフルな設計が不可欠になってきます。
全体としてステートフルな設計が中心になりますが、
一部の機能でステートレスなアーキテクチャを採用することで、
開発の簡略化やスケーリングのしやすさなどのメリットが得られる可能性があります。
</details>
- APIという仕組みが昨今流行っている背景も関係してRESTful設計が流行っているという理解をした。
- 「他のWebアプリにAPIとして組み込んでもらう」には"組み込みやすさ"が重要なので、RESTfulという思想の元でお互いがシステム設計をすれば互いに恩恵を受けられるという感じだと思う。
- RESTfulではjsonなどの中立的な情報形態を採用することで"シンプルさ"を実現していると思う。
・ステートレスという点について「セッションを用いたログイン状態の保持」も該当するのであるなら、昨今のWebサイトって全部ステートフル(非ステートレス)な設計ということになるのでは?と思った。
→「RESTが流行っている」と散見されたが、「完全なRESTの原則に沿った設計」というよりも「RESTの思想を参考にしましょうね」という意向なのか謎。「それって半RESTな設計もREST設計に相当するから"RESTが流行っている"といわれている?」と色々と疑問が残った。
-
イラスト図解式 この一冊で全部わかるWeb技術の基本 > P31の図より ↩︎
Discussion