リソース
- Web上の名前を持った情報すべて。
- その名前が一意なURIに該当。
URI(Uniform Resource Identifer)
- リソースを統一的に識別するIDのこと。
- 構成は「スキーム(プロトコル)://(ホスト名orIP)/(パス)
- プログラムがリソースを簡単に指し示すことができる性質を
アドレス可能性(Addressability)という。 - URIはアドレス可能性を備えており、プログラムから認識できる特定の構造でリソースを表現できる。
- 1つのリソースに複数のURIを当てることも可能だし、さし示す先のリソースの状態をあとから変化させることもできる。
REST
- RESTは以下のスタイルを全て（または一部）組み合わせたアーキテクチャスタイル。
- 頭文字を並べたULCODC$SS＝REST。
- 除外するスタイルが多くなる場合はそもそもREST以外を検討（P2Pとか）
クライアント/サーバ構成 Client(C)
- 単一のコンピュータ上で処理を行うのではなく、クライアントサイドとサーバサイドで処理を分散すること。
- 種々のクライアント(端末)に対応することができ、影響範囲が小さい。
- サーバの冗長化による可用性向上。
ステートレス Stateless Server(SS)
- アプリケーションの状態(＝セッション状態)をサーバ側で管理しないこと。
- サーバ側で情報を持たないことでサーバの計算リソースを占有しない構成を取れる。
※ ただし、セッション情報を維持した方が利便性が高いケースも当然ある（ログインして入るページなど）。こうしたケースでは一般にCockieが用いられる。
ELBでセッション管理が可能だがDynamoなどに書き出して保持する構成はこのスタイルを意識したもの？
ステートレスの欠点
- データ量が多くなることでネットワーク帯域を消費する可能性
- 冪等性がない可能性
キャッシュ Cache($)
- 一度取得したリソースをクライアント側で保持すること。
- クライアント/サーバ間の通信回数を減らし効率化。
統一インターフェース Uniform(U)
- すべてのサーバは同じ規格のインターフェース(GETやPOSTなど全8種類のメソッドのみ)を有する。
- それ以上の拡張は認められない（柔軟性の制限）。
- 全てのサーバへのアクセスのインターフェースを統一することでクライアントとサーバを分離し、影響範囲を小さくできる。
階層化システム Layered(L)
- インターフェースの統一によりクライアント/サーバ間の変更を両者とも気にする必要がない。
- システムの階層化(ロードバランサやプロキシを挟んだ構成)をできること。
- 異なるインターフェースのレガシーシステムとの接続が可能。
コードオンデマンド Code on Demand(COD)
- コードをサーバからダウンロードし、クライアント側で実行すること。
- クライアントを後から拡張可能。
- ただし、アプリケーション全体の可視性は低下する(=クライアント側で実行開始後はサーバ側から把握できない？) 。
RESTとRPCとの比較
関数呼び出し
- 通常の関数呼び出しをネットワーク越しに実行するのはオーバーヘッドが大きく、何回も実施するとなると性能面で不安がある。
- RESTのAPI呼び出しではそれより粒度が大きいので比較的問題にならない。
変更への強さ
- RPCはAPI使用が変わると互換性が失われ、全てのクライアントの修正が必要になる。→Webサービスに向かない。車内のみのツールやSDKではいい。
- RESTのAPIは規格が厳密で下位互換なためWebサービスに広く用いられる。
URI設計
- URIはリソースの名前なので動作を示す名称をつけるのは好ましくない。
- 拡張子を用いるのは1つのリソースに対して表現を複数用意する時。
eg) 言語設定(en/jp)、フォーマット(json/xml) - 複数のパラメータで表現するリソース(緯度経度で表現する地図座標など)に対してはパラメータをセミコロンで繋ぐ。
なお、リソースの言語選択にコンテントネゴシエーションを用いる方法もあるが、日本語OSの利用者が英語版をみたい時などにブラウザの設定を変更する必要があるなど面倒がある点を考慮する必要がある。
HTTP
- RESTの特徴を実現するWebの基盤となるプロトコル。
VSCodeからHTTPリクエストを送ってみる。
ファイル形式をhttpとしてopt+cmd+Rで送信（右クリックから選択も可）。
test.http
GET /timeline HTTP/1.1
Host: qiita.com
- クエリパラメータも指定可能。
- パスは相対パスでも絶対パスでokだが、
Hostの指定は必須。
GET /search?q=test HTTP/1.1
Host: qiita.com
HTTPメソッド
PUTとPOSTの違い：リソース作成時にURIを指定する権限がクライアント側(PUT)にあるかサーバ側(POST)にあるか
ヘッダ情報
MIMEメディアタイプ
- メッセージでやりとりするリソースの表現を指定する。
-
Content-Type: (タイプ)/(サブタイプ)のように指定。 - サブタイプには
x-を付すことで独自に拡張できる。