What Is a Web Service? Types of Web Services Explained for Beginners (With a Banking Lens)

A colleague joined my team last month straight out of a Java course. Bright, wrote clean code, understood collections and threads. On day three he asked me a question that most of us stopped being able to answer honestly a decade ago: “Everyone keeps saying web service. Web service for what? Which web?”

I gave him the textbook answer — SOAP, WSDL, REST, stateless, resources — and watched his eyes glaze. That is a bad sign. When a definition needs three other definitions before it makes sense, the definition is broken. So I tried again from zero, and this article is that second attempt, cleaned up. If you have never touched a web service, it is written for you; if you have run middleware for fifteen years like me, read the banking half anyway.

Start With Something You Already Do

Open your browser, type prasweb.com, press Enter. Your browser sends a request across the internet, some machine somewhere sends back a page, your browser draws it. You read it. Simple.

Now change one thing. Keep everything the same — the request, the network, the machine, the reply — but remove the human. Instead of a browser asking for a page a person will read, a program asks for data another program will use. The reply is not a page with fonts and buttons; it is a small structured block of facts.

That is a web service. It really is that plain. It is a website whose only visitor is other software.

Your food delivery app does not carry every restaurant’s menu inside it — it asks a service. Your banking app does not carry your balance around; it asks a service, and that service asks the core banking system, which is itself reachable as a service.

The useful mental image: a web service is a counter window. There is a fixed address, a list of things you may ask for, a form you must fill in correctly, and a clerk who hands something back. You cannot walk behind the counter. You cannot invent your own form. You ask what the window is built to answer, in the shape it expects, and you get a reply or a refusal.

The Four Parts Every Web Service Has

Strip away every acronym and you are left with four questions. Every web service — 1998 vintage or shipped last week — answers all four.

1. The address. Where do I send this? Usually a URL like https://api.somebank.in/v1/accounts/12345/balance. Nothing exotic — the same kind of address your browser uses.

2. The contract. What am I allowed to ask, what must I supply, and what will I get back? “Send me an account number and a valid token; I will return a balance and a currency code.” Some contracts are machine-readable files (WSDL, OpenAPI, .proto), some are a page of documentation, some — regrettably — are a WhatsApp message from the vendor’s integration engineer.

3. The message format. What language is the conversation in? XML, JSON, Protocol Buffers, fixed-width text. This is the part beginners fixate on and it matters least.

4. The transport. How does the message physically travel? Almost always HTTPS. Sometimes a message queue, sometimes raw TCP.

Every “type” of web service below is just a different set of opinions about those four things. Once you see that, the acronyms stop being intimidating and start being choices.

The Types You Will Actually Meet

SOAP — the formal one

SOAP (Simple Object Access Protocol, and the “Simple” has aged badly) is the older, stricter family. Messages are XML wrapped in a standard envelope. The contract is a WSDL file, which is itself XML, and which describes every operation and every field type so precisely that tooling can generate client code from it automatically.

It is verbose. A request that carries fifty characters of real information can run to several hundred bytes of envelope. In exchange you get things that matter when money moves: strong typing, formal schema validation, and the WS-* standards — WS-Security for message-level signing and encryption, WS-ReliableMessaging for guaranteed delivery, WS-AtomicTransaction for two-phase commit across systems.

Where you find it: core banking, insurance policy administration, payment switches, government integrations, telecom provisioning. Anywhere the system was designed between roughly 2000 and 2012 and has been too important to rewrite since.

My honest read: nobody starts a greenfield project with SOAP in 2026, and anyone who tells you SOAP is dead has never worked in a bank. I still spend real hours every month on SOAP endpoints, and they are not going anywhere this decade.

REST — the default

REST (Representational State Transfer) is less a protocol than a style. It says: model everything as a resource with an address, and act on it with the verbs HTTP already gives you.

• GET /accounts/12345 — read the account
• POST /accounts/12345/transfers — create a transfer
• PUT /customers/987 — replace the customer record
• DELETE /cards/456 — remove the card

Messages are almost always JSON, which is readable by a human without tooling. Each call is stateless — the server remembers nothing between calls, so every request carries whatever context it needs. That single property is why REST scales: any server in the pool can answer any request, so you add capacity by adding boxes.

Main trade-off: the looseness that makes REST fast to build makes it easy to build badly. There is no WSDL forcing discipline. Two REST APIs from the same organisation will disagree about error formats, pagination and date handling unless someone enforces standards. OpenAPI specifications exist precisely to put back the rigour SOAP had by default.

gRPC — the fast internal one

