Web
インターネット通信技術を使った世界規模の情報システム
- 用途
- Webサイト、設定画面UI、WebAPI
- 技術
- HTTP、URI、HTML
ハイパーメディア
リンク(ハイパーリンク)で情報を結び付けるWebの機構
文字や動画、あるサイトからあるサイト等結リンクに飛べる仕組み
ブラウザ
ユーザーがWebにアクセスするためのソフトウェア
ブラウザを介してWebの情報を閲覧や操作をする
アーキテクチャスタイル
アーキテクチャ(システムにおける共通した様式)のスタイル
例）WebのアーキテクチャスタイルはRESTでアーキテクチャはURIやHTTP
- REST
- MVC
- パイプ&フィルタ
- イベントシステム
URI
Uniform Resource Identifier
情報(リソース)の場所を示す識別子＝リソースの名前のこと
http://blog.jp/hoge
スキーム：プロトコルhttp
ホスト名：blog.jp
パス：/hoge
より複雑な場合
http://yohei:pass@blog.example.jp:8000/search?q=test&debug=true#10n
ユーザ名：yohei:pass
ポート番号:8000
クエリパラメータ：q=test&debug=true
URIフラグメント：#10n
ベースURI
相対URIの基底となるURI
※相対URI→/や../ といった相対表記で表すURIの示し方。
HTMLでベースURIを指定するａａ用途
- Webサイト、設定画面UI、WebAPI
- 技術
- HTTP、URI、HTML
ハイパーメディア
リンク(ハイパーリンク)で情報を結び付けるWebの機構
文字や動画、あるサイトからあるサイト等結リンクに飛べる仕組み
ブラウザ
ユーザーがWebにアクセスするためのソフトウェア
ブラウザを介してWebの情報を閲覧や操作をする
アーキテクチャスタイル
アーキテクチャ(システムにおける共通した様式)のスタイル
例）WebのアーキテクチャスタイルはRESTでアーキテクチャはURIやHTTP
- REST
- MVC
- パイプ&フィルタ
- イベントシステム
URI
Uniform Resource Identifier
情報(リソース)の場所を示す識別子＝リソースの名前のこと
http://blog.jp/hoge
スキーム：プロトコルhttp
ホスト名：blog.jp
パス：/hoge
より複雑な場合
http://yohei:pass@blog.example.jp:8000/search?q=test&debug=true#10n
ユーザ名：yohei:pass
ポート番号:8000
クエリパラメータ：q=test&debug=true
URIフラグメント：#10n
ベースURI
相対URIの基底となるURI
※相対URI→/や../ といった相対表記で表すURIの示し方。
HTMLでベースURIを指定する
<HTML>
<head>
<base href="http://example.jp">
</head>
...
</HTML>
％エンコーディング
URIに日本語などASCII文字(アスキー)以外の文字を入れる際に使う方法
UTF-8でエンコード
https://ja.m.wikipedia.org/wiki/%E3%81%82
URI設計の大事な2つのポイント
- %エンコーディングはUTF-8で指定する
- 相対URIはなるべく使わない、絶対URIでAPIなど設計する
アドレス可能性
Adressability
リソースにしっかり名前がついておりURI(アドレス)で指し示せる状態
クライアント/サーバ
アーキテクチャスタイル
- クライアント
- サーバにリクエストを送信
- サーバ
- クライアントにレスポンス(情報)を返す
利点：UIとデータストレージの機能を分けて、マルチプラットフォーム化や冗長性向上
ステートレスサーバ
クライアントサーバで、サーバがクライアント側の状態を管理しない
クライアントはリクエスト毎にすべての情報を送信する
キャッシュ
Cache
リソースの鮮度に基づいて、一度取得したリソースをクライアント側で使いまわす方式
ローカルストレージにリソースを蓄積する
利点：クライアントサーバ間の通信を減らして効率的にする
キャッシュ用ヘッダー
- Pragma
- キャッシュ可能か(no-cache✖)
- Expires
- キャッシュの有効期限
- Chace-Control
- 詳細な有効期限やキャッシュ可否の設定
統一インターフェース
アーキテクチャスタイル
URIリソースへの操作は、統一された限定的なインタフェースでのみ行われる
(たとえばHTTPメソッドなど)
利点：全体のアーキテクチャがシンプルになる
階層化システム
アーキテクチャスタイル
システムをいくつかの階層に分離する
ロードバランサによる負荷分散や、プロキシによるアクセス制御など
コードオンデマンド
サーバからダウンロードしたプログラムをブラウザ上で実行する仕組み
JavaScriptやFlashがそう
REST(アーキテクチャスタイル)
- クライアント/サーバ
- ステートレスサーバ
- キャッシュ
- 統一インタフェース
- 階層化システム
- コードオンデマンド
これらの原則をすべて備えた複合アーキテクチャスタイル
RESTful
RESTの制約に則ってRESTらしいことを示す
例）APIがRESTfulだとシンプルで柔軟な、よいシステムになる
WebAPI
プログラム向けのインタフェースのこと
アプリケーションの機能やアプリケーション同士の連携に使う
プログラムが解釈しやすい様にデータ形式はJSONやXML
HTTP
あらゆる情報を転送するプロトコル
HTMLなどハイパーテキストや画像、ファイル、JavaScriptプログラムなど
TCP/IP
HTTPを支えるインターネットプロトコル
-
IP
- 指定したIPアドレスに向けてパケット(データの通信単位)を送り出す
-
TCP
- IPが保証しなかったデータの転送を保証する
- コネクションを使ってポートに送る
HTTPメッセージ
HTTP通信で送られるリクエストメッセージとレスポンスメッセージのこと
HTTPメソッド
リクエストメッセージで送る情報
クライアントが行いたい処理を伝える８つのメソッド
データ操作の基本、CRUD(クラッド)の性質はGET, POST, PUT, DELETEで実現
-
GET
- リソースの取得。検索など。キーワードがURIに格納される
-
POST
- 子リソースの作成。追加、投稿など。キーワードはリクエストボディに格納
-
PUT
- リソースの更新。作成、上書き更新など。
-
DELETE
- リソースの削除。
POSTとPUTの使い分け
どちらもリソース作成が出来るが
POSTで作成する場合：サーバ側が自動的にURIを決定する(Xの投稿など)
PUTで作成する場合 ：クライアント側がURIを決定する(Wikiのページなど)
べき等性と安全性
べき等：ある処理で同じ結果が必ず得られる
安全：リソースに変化が無いこと
- DELETEやPUTはべき等で、同じリクエストを何度送っても同じ結果になる
- GETはべき等かつリソースを変化させないため安全
-
POSTはべき等でなく安全でない
- (何度も更新される恐れがある為「再送しますか？」と出る)
✖ POSTで他のメソッドの処理を代用する
✖ PUTで差分を送信して更新する