完全にAPIベースのWebサイト-それは良いアイデアですか？

Question

Webサイトを完全にAPIベースにすることについて耳にすることがあります。つまり、ブラウザーでさえ、ページはAPIエンドポイントに基づいて構築され、他には何もありません。

これで私が目にする利点の1つは、スマートフォンアプリケーションを作成するときに、動作してテスト済みのAPIがすでにあることです。また、何かを変更する必要がある場合は、デスクトップとモバイルアプリを実質的に同時に変更できます（多少の調整が必要です）。

多分私はどういうわけか考えを誤解しましたが、私はそれの全体的な実行可能性についていくつか質問があります。残念ながら、私はこのトピックに関する良い記事を見つけることができませんでした（これは奇妙です、おそらくこれは人々が行うことではなく、私がそれを完全に誤解しているためです）。

たとえば、範囲を明確にするために、ソーシャルネットワーク風のサイトを構築しているとしましょう。

モバイル開発の場合、APIがデフォルトの方法ですが、デスクトップの場合、私にはやりすぎのようです。私はDjango=フレームワークに慣れており、ページレンダリングを非常に簡単に行うことができます。ブラウザはGETまたはPOSTパラメータ付きのリクエストを送信し、応答ページをレンダリングします。デスクトップブラウザーでAPIを使用する場合は、単純なリクエストの代わりに、JSONを作成してAPIエンドポイントに送信し、デシリアライズしてから応答をレンダリングする必要があります。通常の方法とは異なり、非常に複雑なコードを生成できます1つのステップでの応答-APIエンドポイントでは、多くのコンテンツを含むデスクトップWebページを生成するために実際に複数のエンドポイントを使用する必要がある場合があります。つまり、最終的に複数のAPIリクエストを送信することになります。したがって、サイトのデスクトップバージョンのすべてにAPIを使用して、数を増やしますサーバーへのリクエストの数と必要なコードの量です。はい、モバイルアプリの開発にかかる時間を節約しますが、帯域幅の増加と堅牢性の低下を犠牲にしており、これは私の意見では問題です。誰かが説明できればいいのに.
どこでもAPIエンドポイントに依存するデスクトップバージョンを実行することは本当に意味がありますか？私は時々それについて話しているのを見たことがありますが、それについての例や大きな記事を見たことがありません。これはおそらくこれが愚かな考えであり、私がそれについて考えることにも時間を費やしていることを示唆しています。誰もがすべての小さなものがAPIエンドポイントに関連付けられている大きなデスクトップWebサイトを本当に作っていますか？私はあまり経験がないかもしれませんが、それがわかっている限り、通常は小さなAPI呼び出しが役に立ちますが、構造全体がAPIに依存しているわけではありません（モバイルアプリとは異なります）。それで、私は通常の開発に固執し、モバイルアプリにほぼ独占的にAPIを残す必要がありますか？

Ewan · Accepted Answer

「シングルページアプリ」について話しているようです

この用語は、実行するアクションのすべてまたはほとんどがクライアント側のjavascript AJAX呼び出しを介して実行され、jsonを取得し、そのjsonをHTMLとページの更新

のではなく：

ブラウザーに新しいhtmlページを要求させ、それがブラウザーによって返されて表示され、古いページが破棄されます。

このアプローチにはマイナス面もあると思いますが、これは現在、Webサイトデザインの事実上の標準アーキテクチャです。単純な理由は、AJAXがページのロードよりも明らかに優れたユーザーエクスペリエンスを提供することです。

このアプローチを実装しやすくするために、reactやangularなどのJavaScriptフレームワークがいくつか利用できます。

したがって、ほとんどの「単一ページアプリ」は[〜＃〜] not [〜＃〜]すべてが1つのページで実行されます。管理ページ、設定などは、私の経験では通常、分割されており、実質的には別の「単一ページアプリ」になっています。つまり、angularまたは何でも使用するAdmin.htmlがあり、ページ内機能を実行する一連のAPIがあります。

これにより、懸念事項を簡単に分離して、単一ページのアプリが認証で発生する傾向があるいくつかの問題に対処することが容易になります。

サイトのこれらのセクション間の変更は頻繁に行われるものではなく、ページ全体が変更される「大きなステップ」と見なされるため、ユーザーエクスペリエンスは実際には影響を受けません。

ただし、このアプローチが適切な場合は慎重に検討する必要があります。一部のフォームを標準のhttp経由で送信し、一部のフォームをjsフレームワーク経由で送信しても、何のメリットもないように思えます。フレームワークを使用している場合は、それに固執してすべてに使用してください。古いskool htmlを実行している場合は、それに固執してください。両方のアプローチを組み合わせると、単に両方の欠点が得られることになります。

Joeri Sebrechts · Answer

システムにアクセスするあらゆる方法の背後で共有APIを使用することは理にかなっています。このAPIの背後では、エンティティの種類やデータベースからのエンティティのロード方法、ユーザーの認証と承認の処理方法など、繰り返し発生する問題に対処できます。モバイルとデスクトップのような2つの異なるクライアントの違いを、コードの重複なしに実際の違いに限定することを目指してください。

ただし、これは、すべてのフロントエンドでWebサービスを再利用する必要があるという意味ではありません。ここにはいくつかのオプションがあります：

クラスのセットである共有APIは、Webサービスと（サーバー側の）Webページに1回ずつラップされます。
WebサービスをAPIとして使用しますが、サーバー内から呼び出してサーバー側のWebページをレンダリングします
WebサービスをAPIとして使用し、クライアントから呼び出します。

あなたの質問に戻ります：

どこでもAPIエンドポイントに依存するデスクトップバージョンを実行することは本当に意味がありますか？

はい、デスクトップバージョンをモバイルバージョンと同じAPIに依存させることは理にかなっています。いいえ、Webサービスエンドポイントの形式である必要はありません。

これらの選択について詳しく説明すると、 backends-for-frontendsパターンに興味があるかもしれません。