REST vs SOAP vs GraphQL: Differences Every Tester Should Know

“What is the difference between REST and SOAP?” has been asked in almost every API testing interview for over a decade, and GraphQL is now added to it. In this lesson you will see one real requirement, “get the balance and last two transactions of a bank customer”, built three ways, so the differences become obvious instead of memorised. Then you will learn how your test cases change for each style.

One Requirement, Three APIs

The mobile banking app needs: customer name, account balance and the last 2 transactions. Let’s see how each API style delivers it.

REST: several resource URLs

GET /v1/customers/42
GET /v1/accounts/ACC-4521
GET /v1/accounts/ACC-4521/transactions?limit=2

{ "data": { "id": "ACC-4521", "type": "savings", "balance": 18400.50,
            "currency": "INR", "branch": "Pune Camp", "ifsc": "SQAT0000123",
            "opened_on": "2019-06-11", "nominee": "...", "...": "many more fields" } }

Three round trips, and the account call returns many fields the screen never shows (over-fetching). Getting both pieces of data with one call isn’t possible (under-fetching), unless the team builds a custom endpoint.

SOAP: one operation, XML envelope

POST /CoreBankingService HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "GetAccountSummary"

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:cb="http://bank.example.com/core">
  <soapenv:Header><wsse:Security>...signed token...</wsse:Security></soapenv:Header>
  <soapenv:Body>
    <cb:GetAccountSummary>
      <cb:CustomerId>42</cb:CustomerId>
      <cb:TxnCount>2</cb:TxnCount>
    </cb:GetAccountSummary>
  </soapenv:Body>
</soapenv:Envelope>

Always POST, always XML, operation defined in the WSDL. Verbose, but every field, type and error is strictly defined.

GraphQL: one query, exact fields

POST /graphql
{
  customer(id: 42) {
    name
    account { balance currency }
    transactions(last: 2) { date amount description }
  }
}

One request, and the response contains exactly those fields and nothing else.

REST vs SOAP vs GraphQL: Comparison Table

REST in Detail (with a Live Example)

REST follows six constraints: client-server, stateless, cacheable, uniform interface, layered system and (optional) code on demand. For testers the important ideas are: resources as URLs, methods as actions and status codes as results.

Request the same user in JSON (default) and, with content negotiation, in XML. REST lets one resource have several representations:

curl -i \
  -H "Accept: application/xml" \
  "https://sqatools.in/wp-json/sqa-api/v1/users/1"

Change the Accept header to text/csv and the API replies 406 Not Acceptable, a great negative test.

SOAP in Detail

A SOAP message has four parts:

• Envelope (mandatory): root element that marks the XML as a SOAP message.
• Header (optional): security tokens, transaction ids, routing.
• Body (mandatory): the operation and its parameters, or the response.
• Fault (inside Body, on errors): faultcode, faultstring and detail.

<soap:Body>
  <soap:Fault>
    <faultcode>soap:Client</faultcode>
    <faultstring>Invalid account number</faultstring>
    <detail><cb:ErrorCode>ACC-404</cb:ErrorCode></detail>
  </soap:Fault>
</soap:Body>

You will test SOAP hands-on in the SoapUI lessons of Module 4.

GraphQL in Detail

GraphQL has three operation types:

• Query: read data.
• Mutation: create, update or delete data.
• Subscription: real-time updates, usually over WebSocket.

// Partial success: HTTP 200, but one field failed
{
  "data": { "customer": { "name": "Asha Verma", "transactions": null } },
  "errors": [
    { "message": "Not authorised to view transactions", "path": ["customer", "transactions"] }
  ]
}

This is the biggest trap for testers coming from REST: a 200 does not mean success. Always assert that errors is absent (or contains what you expect).

How Test Cases Differ for Each Style

Playwright Example: Testing REST and GraphQL the Same Way

Playwright’s request fixture can call any HTTP API, so the same framework covers REST, GraphQL and even SOAP (as a POST with an XML body).

import { test, expect } from '@playwright/test';

test('REST: content negotiation returns XML', async ({ request }) => {
  const res = await request.get('https://sqatools.in/wp-json/sqa-api/v1/users/1', {
    headers: { Accept: 'application/xml' },
  });
  expect(res.status()).toBe(200);
  expect(res.headers()['content-type']).toContain('application/xml');
  expect(await res.text()).toContain('<name>Asha Verma</name>');
});

test('GraphQL: assert data AND errors', async ({ request }) => {
  const res = await request.post('https://example.com/graphql', {
    data: { query: '{ user(id: 1) { name email } }' },
  });
  expect(res.status()).toBe(200);
  const body = await res.json();
  expect(body.errors).toBeUndefined();          // the important GraphQL check
  expect(body.data.user.name).toBe('Asha Verma');
});

test('SOAP: post an XML envelope', async ({ request }) => {
  const envelope = `<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
      xmlns:tem="http://tempuri.org/"><soapenv:Body>
      <tem:Add><tem:intA>5</tem:intA><tem:intB>7</tem:intB></tem:Add>
    </soapenv:Body></soapenv:Envelope>`;
  const res = await request.post('http://www.dneonline.com/calculator.asmx', {
    headers: { 'Content-Type': 'text/xml; charset=utf-8', SOAPAction: '"http://tempuri.org/Add"' },
    data: envelope,
  });
  expect(res.status()).toBe(200);
  expect(await res.text()).toContain('<AddResult>12</AddResult>');
});

The GraphQL URL above is a placeholder; replace it with your project’s endpoint. The SOAP calculator is a free public demo service.

When to Choose Which (Decision Guide)

• Choose REST for public APIs, CRUD-style apps, mobile backends and anything that benefits from HTTP caching.
• Choose SOAP when a partner or regulator requires it, or you need WS-Security signing and distributed transactions.
• Choose GraphQL when many different clients (web, Android, iOS, smart TV) need different shapes of the same data and you want to avoid many custom endpoints.

Common Myths

• “REST always uses JSON.” No, REST can return XML, CSV or anything; the practice API returns XML when asked.
• “SOAP is dead.” No, it still runs core systems in banking, insurance, airlines and government.
• “GraphQL replaces REST.” Most companies run both; GraphQL often sits in front of REST services.
• “SOAP only works over HTTP.” It can also use SMTP, JMS and other transports.

Interview Questions: REST vs SOAP vs GraphQL