9

確立された WCF SOAP サービスがあります。そのインターフェースは WSDL で定義され、そこからサーバー用の C# クラスが生成されます (顧客は、同じ WSDL からさまざまな言語でクライアント側バインディングを生成します)。WSDL には、少し変更できる現在のバージョンと、非推奨期間や協議などなしに変更または削除できない古いバージョンがあります。SOAP リクエストは複雑になる傾向があり、同じリクエスト内に複数の XML 名前空間があります。 .

WCF SOAP サービスには多くの "スマート" 機能があり、作成する必要がある新しい Web アプリケーションに必要なフェッチ機能とレポート機能を正確に提供します。そのクライアント側には AngularJS を使用したいと考えています。しかし、これらの複雑な SOAP リクエストは、JavaScript の世界では簡単には作成できません。REST サービスさえあれば、angular Resource サービスを使用できます。そうでない場合、JSON を話すサーバーは、SOAP のような RPC スタイルではありますが、かなり僅差で実行されます。

サーバーとクライアントの間のインピーダンスの不一致を軽減する方法について、さまざまなアイデアがありました。しかし、速くて簡単に聞こえるものは何もありません。

私は考えました： -

  1. 新しい REST サービスを作成します。まさにクライアント側が望んでいるものですが、新しい開発の深刻な部分です。
  2. WebHttpBinding は何かを提供しているように見えます。しかし、カスタム属性の C# マークアップ (C# が WSDL から生成されたときに達成する方法) が必要であり、複雑な型をサポートしない可能性があるようです。
  3. SOAP サービスの呼び出しを抽象化するために、クライアント側の JS の負荷を取得または書き込みます。ただし、これが WSDL から自動生成されない限り、クライアント側で膨大な量のコードを記述する必要があります。
  4. サーバー用の IDispatchMessageFormatter を作成して、私が考案した JSON 形式のメッセージを受け入れます。特に IDispatchMessageFormatter を実装および統合する人々の良い例を見つけるのは難しいように思われるため、難しいように思えます。
  5. JSON と XML を交換する MessageEncoder を記述します。しかし、これは実際にはエンコード操作ではありません。これを書き込もうとしたときに非常に明確になりました!

提案を探しています。

4

1 に答える 1

8

一般に、AngularJS の開発には REST サービスをお勧めします。また、多くのレガシー システムを Node.js API サーバーでラップしています。もちろん、大量の「場合による」ものがありますが、一般的に、ほとんどのプロジェクトは、そのルートに従うと、より幸せで生産性が高くなります。

考えるべきこと

  1. 現在の SOAP API は、ユーザー インターフェイスの要件にどの程度適合していますか?
  2. Express、Sinatra、Flask、または REST API の迅速な開発を可能にするその他のマイクロ フレームワークの経験はありますか? 堅実な Node.js Express API サーバーを数時間で構築し、AngularJS アプリケーションを構築する際にそれを拡張できることがわかりました。
  3. AngularJS の経験はどれくらいありますか? クライアント側で複雑なデータ層を構築するのは、より高度なプロジェクトです。

AngularJS にとって REST が重要な 6 つの理由

  1. $resource と $http を使用して Angular コードを記述する方がはるかに高速です。Get the API right は、効果的な AngularJS 開発のための良い推奨事項です。実際、AngularJS は REST 用に設計されていると主張することもできます。そのため、プレーンな JavaScript がモデルで機能します (2 を参照)。
  2. Angular の昔ながらの JavaScript オブジェクト データ モデルは、ユーザー インターフェイスと一致する JSON を話す REST API とうまく連携します。ただし、うまく適合しないと問題が発生します。Angular には正式なデータ モデルがないため、API を合理化して Angular でうまく動作させるために大量のコードを作成することになります。Breeze.js のようなサードパーティのライブラリが解決策を提供してくれるかもしれませんが、それでも扱いにくいです。
  3. キャッシングで簡単にスケーリングできます。Redis、memcache、Varnish、またはその他の一般的な HTTP キャッシング ソリューションをミックスに簡単に追加できます。リソースベースの抽象化は、REST API の透過性と冪等性により、キャッシュ戦略に最適です。
  4. フロントエンドとサーバーの疎結合 - SOAP から移行する場合、または他のサービスと統合する必要がある場合、バックエンドへの変更をサポートしやすくなります。
  5. 一般に、AngularJS ロジックとは別に JSON API をテストする方が簡単なので、テスト スイートはよりシンプルで効果的になります。
  6. 新しい REST API は、将来の AngularJS および JSON 指向のプロジェクトで活用しやすくなります。

それが役立つことを願っています。

乾杯、ニック

于 2013-07-16T19:44:35.067 に答える