SOAPless
無料で始める
ブログへ戻る
soaprest-apicomparisonweb-services

SOAP と REST API の違い: メリット・デメリットと適切な使い分け

SOAPless Team11 min read

「SOAP と REST、どちらを使うべきか?」は、API 設計やシステム連携において最も頻繁に議論されるテーマの1つです。しかし、どちらが優れているかという二項対立の議論はあまり意味がありません。SOAP と REST は解決する課題が異なり、実際の現場では両方を扱う場面が増えています。

この記事では、SOAP と REST の本質的な違いを掘り下げ、それぞれの強みと弱みを明確にし、ユースケースごとの最適な選択肢を提示します。

プロトコル vs アーキテクチャスタイル

最も根本的な違いは、SOAP が「プロトコル」であり、REST が「アーキテクチャスタイル」であるという点です。

SOAP (Simple Object Access Protocol) は厳密なメッセージ形式、通信規則、SOAP Fault によるエラーハンドリングを定義するプロトコルです。SOAP メッセージは常に以下の構造を持ちます:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:tns="http://example.com/orderservice">
  <soap:Header>
    <!-- WS-Security、WS-Addressing など -->
  </soap:Header>
  <soap:Body>
    <tns:GetOrder>
      <tns:orderId>12345</tns:orderId>
    </tns:GetOrder>
  </soap:Body>
</soap:Envelope>

REST (Representational State Transfer) は HTTP メソッドを動詞として、URL をリソース識別子として使用するアーキテクチャスタイルです。メッセージ形式に制約はありませんが、JSON が主流です:

curl -X GET https://api.example.com/orders/12345 \
  -H "Authorization: Bearer eyJhbGciOi..."

{
  "id": 12345,
  "customer": "Acme Corp",
  "status": "shipped",
  "total": 299.99
}

SOAP は厳格な構造と組み込み機能を提供し、REST は柔軟性とシンプルさを提供します。

メッセージ形式: XML vs JSON

項目SOAPREST
形式XML のみJSON、XML、テキスト、バイナリ
エンベロープ<soap:Envelope> が必須ラッパー不要
スキーマXSD (XML Schema Definition)JSON Schema (任意)
名前空間必須、複数存在することも多い不要
可読性冗長で読みにくいコンパクトで読みやすい
パースXML パーサー + 名前空間処理JSON.parse()

同等の注文情報を取得するレスポンスの場合、SOAP は XML タグ、名前空間、Envelope 構造により、JSON の 2-3倍のサイズになることが一般的です。

コントラクト定義: WSDL vs OpenAPI

SOAP サービスは WSDL (Web Services Description Language) ファイルで定義されます。WSDL にはすべての操作、入出力メッセージ、データ型、バインディング情報が記述されています:

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
                  xmlns:tns="http://example.com/orderservice"
                  targetNamespace="http://example.com/orderservice">

  <wsdl:types>
    <xsd:schema targetNamespace="http://example.com/orderservice">
      <xsd:element name="GetOrder">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="orderId" type="xsd:int"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
    </xsd:schema>
  </wsdl:types>

  <wsdl:message name="GetOrderRequest">
    <wsdl:part name="parameters" element="tns:GetOrder"/>
  </wsdl:message>

  <wsdl:portType name="OrderServicePortType">
    <wsdl:operation name="GetOrder">
      <wsdl:input message="tns:GetOrderRequest"/>
      <wsdl:output message="tns:GetOrderResponse"/>
    </wsdl:operation>
  </wsdl:portType>
</wsdl:definitions>

REST API は OpenAPI (旧 Swagger) 仕様で記述されます。YAML または JSON 形式で、エンドポイント、パラメータ、リクエスト/レスポンススキーマ、認証方式を定義します:

openapi: 3.0.3
paths:
  /orders/{orderId}:
    get:
      summary: 注文IDで注文を取得
      parameters:
        - name: orderId
          in: path
          required: true
          schema:
            type: integer
      responses:
        '200':
          description: 注文情報
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Order'

WSDL は機械可読なコントラクトとして自動コード生成を可能にします。OpenAPI も同様の役割を果たしますが、人間にとっての可読性と編集のしやすさでは優位です。

セキュリティ: WS-Security vs OAuth/JWT

セキュリティは SOAP が明確な優位性を持つ領域の1つです。

SOAP の WS-Security はメッセージレベルで動作します。セキュリティヘッダーが SOAP Envelope 内に埋め込まれるため、中間ノードを経由してもメッセージのセキュリティが保たれます:

<soap:Header>
  <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <wsse:UsernameToken>
      <wsse:Username>apiuser</wsse:Username>
      <wsse:Password Type="...#PasswordDigest">dGVzdA==</wsse:Password>
      <wsse:Nonce>abc123</wsse:Nonce>
      <wsu:Created>2025-08-10T10:00:00Z</wsu:Created>
    </wsse:UsernameToken>
  </wsse:Security>
</soap:Header>

金融機関や官公庁のシステムでは、メッセージが複数の中間ノードを通過するため、メッセージレベルの暗号化やデジタル署名が不可欠です。

REST のセキュリティ はトランスポートレベルのセキュリティ (TLS) とトークンベース認証に依存します:

# OAuth 2.0 Bearer トークン
curl -X GET https://api.example.com/orders/12345 \
  -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."

# API キー
curl -X GET https://api.example.com/orders/12345 \
  -H "X-API-Key: sk_live_abc123..."
