クライエント側のサーバー側も、一番下のレイヤーはキャッシュでなければいけない。

今仮にクライエント側のキャッシュ・レイヤーが以下のようなリクエストを
サーバー側のキャッシュ・レイヤーに送ったとしよう。

=========================================================
Request

mode:available

Item1:
	time:2020-01-23 14:23:34
	name:button templates

Item2:
	time:2020-01-23 12:03:11
	name:vote counts

---------------------------------------------------------
※　modeにはavailableとcompleteがある。
※　timeはクライエント側にあるデータのキャッシュの発行時刻である。
=========================================================
サーバー側のキャッシュ・レイヤーのアルゴリズム

	[ケースA] サーバー側が同名のキャッシュを持っていた場合

		クライエント側とサーバー側のキャッシュの時刻を比較する

		[ケースA１]　クライエント側の時刻が、サーバー側の時刻より、前の場合
			データは送る。

		[ケースA２]　クライエント側の時刻が、サーバー側の時刻と同じか、後の場合
			「最新です」というメッセージを送って、データは送らない。

	[ケースB] サーバー側が同名のキャッシュを持っていない場合

		[ケースB１]　リクエストモードがavailableの場合
			「キャッシュされていません」というメッセージを送って、
			HTTPのコネクションをCloseして、本体にデータの作成依頼を出す。

		[ケースB２]　リクエストモードがcompleteの場合
			HTTPのコネクションを維持したまま、本体にデータの作成依頼を出して、
			データの作成が完了したら、キャッシュして、クライエント側に返す。
			もし既に作成依頼がでていたら、それはキャンセルしなければいけない。

=========================================================
Response

wait:0

Item1:
	time:2020-01-23 14:23:34
	name:button templates
	result:「データ」
	data:{......}

Item2:
	time:2020-01-23 12:03:11
	name:vote counts
	result:「キャッシュされていません」

=========================================================
クライエント側のキャッシュ・レイヤーのアルゴリズム

resultが「データ」か「最新です」なら、triggerして本体に伝える
resultが「キャッシュされていません」の項目は、waitだけ待って、
再度リクエストを行う。その場合、モードはcompleteになる。

=========================================================
Request

mode:complete

Item2:
	time:2020-01-23 12:03:11
	name:vote counts

=========================================================