ライブラリの代わりにサービス（REST / SOAP）を使用する理由

Question

アプリケーションをサービスに分割しようとしているとしましょう。 SOAアプローチを採用する場合と、それを必要とするアプリケーションがロードできるライブラリAPIを単に作成する場合とでは、何らかの理由がありますか？.

Arseni Mourzenko · Answer

両者の違いは微妙かもしれません。たとえば、.NETの世界では、エンドユーザーにとってモノリシックのように感じられ、同じマシンで動作するが、内部ではWCFサービスの束に分離されるアプリケーションがある場合があります。また、ライブラリが強くリンクされていない（アドイン/プラグイン）アーキテクチャがあり、互いに通信するときにプロトコルに従うだけの場合もあります。

これらの中間的なケースについて話し合うのを避け、強力にリンクされたAPIライブラリと個別のRESTサービスのみを扱う場合は、次の点を検討することをお勧めします。

ライブラリAPIは同じマシンで呼び出されます。サービスはどこでもホストでき、どこからでも呼び出すことができます。パフォーマンス/スケーラビリティ/セキュリティ上の理由から、複数のマシンでのアプリケーションのホスティングをカウントしている場合は、サービスを使用する必要がある可能性があります。
複数のマシンにデプロイされたアプリケーションが1つのサービスを使用する場合も同様です。たとえば、銀行のアプリケーションで財務計算を行う場合、1つの方法は、大規模なアプリケーション全体をすべてのデスクトップに展開し、毎回すべてのクライアントに大規模な更新を強制することです。別のアプローチは、サーバー上で計算部分をホストし、UIとそれらのサーバーへの多数の呼び出しのみを備えた軽量アプリのみをデスクトップにデプロイすることです。
RESTサービスをホストしている場合、Macユーザー、Linuxを使用しているユーザーなど、誰でもそれを使用できます。VisualStudioでC＃ライブラリを作成して配布した場合DLLとして、Windowsを持っていないユーザー（顧客？）を忘れます。

Mike O&#39;Connor · Answer

サービスのもう1つの利点は、サービスを更新すると、サービスのすべてのコンシューマーにすぐに展開されることです。そのため、バグやパフォーマンスの問題を修正した場合、更新されたサービスが公開されるとすぐに全員がメリットを享受できます。無視する更新を配布する必要はありません。

Cory House · Answer

ライブラリの利点：

呼び出しあたりのオーバーヘッドが少ない（ジャンプのみ、またはインライン化）=パフォーマンスが向上する可能性があります
おそらく機能する最も単純なもの
一元化されたサービスがダウンしてすべての消費者に影響を与えるリスクがない

サービスの利点：

誰もがすぐに透過的にアップグレードを取得（バージョン管理されたAPIが提供されない限り）
消費者はコードを逆コンパイルできません
サービスハードウェアを個別に拡張できます
テクノロジーにとらわれない。共有ライブラリーでは、消費者は互換性のあるテクノロジーを利用する必要があります。
より安全に。 UI層は、DBに直接アクセスする代わりに、ファイアウォールの背後にあるサービスを呼び出すことができます。

jiggy · Answer

SOAアプローチでは、さまざまなサービスを個別にホストおよび保守できます。コードに加えて、特定のサービスをデプロイするには、多くの特別な構成（パスワード、ポート、証明書など）が必要になる場合があります）。 a RESTサービスは、明確に文書化して簡単に理解できる有限の複雑さを持っています。また、クライアントにDBまたは他のリソースへのアクセスを許可する必要がないことを意味するため、より安全です。

Paul T Davies · Answer

SOAサービスに変更がある場合、そのSOAサービスは再開発、再テスト、および再デプロイする必要があります。そのサービスを使用するすべてのアプリケーションは続行できますDLL内のライブラリへの変更は、そのDLLを参照するためにそのライブラリのすべてのコンシューマを再開発する必要があることを意味します。それらはすべて再テストする必要があり、すべてがこれは正しく展開されない可能性があり、アプリケーションによってDLLのバージョンが異なる可能性があります。これは問題にならない場合があります-おそらくすべてのシステムに、展開時に存在していたライブラリのバージョンが必要です。（ロギングシステムを更新して便利な新機能を追加した可能性があります-本当にすべてのシステムを更新する必要がありますか？）この場合、ライブラリは問題ありません。ただし、税を計算するサービスがあるとします率と税法が変更されます。この変更を組み込むためにすべてのシステムを更新する必要はありません。一箇所でそれを行うには。この場合、サービスの方が適しています。

aagaard · Answer

いくつかの良い答えがありますが、私は与えられた答えにさらに多くのものを追加したいと思います：

APIライブラリメソッドは、オーバーヘッドをできるだけ少なくしてやり取りしたい場合に非常に役立ちます。その結果、APIとそれを使用するアプリケーションの間には、より高い結合があります。場合によっては、これはアプリケーションにとって問題なく、必要な場合さえありますが、非常に分散されたシステムがある場合、または相互運用性が大きな問題であると考える場合、抽象化を1つ上に進め、他の通信方法を使用する必要があります。特に、分散システムが必要な場合、SOAPはSOAの次のステップのようなものですが、ユニットを相互に認識する必要があるため、ユニット間の依存関係は残ります。手順RESTは、マシンが他のサービスのコンテンツについて何かを統一された方法で学習できるようにすることで、それを新しいレベルに引き上げます。

あなたの場合、アプリケーションが配布されていなければ、アプリケーションをSOAに変換する理由は何もありません。