gRPC, from Google, is what you reach for when two of your own services talk to each other thousands of times a second and every millisecond counts. Contracts are .proto files. Messages are Protocol Buffers — a binary format, so compact and quick to parse, and completely unreadable if you open it in a text editor. It runs over HTTP/2, so a single connection carries many calls at once and supports streaming in both directions.

Where it fits: service-to-service traffic inside your own perimeter. A fraud-scoring service that must answer in eight milliseconds. A limit-check service called on every transaction.

Where it does not: as a public API. Your partners’ developers cannot debug a binary payload with curl, and you will spend the integration budget on support calls.

GraphQL — the client picks

The problem GraphQL solves: your mobile app needs a customer’s name, last five transactions and card status. With REST that is three calls, and each returns far more than the app needs — wasteful on a 3G connection in a tier-3 town.

GraphQL gives you one endpoint and lets the client send a query describing exactly which fields it wants. One round trip, no wasted bytes. Excellent for mobile and for aggregating several backend systems behind one facade.

The catch: you have handed clients the ability to write expensive queries against your backend. Query-depth limits, complexity budgets and caching all become your problem. Caching in particular is much harder than with REST, where a URL is a natural cache key. Powerful, and not free.

Message-queue and event services — fire and forget

Everything above is a conversation: ask, wait, get an answer. Sometimes waiting is wrong. When a payment settles, twenty downstream systems care — ledger, statements, notifications, analytics, AML monitoring, loyalty. The payment service should not be calling twenty endpoints and waiting for twenty replies. Any one of them being slow would slow the payment.

So instead it publishes one message — “payment 8891 settled” — onto a queue or topic (IBM MQ, Kafka, RabbitMQ, JMS) and moves on. Interested systems consume it in their own time. If one is down, the message waits. This is asynchronous integration, and mature banking estates are full of it.

The judgement call: ask synchronously when you need the answer to continue, publish asynchronously when someone else needs to know but you do not need their acknowledgement.

Webhooks — the reverse call

Worth a mention because beginners rarely see it coming. Normally you call the service. A webhook flips it: you register a URL of your own, and when something happens, they call you. Payment gateways use this heavily — rather than your system polling “is it done yet?” every two seconds, the gateway posts the result to your endpoint the moment it settles.

Side by Side

Webhooks sit awkwardly in a table like this — they are a direction of call rather than a message-format family, and they usually carry plain JSON over HTTPS like any REST call. I have included the row anyway, because in practice you choose between “I will poll them” and “they will call me” exactly as you choose between the others.

Why Banking Cannot Function Without Them

Here is the part I care about most, and the part the tutorials skip.

A bank is not one system. It is dozens, bought or built across thirty years, in different languages, on different hardware, under different vendors. The core ledger, the card system, loan origination, treasury, AML, CRM, the mobile app, the ATM switch — all separate, all needing to know things the others hold.

You cannot merge them. Merging thirty years of banking systems is a decade-long programme that has sunk plenty of institutions that tried. So you connect them instead. Web services are the connective tissue, and without them a modern bank simply does not work. That is not a marketing line — it is an architectural fact.

UPI is the clearest proof

India’s UPI processed 24.51 billion transactions worth ₹29.82 lakh crore in August 2026, a record month. Look at what one of those payments actually is.

You tap send in a payment app. That app calls its PSP bank’s API. The PSP calls NPCI. NPCI resolves your VPA to an account, routes to the remitter bank, which calls its own core banking to debit, then to the beneficiary bank, which credits and confirms. Confirmation travels the whole chain back. Both banks publish settlement events internally. Fraud engines get called along the way. Two notifications go out.

That is a dozen or more web service calls, across four or five organisations, in under three seconds — and it happens roughly nine thousand times a second on average, far more at peak. There is no version of this that works without machine-to-machine services with strict contracts and hard latency budgets. UPI is not a payment product; it is a public web service specification with an enormous amount of infrastructure honouring it.

Regulation now assumes APIs exist

Two examples worth knowing if you work in Indian BFSI.

The Account Aggregator framework lets you share your financial data between regulated entities with explicit consent, entirely through standardised APIs. Government figures put the number of users who have linked financial accounts past the 11-crore mark, with the ecosystem facilitating tens of millions of financial services in FY26, and the RBI recognised Sahamati as its self-regulatory organisation in 2026. A lender that cannot consume those APIs cannot participate. The consent artefact itself is a signed digital object passed between services — the regulation is written in the shape of a web service.

ISO 20022 is the other. SWIFT’s cross-border payment traffic completed its cutover from the old MT messages to ISO 20022 XML in November 2025, ending the coexistence period. Every bank in that flow had to change its message formats and its integration layer to a deadline set by someone else. If your integration was buried in point-to-point code instead of a managed service layer, that migration hurt considerably more than it needed to.

