それは可能ですが、現実の世界では、あなたが想像する素朴なアプローチよりも少し複雑です。主に、トリガーがHTTPリクエストを待機することは許容されません：
- 1つは、トリガーが遠く離れたWWWサービスからの応答を待機しているリソース（主にロック）をブロックするため、アプリケーションは急停止するまでクロールします。
- 第2に、より微妙ですがはるかに悪いのは、ロールバックが存在する場合の正確性の問題です。 HTTPリクエストに対して発行されたトランザクションがロールバックした場合、HTTPリクエストを「元に戻す」方法はありません。
解決策は、キューを介してトリガーをHTTPリクエストから切り離すことです。トリガーはリクエストをローカルキューにエンキューしてコミットし、別の処理でこれらのリクエストをデキューしてHTTPリクエストを発行します。これにより、上記の両方の問題が解決されます。キューに通常のテーブルを使用することも（テーブルをキューとして使用するを参照）、ServiceBrokerを使用することもできます。どちらも適切に機能します。
ここで、この要求をデキューして実際にHTTP呼び出しを行う方法について、専用のプロセス（つまり、この目的専用のアプリケーション）を使用することを強くお勧めします。 SQLCLRを使用することは可能ですが、それは非常に悪い選択です。 SQL Serverのリソース（特にワーカー）は、インターネットの応答を待つために無駄にすることは非常に貴重です。