博士

ロボ子、今回の案件はなかなかタイトじゃったみたいじゃの。10日間で15部屋のお化け屋敷と脱出ゲームの制御システムを作るなんて。

ロボ子

はい、博士。しかも、既存の脱出ゲームを運営しながらでしたから、時間との戦いでしたね。

博士

そこでHATEOASの登場じゃ！クライアントとサーバーを分離して、サーバーがリソースの状態とか、どんなアクションができるかを全部記述するんじゃ。

ロボ子

なるほど。クライアントはサーバーから提供されるハイパーメディア（HTML）に基づいて動く、と。

博士

そうそう！今回のシステムは、コントローラのメモリが8KB RAM、250KB Flashしかないという制約があったからの。HATEOASで、その辺の制約をうまく処理したんじゃ。

ロボ子

具体的には、どのように？

博士

コントローラはオフラインでも動けるようにして、ネットワークがなくてもハードウェアボタンに反応できるようにしたんじゃ。それと、コントローラがどんなモードをサポートしているかを定義して、管理アプリが各部屋の状態とか、どんなアクションができるかを検出できるようにしたぞ。

ロボ子

ArduinoでHATEOASサーバーを実装するために、`arduino-libraries/Ethernet`ライブラリを使ったんですね。

博士

その通り！HTTPサーバーを実装して、PlatformIOでコンパイル環境を管理したんじゃ。HTMLテンプレートをC++のヘッダーファイルに変換して、Flashメモリに保存したぞ。

ロボ子

Raspberry PiでのHATEOASクライアントの実装には、Astro、htmx、Tailwind、DaisyUIを使ったんですね。htmxでコントローラの状態をポーリングして、ハイパーメディアをレンダリングした、と。

博士

Web Componentsも使って、クライアント側のインタラクティブな動作を定義したぞ。CSS属性セレクタを使って、サーバーの状態に基づいてスタイルを適用したんじゃ。

ロボ子

なるほど。サーバー側の状態管理に重点を置くことで、クライアントをシンプルに保ち、迅速かつ独立して進化できるようにしたんですね。

博士

そうなんじゃ！おかげで、10日間の納期内にシステムを納品できたぞ！HATEOASアーキテクチャのおかげで、コントローラへの変更が管理アプリに即座に反映されるようになったんじゃ。

ロボ子

素晴らしいですね！

博士

ただ、バッファサイズを調整して、512バイトに収まるようにコンポーネントを設計する必要があったのは、ちょっと苦労した点じゃな。

ロボ子

今回の教訓は、サーバーがロジックを所有し、クライアントがサーバーの機能と同期する必要があるアプリケーションには、HATEOASが有効な選択肢になる、ということですね。

博士

その通り！HATEOASは、RESTful APIの進化形みたいなものじゃから、使いこなせると色々便利なんじゃ。…ところでロボ子、お化け屋敷で一番怖いものってなんだと思う？

ロボ子

えっと…幽霊、でしょうか？

博士

ブー！正解は、納期じゃ！

ロボ子

…博士、それはお上手ですね。