Django - REST APIのみを使用したプロジェクトアプリの接続

Question

主に2つの質問があります。私はこれをどこでも読んでいませんが、あなたのプロジェクトのすべてのアプリケーションに出入りするすべてのデータがREST API呼び出しに依存するようにすることをお勧めしますか？

たとえば、新しいユーザーを登録したい場合などです。フロントエンドからバックエンドの作業なしでデータを収集し、このデータをREST呼び出しとして、すべての検証とバックエンドの作業が行われる「登録アプリ」に送信します。

この方法は、依存関係をより一層解消し、プロジェクトの各部分をより分離して「クリア」するだけでなく、大きなチームで作業するときに効果的です。したがって、私の疑問は、これが実行可能な開発方法ですか？これにセキュリティやパフォーマンスの問題はありますか？そして、どこでもっと読むことができますか？

おかげ

マックス

Answer 1

それは、私はそれが長所と短所を持っているほとんどの選択肢のように考え、完全に実行可能です。ここではそれらのいくつかは以下のとおりです。

長所：

• デカップリング - あなたがデザインの明快さを得るためクライアントは、（つまり、REST API）の抽象化に依存ではなく、結石（すなわちウェブサイト）、能力へブラウザの外部でテストし、REST APIの代わりにさまざまな実装（例：開発/テストの目的で模擬サービスを提供しています。さらに、REST APIが別のバックエンド・サービスによって実装されている場合は、それを個別に更新して、独立して拡張することができます。
• レスポンシブなユーザーインターフェイス - REST要求により、HTMLページの再読み込みが回避され、UXが改善されます。また、非同期REST呼び出しを行うこともできます。
• ペイロードの削減 - 通常、REST呼び出しは、ページの更新時に送信されるHTMLよりも少ないデータを返します。

短所：

• より複雑なクライアント - あなたは非同期のREST呼び出しを採用するので、もしあなたが、特にJavaScriptとより複雑な必要があります。
• ダイナミックページビルド - 通常、REST呼び出しの結果はUIに何らかの変更が必要な場合があります。これはjavascriptで動的に行う必要があり、複雑化も加わります。したがって、あなたのUIロジックはHTMLページテンプレートとjavascript UIアップデートに分割されます。これにより、UIが推論するのが難しくなります。
• タイムアウト - JavaScriptでタイムアウトとエラーを処理する必要があります。
• セッション - ユーザーの認証とセッションの維持の手段が必要です。 RESTサービスはクライアント・セッション状態を維持するべきではないため、クライアントに状態を格納するか、独自の別個のURIを持つ新しいRESTリソースとして明示的に状態を追加する必要があります。
• 強制ページリロード - このメカニズムを使用してページのリロードを回避すると、ユーザーはページをかなりの期間開いている可能性があり、ページをリロードするために何らかのメカニズムが必要な場合があります。