REST vs SOAP vs GraphQL

REST vs SOAP vs GraphQL

Choosing an API style shapes how you design tests. Understanding the differences prevents you from applying the wrong testing strategy.

REST (Representational State Transfer)

REST is the dominant API style. Resources are identified by URLs; operations are expressed via HTTP verbs.

GET    /users/42         → retrieve user 42
POST   /users            → create a new user
PUT    /users/42         → replace user 42
PATCH  /users/42         → partially update user 42
DELETE /users/42         → delete user 42

Testing REST:

• Assert status codes are semantically correct (201 for create, 404 for not found)
• Validate response body schema
• Test authentication on every endpoint
• Test idempotency of PUT and DELETE

SOAP (Simple Object Access Protocol)

SOAP uses XML messages over HTTP POST. Common in enterprise and legacy banking/insurance systems.

<soap:Envelope>
  <soap:Body>
    <GetUserRequest>
      <UserId>42</UserId>
    </GetUserRequest>
  </soap:Body>
</soap:Envelope>

Testing SOAP:

• All requests are POST regardless of operation
• Status code is always 200; errors are in the SOAP Fault body
• Use SoapUI or Postman's SOAP support
• Validate against WSDL schema

GraphQL

GraphQL uses a single endpoint (/graphql) for all operations. Clients specify exactly what data they need.

query {
  user(id: 42) {
    name
    email
    orders { id totalAmount }
  }
}

Testing GraphQL:

• All requests are POST to /graphql
• Status is always 200 (even for errors — check the errors field in the response body)
• Test for over-fetching prevention (client requests only what it needs)
• Test introspection is disabled in production (security concern)
• Test N+1 query performance for nested resolvers

Key Testing Difference