Exploring the API Universe: Different Types of APIs You Should Know
I broke this down in the video above. Below is the written version, expanded into a fuller reference on the API styles a tester runs into and how each one changes the way you test it.
There are many types of APIs, and the type an API uses is not a trivia question. It decides how you call it, how it reports errors, and how you have to test it. If you are a tester who keeps hitting APIs without a clear picture of how REST differs from SOAP or GraphQL, this one is for you. Over the years, as technology and requirements changed, so did the methods and standards for software talking to software. In this article I want to walk through the main API styles, REST, SOAP, GraphQL, RPC, and webhooks, with the features that matter and what each one means when you sit down to test it.
Why a tester needs to know the API styles
Knowing the API style tells you how to test it, because each style carries its own rules for requests, errors, and data.
REST is the most widely used style today, and a lot of testers treat every API as if it were REST. That assumption gets you into trouble the first time you meet a SOAP service or a GraphQL endpoint. The style determines where the data lives, how many endpoints exist, what a success looks like, and how a failure comes back.
In my testing, REST is what I hit most often, but the others still show up, especially in finance, enterprise integrations, and event-driven systems. I cover the full landscape in the video. The goal here is to recognize the style fast, because that recognition shapes everything you do next.
REST, the default style
REST is an architectural style that treats everything as a resource you act on with standard HTTP methods, and it is the most widely used API style today.
REST was conceptualized by Dr. Roy Fielding in his 2000 doctoral dissertation, as a response to the complexity of SOAP and similar architectures. It is not a protocol or a standard. It is a set of guidelines. The core idea is to treat everything as a resource you operate on with standard HTTP methods. I walk through REST first in the video because it is the style you will test most.
Its characteristics define how you test it. REST is stateless, so every request must carry everything the server needs, with no stored context between calls. It separates client and server, allows caching, and uses a layered design. It speaks JSON in most cases and XML in legacy systems. The methods are GET to retrieve, POST to create, PUT to update, DELETE to remove, and PATCH to apply a partial change. When you test REST, you check the status codes the video calls out, like 200 for success, 404 for not found, and 500 for server errors, plus versioning, clear error messages, and OAuth-based security.
SOAP, the heavyweight standard
SOAP is a strict XML-based protocol built for secure, cross-platform communication, and it is still common in finance and enterprise systems.
SOAP was developed in the late 1990s so programs on different operating systems, like Windows and Linux, could talk to each other. It became a W3C standard and won favor in financial services and enterprise integrations, anywhere that needed strong security and ACID compliance. It usually runs over HTTP but can run over other protocols, and any language can implement it.
A SOAP message is XML with a clear structure: an envelope that wraps everything, an optional header for metadata like authentication, a body that holds the actual content, and an optional fault element that reports errors. That fault element is a gift to a tester, because error handling is built in and structured. The trade-off is weight. SOAP is verbose, parsing the XML is CPU and memory heavy, and it tends to be slower and use more bandwidth than lighter styles.
GraphQL, ask for exactly what you need
GraphQL is a query language with a single endpoint that lets clients request exactly the data they want, which cuts the over-fetching and under-fetching common with REST.
GraphQL was developed by Facebook in 2012 and open-sourced in 2015, built to fix inefficiencies in traditional REST APIs. Its standout feature is a flexible query language. The client asks for precisely the fields it needs and nothing more, so you stop pulling back too much or too little data.
It is strongly typed, every query is validated against a schema, and it usually exposes a single endpoint instead of many. The schema makes it self-documenting, so you can introspect it and see the capabilities directly. You read with queries, write with mutations, and get real-time updates with subscriptions. The advantages are flexibility, strong typing, and introspection. The risks a tester watches for are the learning curve for REST-trained teams and deeply nested queries that can drag performance down if nobody is monitoring them.
RPC and webhooks, the rest of the landscape
RPC calls a procedure on a remote server, and webhooks push data to you when an event happens, and both need a different approach than request-and-response REST.
RPC goes back to the early days of distributed computing. The idea is to execute a method on a remote server as if it were local. Traditional RPC is often blocking, so the client waits until the server responds, and the client and server usually share a generated interface through a stub. Common forms include XML-RPC, JSON-RPC, and gRPC, the modern framework from Google that uses protocol buffers and supports streaming. RPC can be very efficient with binary protocols, but it is more complex and less web-friendly to debug than HTTP styles.
Webhooks flip the direction. A webhook is a user-defined HTTP callback that fires when a specific event occurs, sending data to a target URL. They are event-driven and asynchronous, so the source does not wait for a reply. You see them in notifications, CI/CD triggers on a commit, and CRM updates. What I learned testing them is that the asynchronous nature is exactly what makes them hard. I found webhooks the toughest of these styles to test reliably, because delivery is not guaranteed on an unstable network and a poorly secured endpoint is an open door.
The takeaway
There are many types of APIs, and REST is the one you will meet most. SOAP brings strict structure and strong security at the cost of weight. GraphQL gives clients precise control over the data. RPC executes remote procedures efficiently. Webhooks push real-time events instead of waiting to be asked. Each one serves a purpose and carries its own advantages and trade-offs. The first move in any API testing job is to identify the style, because that decides how you test everything after it.
If this helped, the full walkthrough is in my video on the different types of APIs. Here is my question for the comments: which API style gives your team the most trouble to test, and why? Subscribe if you want more grounded explanations of testing and quality.
