周りを見渡すと、RESTful GUI Web アプリケーションはほとんどありません。これは歴史的な理由によるものですか、それとも RESTful な設計は一般的なシナリオでは非生産的ですか?
私の回答は主観的なものですが、RESTful な開発を妨げる 2 つの大きなハードルがあると思います。
- 変更 - 従来のサイトの設計方法とは大きく異なります
- 課題 - 純粋な RESTful サーバー API とそれに対応するリッチで堅牢なクライアント UI の設計は容易ではありません
多くの場合、複雑な GUI ではクライアントに JavaScript アプリケーションが必要になります。
私の意見では、複雑でリッチなクライアント サイド エクスペリエンスには、サーバー サイドの実装に関係なく、詳細な JavaScript が必要になります。
同じページにとどまり、パーツのみをリロードする必要があります。
これは、従来のリクエスト/レスポンスの全ページから全ページへの設計とは大きく異なる設計です。各設計には独自のトレードオフがあります。REST 設計は AJAX 呼び出しで特にうまく機能しますが、クライアント側のコードは、保守可能で堅牢な設計にする必要があります。
シッククライアントを備えた RESTful サーバー:
- スケーラビリティ: すべてのユーザーのセッション情報は、不十分なサーバー メモリに保存されません。
- ネットワークを介した要求/応答データの削減: すべてのページを完全に送信せず、セッション ID または
ViewStatesを送信しない
- クリーンな再利用可能な URL: 複数の UI をサポートできるクリーンで分離されたサーバー API を提供します。
- 純粋: HTTP 仕様への厳密な準拠 (GET は副作用を引き起こさないなど)
- クライアント エクスペリエンス: 非同期トランザクションにより、よりリッチで応答性が向上
ただし、前述のように、シッククライアントには欠点があります。
- XSS 攻撃に対してより脆弱であるため、RESTful URL には注意深いセキュリティが本当に必要です
- 複雑な JavaScript は、開発、保守、およびデバッグが難しい場合があります (OO JavaScript を使用すると、これを調整できます)
- 非同期リクエストがバックグラウンドで処理されていることをユーザーに示す必要がある
- クライアント側の障害処理ロジックがさらに必要
- フレームワークと IDE ツールは、サーバー側と比較して、クライアント側の開発には伝統的に弱いものでした (これは徐々に改善されています)。