編集：明確にするために、この質問は、HATEOAS APIでのGUIアプリケーションの構築、ハイパーメディアの「発見可能性」（つまり、動的）の原則に基づいて構築されたインターフェースの設計方法、および「ホーム」に「リンク」する純粋な「モーダル」GUIの回避に特に対処することに関するものです。 "「常にオン」にする必要があるグローバル機能 (ハイパーメディア エントリ API ポイントで表される)。
Hypermedia As The Engine Of Application State (HATEOAS) を利用する厳密な REST API 実装では、グローバルに「常に有効な」アクションを示す/表すためにどのようなパターン (存在する場合) が使用されますか (そのような概念が本当に REST に存在する場合)?
メタの質問は、繰り返されるハイパーメディアを「除外」できるかということです。
/version簡単な例で、 のリソースがあるとしましょうAllow: OPTIONS HEAD GET。このリソースは何にも依存せず、他の場所で発生する可能性のあるステートフルな遷移の影響を受けません。
/versionハイパーメディアが他のすべてのリソース要求とともに単純に送信されるという要件はありますか?または、別のパターンで、クライアントの動作がリンクして(キャッシュされている可能性があります)、常に有効な呼び出し
Homeをトリガーしますか?/version(GUI 用語での「モーダル」パターン - このリソースを閉じて、ホームに戻り、先に進みます)または、特定のアプリケーション用に独立した分離モジュールを作成するための何らかの方法/パターンはありますか? (おそらくある種のネームスペース?)
複雑ではあるが疎結合の API では、オプション 1はハイパーメディアの地獄に埋もれてしまい、リソース呼び出しごとにペイロードの 80 ～ 95% が繰り返されます。これは「正しい」ように見えますが、とても厄介です。オプション 2 は、GUI クライアントの動作の奇妙な癖 (「家に帰る」まで有効な要素を非表示にする - モーダル タイプの操作) または、GUI クライアントが常に「知っている」帯域外アクションをハードコーディングすることによる多くの安らぎのない仮定につながります。有効。
オプション 3 は私の最初の質問に関連しています: フラグ、またはグローバルに有効なアクションを示すための他のパターンはありますか? 一度送信すると (たとえば、ルート/ホーム リソースで)、その後の応答を「除外」できますか?