要約: APIをデータAPIとアプリケーションAPIに分割する場合、ここで提唱されているように、アプリケーションAPIをJSONからハイパーメディア（HTML）に変更し、htmxのようなハイパーメディア指向のライブラリを使用して、ハイパーメディアモデルの利点（シンプルさ、信頼性、柔軟性など）を活用することを検討する必要があります。
最近、マックス・チェルニャックは独自のフロントエンドを強化するための汎用APIを構築しないでくださいというエッセイを書きました。彼の要約は次のとおりです。
フロントエンドが連携した大企業やGraphQLで作業しているのでなければ、YAGNI（You Ain't Gonna Need It：必要なことだけをする）です。
彼は、汎用APIとアプリケーションAPIの異なるニーズについて議論しています。彼は、汎用APIのニーズとして以下を挙げています。
そして、アプリケーションAPIのニーズとして以下を挙げています。
私は、このニーズの不一致をデータ/アプリAPIインピーダンスミスマッチ問題と呼びます。
マックスの推奨事項は、APIを汎用APIとアプリケーションAPIの2つの「半分」に分割することです。
フロントエンドを汎用APIクライアントとして扱うのではなく、アプリの半分として扱うことをお勧めします。
「ページ」全体のJSONを送信できると想像してみてください。
/page/aのエンドポイントを作成し、そこで/page/aのJSON全体をレンダリングします。すべてのページでこれを行います。フロントエンド開発者に、複雑なページをレンダリングするため多数の個別のリクエストを送信することを強制しないでください。不自然な制限で彼らを悩ませるのをやめましょう。連携しましょう。
私は、ここで問題となっている点についてマックスに完全に同意します。
特に、汎用APIは安定している必要があるのに対し、アプリケーションAPIはアプリケーションのニーズに対応するために迅速に変更する必要があるという事実を強調したいと思います。
ジャン＝ジャック・デュブレは、この記事で、API設計者の悲しい現状について次のように述べています。
最近、私の仕事の最悪の部分は、フロントエンド開発者向けのAPIを設計することです。会話は必然的に次のようになります。
開発者 - この画面にはデータ要素x、y、z…があります。レスポンス形式が{x: , y:, z: }のAPIを作成していただけますか？
私 - はい
これは、マックスが気づいた緊張を完全にカプセル化したものです。APIエンジニアは、一般的で安定したAPIを設計したいと考えていますが、多くの場合サーバー側で解決するのが最適な、複雑なデータニーズを持つ、急速に変化するUIの気まぐれに左右されます。
マックスが指摘するように
「ページa」は、必要なことだけを実行するように単純にすることができます。「ページa」のバグ、セキュリティ、パフォーマンスを徹底的にテストします。1つの大きなSQLクエリで「ページa」のすべてを取得することもできます。
繰り返しますが、データ/アプリAPIのインピーダンスミスマッチ問題があるという点で、私はマックスに完全に同意します。そして、GraphQLのようなソリューションに頼るのではなく、APIを2つに分割することを提案したことに対して、彼を称賛します。
ただし、次のステップがあります。
アプリケーションAPIを汎用データAPIから分離したら、パブリックデータAPIの制約に縛られることはなくなります。アプリケーションAPIの全体的な形式を再検討することができます。自由に何でもできるようになったので、少し大胆に考えてみましょう。
アプリケーションAPIの核となる問題は、急速な変化とページ（またはリソース）固有のチューニングであることに注意してください。まさにこの問題に対処するための非常に優れたテクノロジーがあります。ハイパーメディアです！
HATEOASによるハイパーメディアは、APIの変更をそれほど問題ではなくします。ハイパーメディアAPIの形状を変更しても、問題ありません。新しいAPIは、サーバーから返される新しいHTMLに פשוט משתקף です。エンドポイントを追加および変更でき、そして（最初の近似値までは）クライアント（つまりブラウザ）を更新する必要はありません。
ブラウザは単に新しいHTMLを表示し、それらを駆動する人間は新しい機能に適切に反応します。
そのため、マックスは正しい方向に進んでいると思いますが、十分に進んでいないとも思います。2つを別々の懸念事項に分離することでデータ/ APP APIインピーダンスミスマッチ問題を解決するという精神的な飛躍を遂げたら、ハイパーメディアの利点を再発見するのは、ほんの少し先のことです。
「ああ、でもハイパーメディアアプリケーションはあまり使い勝手が良いとは言えません。Web 1.0には戻りたくないのです。」と反論するかもしれません。
それは perfectly reasonable な反論ですが、人々はその問題に取り組んでおり、ハイパーメディアモデル内でHTMLの使いやすさの問題に対処する多くのライブラリが現在利用可能です。
私のお気に入りは、unpolyと、もちろん私自身のhtmxです。
ハイパーメディアアプリケーションAPIに切り替える場合（これは実際には「以前のようにHTMLを使用する」ことを意味します）、RESTful Webモデルのすべての利点（シンプルさ、信頼性など）と、成熟したWebフレームワークでのサーバーサイドレンダリングの利点（キャッシング、SQLチューニングなど）が得られます。
そして、htmxのようなハイパーメディア指向のフロントエンドテクノロジーを選択することで、そのモデル内で優れたユーザーエクスペリエンスを作成できます。
古いものはすべて再び新しくなりますが、今回は少し良くなっています。