What the bank actually gets from this

Channel independence. Build the balance-enquiry service once and the mobile app, net banking, ATM, IVR, branch teller screen and partner API all consume the same one. Change the ledger underneath and no channel notices. This is the single biggest return.

Partnering at all. Embedded finance, co-lending, merchant acquiring, insurance distribution — every one of these is an API integration with an outside party. No services, no partnerships.

Auditability. Every call through a gateway is logged with who, what, when and the outcome. When the regulator asks how customer data reached a third party, you produce the trail. Point-to-point database links produce nothing.

Blast radius control. When the card system is degraded, a well-built service layer fails just card operations — circuit breakers open, timeouts fire, fallbacks return a graceful message. Badly built, the whole mobile app hangs waiting on thread pools that never drain. I have watched both versions of that evening. The difference is entirely in the integration layer.

The uncomfortable flip side: once everything runs through services, the service layer is the bank’s availability. Your gateway, your ESB, your app servers and their connection pools are now customer-facing infrastructure. This is why middleware capacity planning stopped being a back-office concern.

Security: The Half That Decides Whether Any of This Is Safe

Everything above quietly assumed the caller is welcome. Drop that assumption and the whole picture changes.

Go back to the counter window. A web service is a window that will answer “what is the balance of account 12345?” — reliably, in milliseconds, thousands of times a second, to whoever walks up. It has no instinct. It does not notice that the person asking looks wrong, or that the same person has now asked about forty thousand different account numbers in a row. A branch clerk would. A service will not, unless you build it to.

That is why security is not a layer you bolt on after the integration works. It is the difference between an interface and a liability.

Authentication — who are you?

Authentication answers one question: is the caller who they claim to be? Nothing more. The common mechanisms, roughly in order of how much I would trust them:

• API keys — a long secret string in a header. Simple, and weak: it identifies an application, not a user, and anyone who copies the string becomes that application. Fine for a public rate-limited read endpoint, wrong for anything touching money.
• OAuth 2.0 and OpenID Connect — the caller first obtains a short-lived access token from an authorisation server, then presents that token on each call. Tokens expire in minutes, can be scoped narrowly and revoked centrally. This is the default for customer-facing and partner APIs today.
• Mutual TLS (mTLS) — both ends present certificates, so the client proves its identity at the transport layer before a single byte of the request is read. Standard practice for bank-to-bank and bank-to-regulator links.
• Message-level signatures — the payload itself is signed, and often encrypted, so it stays verifiable after the transport hop ends. This is what WS-Security does in the SOAP world, and what UPI and Account Aggregator flows do with signed digital objects.

The point people miss: a token is a bearer instrument. Whoever holds it is treated as the caller. Short lifetimes, narrow scopes and proper storage are not paranoia — they are what limits the damage when one inevitably leaks into a log file.

Authorisation — what are you allowed to do?

Authorisation is the separate, harder question: given that I know who you are, may you do this specific thing to this specific object? Two layers matter.

Function-level: may this caller invoke this operation at all? A read-only reporting partner should hold a accounts:read scope and nothing that permits a transfer. This one teams usually get right, because it is visible in the API design.

Object-level: may this caller act on this record? This is the one that quietly fails everywhere. A customer authenticates perfectly, then requests GET /accounts/12346 instead of 12345 — and the service, having confirmed a valid token, happily returns someone else’s balance. OWASP ranks broken object-level authorisation as API1, the number-one risk in its API Security Top 10, and it earns the position: the check has to be written deliberately, on every endpoint, and there is no framework that does it for you.

Around those two sit the supporting controls — TLS everywhere, rate limiting and throttling per client, input validation, and logging every call with caller, action, object and outcome. Unglamorous, and each one is a control an auditor will ask you to evidence.

What actually happens when a service is not properly secured

Failures here do not look like failures elsewhere. A badly secured web service does not crash — it works perfectly, at machine speed, for the wrong person.

• Data loss at a scale a screen cannot reach. A leaked internal screen exposes records one at a time. A leaked API endpoint with a missing object-level check exposes them at whatever rate the caller can loop — sequential account IDs, thousands per minute, until someone notices the traffic.
• Unauthorised transactions. If the authorisation gap is on a write endpoint rather than a read, the outcome is not a data breach — it is money moving.
• Enumeration and reconnaissance. Verbose error messages that distinguish “no such customer” from “wrong password” hand an attacker a free customer-validation service.
• Denial of service by accident or design. One unthrottled expensive endpoint — an unbounded GraphQL query, a report generator — is enough to exhaust the connection pools that every other channel shares. I have seen a partner’s retry loop take down a channel more effectively than any attacker did.
• Regulatory and reporting consequences. In India, CERT-In’s 2022 directions require certain cyber incidents to be reported within six hours of being noticed. Six hours is not long enough to work out what happened if you cannot answer, from your logs, who called what and when. The audit trail is not paperwork; it is the thing that makes the incident survivable.
• The one that lasts. Systems get patched in days. Customer trust in a bank does not, and neither does the supervisory attention that follows.