セキュリティ機能SOAP (WS-Security)REST
暗号化メッセージレベル (フィールド単位)トランスポートレベル (TLS)
デジタル署名組み込みサポート標準なし
認証WS-Security、SAMLOAuth 2.0、JWT、API キー
否認防止サポートカスタム実装が必要
中間ノード安全性メッセージは暗号化されたままTLS 終端で復号される

トランスポートプロトコル

SOAP は HTTP、SMTP、TCP、JMS など、XML を運べるあらゆるトランスポート上で動作可能です。実務上はほとんどが HTTP ですが、エンタープライズのメッセージキュー環境ではプロトコル非依存性が活きる場面もあります。

REST は本質的に HTTP に結びついています。HTTP メソッド (GET、POST、PUT、DELETE、PATCH) をセマンティックな動詞として活用し、HTTP ステータスコードでエラーを通知します。

エラーハンドリング

SOAP は SOAP Fault という定義済みスキーマの構造化エラーレスポンスを使用します:

<soap:Fault>
  <faultcode>soap:Client</faultcode>
  <faultstring>注文IDの形式が不正です</faultstring>
  <detail>
    <tns:ValidationError>
      <tns:field>orderId</tns:field>
      <tns:message>正の整数を指定してください</tns:message>
    </tns:ValidationError>
  </detail>
</soap:Fault>

REST は HTTP ステータスコード とレスポンスボディの組み合わせでエラーを伝えます:

{
  "error": {
    "type": "validation_error",
    "code": "INVALID_ORDER_ID",
    "message": "注文IDは正の整数である必要があります",
    "detail": {
      "field": "orderId",
      "value": "abc"
    }
  }
}

Web 開発者にとっては REST のエラーハンドリングの方が直感的ですが、SOAP Fault はツールが自動的にパースできる標準化された構造を提供します。

パフォーマンス比較

指標SOAPREST (JSON)
ペイロードサイズ大きい (XML + Envelope)小さい (JSON)
パース速度遅い (XML DOM/SAX)速い (JSON.parse)
キャッシュ困難 (POST ベース)HTTP キャッシュ対応 (GET)
帯域幅大きい小さい
ステートレス性強制なしアーキテクチャ上の制約

JSON を使った REST API は、同等の SOAP 呼び出しと比較して 30-50% の帯域幅削減と高速なパースを実現します。SOAP レスポンスはほとんどが POST を使うためキャッシュが難しく、読み取り中心のワークロードでは大きなパフォーマンス上の不利になります。

SOAP を選ぶべきケース

以下のような要件がある場合、SOAP が適切な選択です:

  • エンタープライズコンプライアンス が WS-Security、メッセージレベル暗号化、SAML トークンを要求する場合 (銀行、保険、医療)
  • ACID トランザクション が分散システム間で必要な場合 (WS-AtomicTransaction、WS-ReliableMessaging)
  • 厳密なコントラクト が必須の場合 — WSDL は法的拘束力のある API 仕様として機能する
  • レガシー連携 — 接続先のサービスが SOAP のみを公開しており、変更できない場合
  • 官公庁・公共セクター のシステムが SOAP/WSDL を相互運用性の標準として義務付けている場合

日本では特に、全銀システム、e-Gov API、各自治体の基幹システム連携で SOAP が広く使われています。

REST を選ぶべきケース

以下のような要件がある場合、REST が適切です:

  • モバイル・Web クライアント が軽量で高速なレスポンスを必要とする場合
  • 公開 API としてサードパーティ開発者に使いやすさを提供したい場合
  • マイクロサービス 間の内部通信でオーバーヘッドを最小限にしたい場合
  • 読み取り中心のワークロード で HTTP キャッシュの恩恵を受けたい場合
  • 高速な開発 を重視し、シンプルさと短い開発サイクルを求める場合

「両方使う」パターン: SOAP と REST の橋渡し

現実には、多くの組織がハイブリッドなシナリオに直面しています。基幹業務システムは SOAP サービスを公開していますが、フロントエンドチーム、モバイルアプリ、パートナー連携は REST/JSON を必要としています。

このギャップを埋めるアプローチは主に 3 つあります:

1. 手動の変換レイヤー — 各オペレーションについて JSON と XML の変換コードを手書きする方法。動作はしますが、オペレーション数に比例してメンテナンスコストが増大します。

2. API Gateway の SOAP-to-REST 変換 — MuleSoft や IBM API Connect などのエンタープライズゲートウェイによるプロトコル仲介。強力ですが高価で設定が複雑です。

3. 専用の SOAP-to-REST プロキシ — WSDL を読み込み、オペレーションを理解して、自動的に REST エンドポイントとして公開する軽量サービス。

SOAPless による解決

SOAPless は 3 番目のアプローチを自動化します。WSDL URL を貼り付けるだけで、サービスに定義されたすべてのオペレーションに対応する REST JSON エンドポイントが自動生成されます。XML エンベロープの構築、名前空間の管理、レスポンスのパースはすべて自動で処理されます。

フロントエンドやモバイルチームはシンプルな REST API を呼び出すだけです:

curl -X POST https://api.soapless.com/v1/your-service/GetOrder \
  -H "X-API-Key: your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"orderId": 12345}'

SOAPless がこのリクエストを適切な SOAP エンベロープに変換し、上流サービスに送信し、XML レスポンスをパースして JSON を返します。認証情報は AES-256-GCM で暗号化して管理され、REST 側のコンシューマー向けに OpenAPI 3.0 仕様も自動生成されます。

バックエンドでは SOAP の信頼性とコンプライアンスを維持しつつ、フロントエンドでは REST のシンプルさを享受できます。XML パースコードのメンテナンス、名前空間のデバッグ、手動でのエンベロープ構築は不要になります。

ブログへ戻る