| SOAP (Simple Object Access Protocol) |
- XMLベースのメッセージ交換- WSDLによる厳密なインターフェース定義- WS-Securityなどの高度なセキュリティ対応 |
- セキュリティやトランザクション制御が強力- 金融系や基幹システムのように高い信頼性が求められる場面に最適 |
- XMLベースのため、メッセージが冗長で通信量が多い- 開発が複雑で、柔軟性が低い |
- 金融機関や基幹システムなど、高い信頼性とセキュリティが求められる場合- レガシーシステムとの連携が必要な場合 |
1998年（2000年代に普及） |
| RESTful API |
- HTTPメソッド（GET, POST, PUT, DELETEなど）に準拠- URLベースでシンプルに設計可能- JSONやXMLなど柔軟なデータ形式対応 |
- 軽量で高速な通信が可能- Webサービスやモバイルアプリなど幅広い用途に対応 |
- APIの設計次第で冗長なリクエストが増える可能性がある- クライアント側でのデータ結合が必要になりがち |
- Webアプリケーションやモバイルアプリ向けのAPI- 軽量で高速なAPIが求められる場合 |
2000年頃（2010年代に主流に） |
| GraphQL |
- クライアントが必要なデータのみ取得可能- 1回のリクエストで複数のリソースを取得- 柔軟なデータ構造が扱える |
- オーバーフェッチやアンダーフェッチを防ぎ、最適なデータ取得が可能- UI開発者がデータの取得方法を柔軟に制御できる |
- キャッシュが難しいため、大規模なシステムでは負荷管理が課題になることがある- RESTに比べて実装の複雑度が上がる |
- フロントエンド主導の開発や、複雑なデータ構造の管理が必要な場合- モバイルアプリやSPA (Single Page Application) に最適 |
2015年（Facebookが開発） |
| gRPC (Google Remote Procedure Call) |
- Protocol Buffers (Protobuf) を使用したバイナリ通信- 高速なデータ転送とストリーミング対応- マイクロサービス間の通信に最適 |
- 通信が高速かつ軽量なデータ転送が可能- 双方向ストリーミングが容易に実装可能 |
- ブラウザ標準対応がないため、Webクライアント側での利用は制限がある- デバッグが難しい（データがバイナリ形式のため） |
- マイクロサービスアーキテクチャ- リアルタイム処理や大規模データ通信が必要な場合 |
2015年（Googleが開発） |
| WebSocket |
- 双方向通信が可能 (クライアント⇔サーバーのリアルタイム接続)- 状態を維持したまま通信が可能 |
- リアルタイム通信が高速かつ効率的- 常時接続が維持されるため、データ更新の即時反映が可能 |
- 接続管理が必要で、スケーリングの難易度が高い- クライアントが常時接続するため、負荷やセキュリティの考慮が重要 |
- チャットアプリ、ゲーム、金融系ダッシュボードなど、リアルタイム性が求められるシステム |
2008年（HTML5の一部として登場） |