The uncomfortable truth from the incidents I have seen up close: almost none were clever. They were a missing ownership check, a token with a scope far wider than the use case needed, an internal service exposed because someone assumed the network perimeter was the control, or a test endpoint that reached production. Security failures in web services are usually boring — which is exactly why they are preventable.

Key Takeaways

• A web service is a website for software. Same request, same network, different reader. Start there and the rest follows.
• Four parts, always: address, contract, message format, transport. Every acronym is a set of opinions about those four.
• The types are not competitors so much as different tools. SOAP where contracts and message security are non-negotiable, REST for reach, gRPC for internal speed, GraphQL for client-shaped reads, messaging for anything that should not block.
• Banking is a federation of systems that cannot be merged. Web services are what make it behave as one, and Indian regulation now assumes they exist.
• An unsecured service does not crash — it works perfectly for the wrong person. Object-level authorisation is the check nobody writes and everybody needs.
• The integration layer is customer-facing infrastructure. Treat its availability the way you treat the core’s.

Conclusion & Next Steps

My colleague’s confusion was reasonable. We teach this subject backwards — protocols first, then standards, then patterns, and only at the end, if ever, what the thing is actually for. Anyone learning this now should go the other way. If you are starting out, the exercise I would set: pick any public API, call it from a terminal, read the JSON that comes back, then map it to the four parts. That half hour teaches more than a week of protocol theory.

If you have been doing this a while, the question worth asking about your own estate is not which protocol you use — you use all of them — but whether you could name, today, every service your customer-facing journeys depend on, and what happens to each journey when one of them is slow. Most banks cannot answer that quickly enough.

What has been your worst integration surprise — a contract change nobody announced, a partner endpoint that quietly doubled its latency, a queue that filled at 2 AM? Drop it in the comments. The war stories are how the rest of us learn what to check for.

Related reading on this site: middleware and integration posts, OpenShift in banking, and WebLogic operations.

Frequently Asked Questions

Is a web service the same thing as an API?

Close, but not identical. An API is any interface one piece of software offers another — including a local library you call inside the same process. A web service is an API you reach over a network. Every web service is an API; not every API is a web service. In everyday conversation people use them interchangeably and nobody minds.

Do I need to learn SOAP if I am starting today?

You do not need to build in it, but you should be able to read a WSDL and send a SOAP request without panicking. If you work anywhere near banking, insurance, telecom or government, you will meet one within your first year. Learn REST properly first, then spend an afternoon on SOAP so it is not a mystery.

What is the difference between authentication and authorisation?

Authentication establishes who the caller is — a valid token, a client certificate, a signed message. Authorisation decides what that caller is permitted to do, and to which specific record. They are separate checks and both must pass. Most serious API breaches are not authentication failures; the attacker logged in perfectly well as themselves and then asked for someone else’s data, because nobody wrote the ownership check.

Which type is the most secure?

Wrong question, and it is the one I hear most. SOAP has more security machinery built in through WS-Security, which signs and encrypts the message itself so it stays protected past the transport hop. REST relies on TLS plus OAuth 2.0 or mTLS, which is entirely sufficient when implemented properly. The insecure systems I have seen were never insecure because of protocol choice — they were insecure because of missing authentication, over-broad scopes, no rate limiting, or secrets in configuration files.

Why do banks still run old SOAP services instead of moving everything to REST?

Because those services work, they are audited, and they sit closest to the money. Rewriting a payment interface earns you no new revenue and carries real risk of breaking settlement. The usual approach is to leave the SOAP endpoint alone and put a REST facade in front of it, so new consumers get a modern interface while the proven path underneath stays untouched. It is not laziness — it is correct risk management.

What does middleware have to do with all this?

Middleware is the layer web services run on and travel through — the application servers hosting them, the API gateways fronting them, the message brokers carrying the asynchronous ones, the load balancers spreading traffic. When someone says “the API is down”, the cause is usually not the API code. It is an exhausted connection pool, a full queue, an expired certificate, or a thread pool with nowhere to go. That layer is where I have spent most of my career, and it is where the outages actually live.