Types of APIs: REST, SOAP, GraphQL, gRPC, WebSocket and Webhooks

“Which types of APIs have you tested?” is one of the most common API testing interview questions, and a weak answer instantly shows a lack of real experience. In this lesson you will learn both ways to classify APIs (by who can use them and by how they are built), see a real product that uses each type, and learn what a tester must check differently for each one.

Classification 1: Types of APIs by Access

1. Open APIs (Public APIs)

Available to any developer, sometimes with a free API key. They usually have strict rate limits.

What to test: rate limiting (429 Too Many Requests), API key validation, clear documentation matches behaviour, backward compatibility between versions, and behaviour under abuse such as huge page sizes.

2. Partner APIs

Shared only with business partners under a contract. Access is given after onboarding, often with stronger authentication (OAuth 2.0 client credentials, mutual TLS, IP allow-listing).

What to test: contract (field names, formats) exactly as agreed, sandbox vs production behaviour, signature or HMAC validation, idempotency keys (so a retry doesn’t charge a customer twice), and webhook callbacks.

3. Internal APIs (Private APIs)

Used only inside a company, between its own apps and services. Most APIs a tester works on daily are internal.

What to test: business rules, integration between services, authorization between roles, and data consistency. Don’t assume “internal” means “safe”: internal APIs are a frequent source of data leaks.

4. Composite APIs

One API call that internally triggers several other API calls and returns a combined answer. Often provided by a Backend-for-Frontend (BFF) layer to reduce mobile network calls.

What to test: partial failures (what if the tracking service is down: error, or a response with tracking missing?), timeouts, correct merging of data, and performance of the whole chain.

Classification 2: Types of APIs by Architecture and Protocol

REST APIs

REST (Representational State Transfer) is an architectural style, not a protocol. Everything is a resource with a URL (/users/1), and you act on it with HTTP methods (GET, POST, PUT, PATCH, DELETE). It is stateless, cacheable and uses standard status codes.

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/products/101"

What to test in REST: correct methods and status codes, JSON schema, filters and pagination, headers (ETag, caching), authentication, idempotency of PUT and DELETE.

SOAP APIs

SOAP (Simple Object Access Protocol) is a strict, XML-based protocol. Every message is an XML envelope with an optional header and a body. The contract is described in a WSDL file, which tools such as SoapUI read to generate requests automatically.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:bank="http://example.com/bank">
  <soapenv:Header>
    <bank:AuthToken>abc123</bank:AuthToken>
  </soapenv:Header>
  <soapenv:Body>
    <bank:GetBalance>
      <bank:AccountNumber>XXXX4521</bank:AccountNumber>
    </bank:GetBalance>
  </soapenv:Body>
</soapenv:Envelope>

What to test in SOAP: WSDL validity, XML schema (XSD) compliance, SOAP Faults for errors (usually HTTP 500 with a <soap:Fault>), WS-Security headers, and XPath assertions on response values.

GraphQL APIs

GraphQL has a single endpoint (usually POST /graphql). The client writes a query that asks for exactly the fields it needs, so there is no over-fetching or under-fetching.

query {
  user(id: 1) {
    name
    orders(last: 2) { id total status }
  }
}

What to test in GraphQL: queries and mutations, field-level authorization, errors returned inside an errors array (often with HTTP 200!), deeply nested queries that could overload the server (query depth and complexity limits), and introspection being disabled in production.

gRPC APIs

gRPC, created by Google, sends compact binary messages (Protocol Buffers) over HTTP/2. The contract lives in a .proto file. It is much faster than JSON, supports streaming, and is popular for internal microservice traffic.

service PriceService {
  rpc GetPrice (PriceRequest) returns (PriceReply);
}
message PriceRequest { int32 product_id = 1; string pincode = 2; }
message PriceReply  { double price = 1; string currency = 2; }

What to test in gRPC: gRPC status codes (OK, NOT_FOUND, INVALID_ARGUMENT, DEADLINE_EXCEEDED), deadlines and timeouts, streaming behaviour, and backward compatibility of the .proto file. Tools: Postman (gRPC requests), grpcurl, BloomRPC-style clients and k6.

WebSocket APIs

A WebSocket opens one long-lived connection where both sides can send messages at any time. No repeated polling.

What to test: connection handshake (HTTP 101 Switching Protocols), message order and format, reconnection after network drop, authentication on connect, heartbeat/ping, and load with many simultaneous connections.

Webhooks (Reverse APIs)

With a normal API you call the server. With a webhook, the server calls you when an event happens, by sending an HTTP POST to a URL you registered.

What to test: signature verification (reject tampered payloads), duplicate deliveries (the same event twice must not ship two parcels), retries when your endpoint is down, ordering of events, and quick 2xx acknowledgement. Tools such as webhook.site help you capture webhook calls while testing.

Which API Type Should You Learn First?

1. REST: over 80% of the APIs you will test. Master it first (this course focuses on it).
2. SOAP with SoapUI, if you target banking, insurance or service companies with enterprise clients.
3. GraphQL: growing fast in product companies.
4. WebSocket, webhooks and gRPC: learn the concepts and test approach; tools are similar.

Testing Checklist by API Type

Interview Questions: Types of APIs