回答:
両者の違いは微妙かもしれません。たとえば、.NETの世界では、エンドユーザーにはモノリシックのように感じられ、同じマシンで動作するが、内部では多数のWCFサービスに分離されるアプリケーションがあります。また、ライブラリが強くリンクされていない（アドイン/プラグイン）アーキテクチャがあり、互いに通信するときにプロトコルに従っている場合があります。
これらの中間的なケースについて話すのを避け、強くリンクされたAPIライブラリと個別のRESTサービスのみを扱う場合は、次の点を考慮することをお勧めします。
ライブラリAPIは、同じマシンで呼び出されます。サービスはどこでもホストでき、どこからでも呼び出すことができます。パフォーマンス/スケーラビリティ/セキュリティ上の理由で、複数のマシンでアプリケーションをホストしている場合は、サービスを使用する必要がある可能性があります。
複数のマシンにデプロイされたアプリケーションが1つのサービスを使用する場合の状況は似ています。たとえば、金融計算を行う銀行のアプリケーションを実行している場合、1つの方法は、すべてのデスクトップに大規模なアプリケーション全体を展開し、毎回すべてのクライアントに大規模な更新を強制することです。別のアプローチは、サーバー上で計算部分をホストし、UIとそれらのサーバーへの呼び出しだけを備えた軽量アプリのみをデスクトップに展開することです。
RESTサービスをホストしている場合、だれでも使用できます。Macユーザー、Linuxを使用しているユーザーなどです。VisualStudioでC＃ライブラリを作成し、DLLとして配布する場合は、ユーザー（顧客？）Windowsを持っていない人。
サービスのもう1つの利点は、サービスを更新すると、サービスのすべてのコンシューマにすぐに展開されることです。そのため、バグやパフォーマンスの問題を修正した場合、ユーザーが無視することを選択する可能性のある更新を配布する代わりに、更新されたサービスが公開されるとすぐに全員が利益を得ます。
ライブラリの利点：
サービスの利点：
SOAサービスに変更がある場合、そのSOAサービスを再開発、再テスト、および再デプロイする必要があります。そのサービスを使用するすべてのアプリケーションは、引き続き使用できます。DLL内のライブラリを変更すると、そのライブラリのすべてのコンシューマを再参照してそのDLLを参照する必要があり、それらをすべて再テストし、すべて再デプロイする必要があります。また、これが適切に行われない可能性があり、アプリケーションごとにDLLのバージョンが異なる可能性があります。時々これは問題ではないかもしれません-おそらくすべてのシステムは展開時に存在したライブラリのバージョンを持っているべきです（有用な新機能を持つようにロギングシステムを更新したかもしれませんすべてのシステムを更新する必要がありますか？）この場合、ライブラリは問題ありません。しかし、税率を計算するためのサービスがあり、税法が変更されたとしましょう。この変更を組み込むためにすべてのシステムを更新する必要はありません。1か所で行う方が良いでしょう。この場合、サービスがより良いオプションです。
いくつかの良い答えがありますが、与えられた答えにさらに多くのものを追加したいと思います。
APIライブラリメソッドは、できるだけ少ないオーバーヘッドで物事とやり取りする場合に非常に便利です。その結果、APIとそれを使用するアプリケーションとの間のカップリングが高くなります。時には、これはアプリケーションにとっても大丈夫であり、必要でさえありますが、非常に分散したシステムがある場合、または相互運用性が大きな問題であると考えられる場合は、後者を抽象化し、他の通信方法を使用する必要があります。特に、分散システムが必要な場合、SOAPはSOAの次のステップの1つですが、ユニットは互いの手順を知る必要があるため、ユニット間の依存関係が残ります。マシンが他のサービスのコンテンツについて何かを統一された方法で学習できるようにすることで、RESTはそれを新しいレベルに引き上げます。
あなたの場合、アプリケーションが配布されていなければ、アプリケーションをSOAに変換する理由はわかりません。