- ブラウザURL入力
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口
- アプリ処理今ここ
- DB保存
前回、境界とは名前が解決される場所であり、解決が失敗する時期が境界の硬さだと見ました。今回は実務が最も強く守っている1本の線に名前を与えます。
まず結論
リソース風の URL を作らなくても、台数を増やせる構成なら、既に Fielding が論文で2番目に導入した制約に従っています。名前は stateless です。
これは uniform interface の下位ではなく、別の節で別に導入される独立した制約です。名前と位置が分かると「どこを譲れて、どこを譲れないか」を語れます。
Fielding の博士論文 第5章は、REST を導くときに制約をいくつ挙げていると書いているでしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
守っているのに、名前を知らない
前回、線とは名前が解決される場所であり、解決が失敗する時期が線の硬さだと見ました。今回は実務が最も強く守っている1本を取り上げます。
その線には名前があります。Fielding の2000年の博士論文 第5章が、REST を導く途中で2番目に足した制約です。
第7期『状態を持たないHTTPとCookie/セッション』で、合言葉は運べるが表は運べないこと、実体が2つになった瞬間に表が割れることを実測つきで見ました。あれは現象の側です。今回足すのは名前の側だけです。
名前が無いものは、他人に説明できず、変更の可否も判断できません。「なんとなくこうしてきた」は、誰かが「ここだけ例外にしよう」と言ったときに反論の形を取れません。
この制約がどの位置で足されるのかを、章の構成ごと見ます。
- ・§5.1.1 は The Null style ... is simply an empty set of constraints. と原文が書く出発点
- ・stateless は §5.1.3、uniform interface は §5.1.5。別の節で別々に導入される
論文は、制約をいくつあるとは書いていない
制約が導入される節は §5.1.2 から §5.1.7 までの6つ。しかし論文自身はどこでも個数を数えていません。 最もよく流通する「REST には6つの制約がある」を、第5章の全文に当たって潰します。
探した語 ヒット 意味six 0件 「6つ」と書かれた箇所は無いfive 0件 「5つ」と書かれた箇所も無いseven 0件 「7つ」と書かれた箇所も無い
さらに §5.1.7 は code-on-demand について is only an optional constraint within REST と書き、The notion of an optional constraint may seem like an oxymoron. と断ったうえで、任意の制約という考え方を1段落かけて説明しています。「6つ全部を満たすものが REST だ」は、この optional の扱いと食い違います。数を言わずに構造を言うのが原文に忠実な読み方です。
stateless は uniform interface の下位にある制約ですか。
制約に名前を与えると、代償まで一緒に付いてくる
名前の効き目は、呼びやすくなることではありません。その制約が何を誘発し、何を犠牲にするかが一緒に付いてくることです。まず誘発される性質。原文は3つを同格で挙げます。
第7期で見た「表が割れる」現象に噛み合うのは3つ目、Scalability is improved because not having to store state between requests です。要求の間で状態を持たないから、どの実体に投げても同じ結果になる。
ただしスケーラビリティだけを取り出すと原文より狭くなります。 1つの要求を見れば全体が分かること(visibility)も、故障からの復帰が楽になること(reliability)も、同じ制約から同格に出てくる性質です。そして原文は代償も書きます。
a design trade-off です。毎回同じ情報を繰り返し載せるぶんネットワーク性能は下がりうるし、状態をクライアント側に置けば、一貫した振る舞いに対するサーバの制御は弱まります。制約は無料ではない、と原文自身が書いている——ここを落として利点だけ引くのが、要約でいちばん起きやすい事故です。
同じ『制約』という語が、2つの階層で使われている
原文を読むときにもう1つ躓く箇所があります。§5.1.5 の最終段落です。
ここに constraint が2つの意味で同居しています。§5.1.2 から §5.1.7 まで順に足していく制約と、§5.1.5 の内側にある4つの interface constraints。語は同じでも階層が違います。
層 導入される場所 例外側 §5.1.2〜§5.1.7 client-server / stateless / cache / uniform interface / layered system / code-on-demand内側 §5.1.5 の中 identification of resources / manipulation through representations / self-descriptive messages / hypermedia as the engine of application state
stateless は外側の層にあり、内側の4つには含まれません。 つまり「URL がリソース風かどうか」で判定される話(内側寄り)と、「要求が単独で理解できるか」という話(外側の §5.1.3)は、別々に問える別の制約です。
「ステートレスはスケーラビリティのための制約だ」という要約の評価はどれですか。
stateless(§5.1.3)
client-server の次に足される制約です。原文は optional とは書かず、誘発される3つの性質と2つの代償を並べています。足された以降、導出の最後まで効いたままです。
項目 原文の書き方位置 client-server の次に add する任意か optional の語は無い誘発する性質 visibility / reliability / scalability の3つ代償 a design trade-off として2つ明記
code-on-demand(§5.1.7)
導出の最後に足される制約です。原文は利点を挙げつつ visibility を下げるとし、is only an optional constraint within REST と書きます。効くと分かっている範囲でだけ利点と代償が生じます。
項目 原文の書き方位置 the final addition to our constraint set任意か is only an optional constraint within REST概念の説明 may seem like an oxymoron と断って1段落効く条件 known to be in effect for some realm of the overall system
同じ章で同じ「制約」と呼ばれている2つです。扱いの違いは、何を語るときに効いてくるでしょうか。
「この系は制約Xに従っているか」と聞かれたとき、2つで答え方がどう変わるかを考えてみてください。
この章のまとめ
- 実務が最も強く守っているのは、リソース風の URL ではなく stateless。Fielding 博士論文 §5.1.3 で client-server の次に足される制約。
- stateless は uniform interface(§5.1.5)の下位制約ではない。 §5.1.5 の内側にある4つには含まれない。
- §5.1.3 が誘発する性質は visibility, reliability, scalability の3つが同格。1つだけ取り出すと原文より狭い。
- 原文は代償も書く。
a design trade-offとして、繰り返しデータの増加とクライアント実装への依存の2つ。 - 論文は制約の個数を数えていない(第5章に
six/five/sevenは0件)。code-on-demand だけがis only an optional constraint within RESTと明記。 - 名前の効き目は障害を減らすことではなく、どこを譲れてどこを譲れないかを説明できる形にすること。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
AI が「REST には6つの制約があり、そのすべてを満たすものが REST です」と説明しました。原文と照らしてどこが問題ですか。
用語集(4語)
- stateless(Fielding 博士論文 §5.1.3)
- 各要求が、その要求を理解するのに必要な情報をすべて含み、サーバ上に蓄えられた文脈を利用できない、という制約。原文は Session state is therefore kept entirely on the client. と続ける。
- uniform interface(同 §5.1.5)
- 構成要素間のインタフェースを統一する制約。原文は REST is defined by four interface constraints と述べ4つの下位制約を挙げる。stateless はこの4つに含まれない別の制約。
- optional constraint(同 §5.1.7)
- code-on-demand について原文が使った言い方。is only an optional constraint within REST と書かれ、その概念自体が oxymoron に見えるかもしれないと断って説明されている。
- design trade-off(同 §5.1.3)
- 原文が stateless について使った語。利点だけでなく代償を伴う設計上の交換であること。代償は繰り返しデータの増加と、クライアント実装への依存。