Top 50 Web Services Interview Questions (2026)

A web service is a way for two applications to talk to each other over a network using standard web protocols, usually HTTP. It exposes endpoints that take a request and return a response, so a client written in one language can call a service written in another.

The point is interoperability: the client and server only agree on the message format (often JSON or XML) and the protocol, not each other's internals. That's what lets a mobile app, a browser, and a backend all consume the same API.

An API (Application Programming Interface) is any contract that lets one piece of software call another. It's the broad term. A web service is a specific kind of API that's exposed over a network using web protocols like HTTP.

So every web service is an API, but not every API is a web service: a library you import exposes an API without any network involved. When people say 'web API' they usually mean a web service, most often a REST API over HTTP.

REST (Representational State Transfer) is an architectural style for web services. It models everything as resources identified by URLs, uses standard HTTP methods (GET, POST, PUT, DELETE) to act on them, and keeps each request stateless so the server holds no client session between calls.

A RESTful API returns representations of resources, usually as JSON. The style is popular because it rides on plain HTTP: browsers, proxies, and caches already understand it, and the tooling is everywhere.

GET reads a resource without changing it. POST creates a new resource. PUT replaces a resource entirely. PATCH applies a partial update. DELETE removes a resource. These verbs are how a REST API expresses the action while the URL names the resource.

Two properties matter in interviews: GET, PUT, and DELETE are idempotent (repeating them has the same effect), while POST is not. GET is also safe, meaning it shouldn't change anything on the server.

Status codes are grouped by first digit. 2xx means success (200 OK, 201 Created, 204 No Content). 3xx means redirection (301 moved permanently, 304 not modified). 4xx means the client did something wrong (400 bad request, 401 unauthorized, 403 forbidden, 404 not found). 5xx means the server failed (500 internal error, 503 unavailable).

The distinction that matters: 4xx is the client's fault, 5xx is the server's. Returning the right code lets clients, caches, and monitoring react correctly, so picking 200 for everything is a real API design mistake.

All three are success codes, but they say different things. 200 OK means the request succeeded and there's a response body, typically for a GET or an update. 201 Created means a new resource was created, usually the response to a POST, and often includes a Location header pointing to it.

204 No Content means the request succeeded but there's nothing to return in the body, common after a DELETE or an update where the client doesn't need the resource back. Choosing correctly among them is a small but real signal of API care.

An API is RESTful when it follows REST's constraints: resources addressed by URLs, standard HTTP methods used for their real meaning, stateless requests, and responses that return representations (JSON) the client can act on. Ideally it's also cacheable and has a uniform, predictable interface.

Many APIs call themselves REST but break the rules, tunneling everything through POST, or putting verbs in the URL like /getUser. Those work, but they're not really RESTful. The interviewer usually wants to hear you can tell the difference.

JSON (JavaScript Object Notation) is a lightweight text format of key-value pairs and arrays. It's compact, easy to read, and native to JavaScript, so it's the default for most REST APIs today. XML (Extensible Markup Language) is a tag-based format that's more verbose but supports schemas, namespaces, and attributes.

REST APIs almost always use JSON; SOAP services use XML because the SOAP protocol is built on it. XML still wins where you need a strict schema, document markup, or the enterprise tooling around it, but for a typical web API JSON is lighter and simpler.

A request has a method and path (GET /users/42), headers (like Authorization and Content-Type), and an optional body for POST, PUT, or PATCH. A response has a status code (200, 404), headers, and usually a body carrying the data or an error.

Understanding the parts matters because so much of web services debugging lives in the headers and status code, not the body: a wrong Content-Type, a missing auth header, or a 401 tells you more than the payload does.

Headers are key-value metadata sent with a request or response, separate from the body. Common ones: Content-Type says what format the body is (application/json), Authorization carries credentials, Accept says what the client wants back, and Cache-Control governs caching.

They matter because headers control how the message is interpreted and secured. A wrong Content-Type makes a server reject a valid body, a missing Authorization returns 401, and CORS headers decide whether a browser lets a page call your API at all.

GET reads data and shouldn't change anything on the server; its parameters go in the URL, and responses can be cached and bookmarked. POST sends data in the request body to create or trigger something, changes server state, and isn't cached by default.

The practical rules: never put sensitive data in a GET query string (it lands in logs and browser history), and don't use GET for actions that change state. GET is safe and idempotent; POST is neither.

An endpoint is a specific URL where a web service accepts requests for a particular resource or action, like https://api.example.com/v1/users. Combined with an HTTP method, it defines one operation: GET /users lists users, POST /users creates one.

So the same URL can back several operations distinguished by the verb. Designing clear, consistent endpoints (plural nouns, no verbs in the path, predictable nesting) is a big part of what makes an API pleasant to use.

SOAP (Simple Object Access Protocol) is an older, XML-based protocol for web services. Every message is an XML envelope with a header and body, and the service is described by a WSDL contract that spells out exactly what operations and types exist. It can run over HTTP but isn't tied to it.

SOAP brings built-in standards for security (WS-Security), transactions, and reliable messaging, which is why it lingers in banking, telecom, and older enterprise systems. The cost is verbosity and rigidity compared with REST, so most new public APIs don't use it.

A WSDL (Web Services Description Language) is an XML document that formally describes a SOAP web service: the operations it offers, the input and output message types, and where to reach it. It's the machine-readable contract a client uses to know exactly how to call the service.

Because it's strict and generated, tooling can auto-create client code (stubs) from a WSDL. That's a strength of SOAP: the contract is explicit. REST's rough equivalent is an OpenAPI/Swagger specification, though REST doesn't require one.

Stateless means each request carries everything the server needs to handle it, and the server keeps no memory of previous requests from that client. There's no server-side session tying one call to the next; if the client needs to prove who it is, it sends a token on every request.

This is why REST scales well: since no request depends on server-held session state, any server instance can handle any request, so you can add instances behind a load balancer freely. State that must persist lives in a database or a token, not in the server's memory.

Path parameters identify a specific resource and live in the URL path: /users/42 where 42 is the user id. Query parameters come after a ? and refine or filter a request: /users?role=admin&page=2 for filtering, sorting, and pagination.

The rule of thumb: use a path parameter when it names which resource, and a query parameter when it's an option on a collection (filter, sort, paginate, search). Mixing them up (putting a filter in the path) makes an API awkward.

Serialization is turning an in-memory object (a struct, a class instance) into a format that can travel over the network, usually a JSON or XML string. Deserialization is the reverse: parsing that string back into an object the receiving code can use.

Every web service call does this: the server serializes its response object to JSON, sends it, and the client deserializes it. Getting the mapping right, dates, nulls, field names, is a frequent source of subtle bugs between services written in different languages.

curl and Postman are the two everyday tools. curl sends HTTP requests from the command line, so you can hit an endpoint, set headers, and see the raw status and body. Postman gives a GUI to build requests, save collections, and inspect responses, which is handy for exploring an API.

Both let you send any method, set auth headers, and read the exact status code and response, which is how you verify behavior and reproduce bugs. Being fluent with curl in particular reads well because it shows you understand the raw HTTP underneath.

An operation is idempotent if making the same request many times has the same effect as making it once. GET, PUT, and DELETE are idempotent: reading twice, replacing twice, or deleting twice leaves the same end state. POST is not, because two POSTs usually create two resources.

It matters for reliability: networks drop responses, so clients retry. If the method is idempotent, a retry is safe. For POST, you add an idempotency key so a retried create isn't processed twice, which is exactly how payment APIs avoid double charges.

Choose REST by default for web and mobile APIs: it's lighter, JSON-based, cache-friendly, and has huge tooling. Reach for SOAP when you need its built-in standards: WS-Security for message-level encryption and signing, formal contracts via WSDL, or reliable-messaging and transaction guarantees across services.

In practice SOAP survives in banking, payments, telecom, and government systems where a strict contract and enterprise security standards were required, and rewriting them isn't worth it. For a new public API, REST (or GraphQL) is almost always the right call.

GraphQL is a query language and runtime for APIs. Instead of many endpoints, it exposes one, backed by a typed schema, and the client sends a query asking for exactly the fields it wants. The server returns just those fields, so there's no over-fetching or under-fetching.

The trade-off versus REST: GraphQL solves the problem of a mobile screen needing five REST calls or a bloated response, but it makes HTTP caching harder (everything is one POST endpoint) and adds query-cost concerns, since a client can request deeply nested data. REST's per-URL caching is simpler.

gRPC is a remote-procedure-call framework that uses HTTP/2 for transport and Protocol Buffers (a compact binary format) for messages. You define services and messages in a .proto file, and it generates typed client and server code in many languages. It supports streaming in both directions.

You'd use it for internal service-to-service communication where speed and a strict contract matter: the binary format and HTTP/2 multiplexing make it faster and lighter than JSON over HTTP/1.1. The catch is it isn't natively browser-friendly, so public web APIs usually still expose REST or GraphQL and keep gRPC internal.

The common options: API keys (a shared secret in a header, simple but coarse), Basic auth (username and password base64-encoded, only safe over HTTPS), bearer tokens like JWTs (a signed token sent on each request), and OAuth 2.0 (a flow that issues scoped access tokens on behalf of a user without sharing their password).

For user-facing APIs, OAuth 2.0 with bearer tokens is the modern default. For server-to-server, API keys or client-credential OAuth are common. Whatever you pick, it rides on HTTPS, because every scheme here leaks if the connection isn't encrypted.

A JWT (JSON Web Token) is a compact, signed token with three parts: a header, a payload of claims (like the user id and expiry), and a signature. The server signs it with a secret or private key, so it can later verify the token wasn't tampered with, without a database lookup.

It's used for stateless auth: after login, the server issues a JWT, the client sends it in the Authorization header on every request, and the server verifies the signature. The important caveats: the payload is only base64-encoded, not encrypted, so never put secrets in it, and set a short expiry because a stolen token is valid until it expires.

The common approaches: put the version in the URL path (/v1/users), which is the most visible and easiest to route; put it in a header (Accept: application/vnd.api.v2+json), which keeps URLs clean but is less obvious; or use a query parameter (?version=2), which is simplest but least clean.

URL versioning wins on clarity and tooling in most real APIs. Whatever you pick, the goal is the same: ship breaking changes in a new version while the old one keeps serving existing clients, and give consumers a deprecation window before you retire an old version.

A breaking change is any change that can break an existing client. Removing or renaming a field, changing a field's type, making an optional request field required, changing a status code's meaning, or altering error formats are all breaking. Existing clients coded against the old shape will fail.

Non-breaking (backward-compatible) changes are additive: adding a new optional field, a new endpoint, or a new optional query parameter. The rule is you can add, but you can't remove or change the meaning of what's already there without a new version.

Use the right HTTP status code first (400 for bad input, 401 for unauthenticated, 403 for forbidden, 404 for not found, 409 for conflict, 422 for validation, 429 for rate limits, 500 for server faults), then return a consistent JSON error body with a machine-readable code, a human message, and ideally which field failed.

Consistency is what matters: every endpoint should return the same error shape so clients can handle errors generically. Never return 200 with an error inside the body, and never leak stack traces or internal details to callers.

Two main approaches. Offset pagination uses limit and offset (or page and size): simple, lets you jump to any page, but gets slow on large offsets and can skip or repeat rows if data changes between pages. Cursor (keyset) pagination returns a pointer to the last item and asks for the next batch after it: stable under inserts and fast at scale, but you can't jump to an arbitrary page.

Offset is fine for small or admin datasets; cursor pagination is what large, changing feeds use. Either way, return the page data plus metadata (a next cursor or total count) so the client knows how to fetch more.

Rate limiting caps how many requests a client can make in a time window, protecting the service from abuse, runaway clients, and accidental floods. When a client exceeds the limit, the API returns 429 Too Many Requests, usually with a Retry-After header telling it when to try again.

Common algorithms are the token bucket (tokens refill at a fixed rate, each request spends one, allowing short bursts) and the fixed or sliding window (count requests per window). Limits are tracked per API key or user, often in a fast store like Redis, and good APIs return headers showing the remaining quota.

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that controls whether a web page from one origin can call an API on a different origin. By default the browser's same-origin policy blocks such calls; CORS lets the server opt in by sending headers like Access-Control-Allow-Origin that say which origins are allowed.

It exists to stop a malicious site from silently making authenticated requests to another site's API using a logged-in user's cookies. A key point for interviews: CORS is enforced by the browser, not the server, so it only affects browser-based clients. curl and server-to-server calls ignore it entirely.

PUT replaces the entire resource: you send the full representation, and any field you omit is treated as cleared or reset. PATCH applies a partial update: you send only the fields you want to change, and the rest stay as they are.

So updating just one field is a PATCH; if you PUT with only that field, you risk wiping the others. PUT is idempotent by definition (replacing with the same body repeatedly gives the same result); PATCH can be idempotent but isn't required to be, depending on the operations it describes.

HTTP has built-in caching driven by headers. Cache-Control sets how long a response can be reused (max-age) and whether it's private or shared. ETag gives a response a version tag: the client sends it back as If-None-Match, and the server replies 304 Not Modified with no body if nothing changed, saving bandwidth. Last-Modified works similarly with dates.

Only safe, cacheable methods (mainly GET) get cached. Caching lives at several layers: the browser, a CDN, and a reverse proxy. Getting the headers right cuts load and latency; getting them wrong serves users stale data, so cache invalidation is the genuinely hard part.

OpenAPI is a standard, machine-readable specification (a YAML or JSON file) that describes a REST API: its endpoints, methods, parameters, request and response schemas, and auth. Swagger is the popular tooling built around it. It's REST's answer to what WSDL is for SOAP, though REST doesn't require it.

The payoff is that one spec drives a lot: interactive docs, client SDK generation, server stubs, request validation, and contract tests. It becomes the single source of truth both sides agree on, which cuts the miscommunication between API producers and consumers.

A synchronous call blocks: the client sends a request and waits for the response before doing anything else, which is fine for quick reads and writes. An asynchronous approach returns immediately (often 202 Accepted) and does the work in the background, then notifies the client via polling, a webhook, or a message queue.

You go async when the work is slow (video processing, report generation, sending thousands of emails) so you don't hold a connection open for minutes. The trade-off is complexity: the client now has to track a job id or receive a callback instead of getting the answer inline.

Polling means the client repeatedly asks the server 'anything new yet?' on a schedule. It's simple but wasteful: most polls return nothing, and there's lag between an event happening and the next poll picking it up. A webhook flips it: the server calls a URL you registered the moment an event happens, so you get pushed the update instead of asking for it.

Webhooks are more efficient and near-real-time, which is why payment and messaging platforms use them. The cost is you must run a public endpoint to receive them, verify each call is genuine (a signature), and handle retries and duplicates. Polling needs none of that infrastructure, so it's still fine for low-frequency or internal cases.

Use an idempotency key. The client generates a unique key per logical operation and sends it as a header on the POST. The server records the key with the result of the first successful call. If the same key arrives again (a retry after a dropped response), the server returns the stored result instead of charging again.

The details that matter at scale: store the key with the response atomically so two concurrent retries can't both process, scope keys per client, and expire them after a sensible window. This is exactly how Stripe-style payment APIs let clients retry a timed-out charge without risking a double charge.

Layer it. Enforce HTTPS everywhere so nothing travels in the clear. Authenticate every request (OAuth 2.0 bearer tokens or scoped API keys) and authorize per action, not just per login. Validate and sanitize all input to block injection, and never trust client-supplied ids without checking ownership, or you get insecure-direct-object-reference bugs where user A reads user B's data.

Then add rate limiting and quotas to blunt abuse and denial-of-service, return generic errors that don't leak internals, set security headers, and log and monitor for anomalies. Keep secrets in a manager, rotate keys, and scope tokens narrowly so a leaked one does limited damage. Defense in depth, because any single control can be bypassed.

Match the style to the caller. For a public API with many unknown consumers, REST wins on simplicity, caching, and universal tooling. For a product where varied clients (web, mobile) need different field shapes and you want to cut round trips, GraphQL fits, accepting harder caching and query-cost control. For internal service-to-service calls where latency and a strict contract matter, gRPC's binary format and HTTP/2 streaming win.

In real systems you mix them: gRPC between backend services, REST or GraphQL at the public edge. The strong move is to justify the choice by the consumers and constraints (caching needs, client diversity, latency budget, browser reach) rather than picking a favorite.

Webhooks push events to a consumer's URL instead of making them poll. Reliable delivery needs retries with exponential backoff for failed deliveries, idempotency so a consumer can safely receive the same event twice (retries cause duplicates), and a signature (an HMAC of the payload) so the receiver can verify the event really came from you and wasn't forged.

Add sensible operational pieces: a dead-letter queue or event log for deliveries that keep failing, ordering guarantees only if you truly need them (they're expensive), and a way for consumers to replay missed events. The receiver should respond fast (2xx) and process asynchronously, because holding the connection while doing work causes timeouts and more retries.

An API gateway is a single entry point in front of your services. Clients hit the gateway, and it routes each request to the right backend. It centralizes cross-cutting concerns so every service doesn't reimplement them: authentication, rate limiting, request routing, TLS termination, request and response transformation, and observability.

In a microservices setup it also does aggregation (fan out to several services and combine responses) and shields internal service topology from clients. The trade-off is it can become a bottleneck or a single point of failure, so it's run redundantly, and you keep business logic out of it to avoid turning it into a distributed monolith.

Prefer additive, backward-compatible changes: new optional fields and new endpoints don't break anyone, so most evolution needs no new version at all. Design responses to tolerate unknown fields on the client side too, so adding data is always safe. Reserve a new major version for genuinely breaking changes.

When you must break, run versions in parallel, publish a deprecation timeline with dates, add Deprecation and Sunset headers to old responses, and monitor usage so you know who's still on the old version before you retire it. The goal is to never force a flag day where every client must migrate at once.

You can't use a single database transaction across services, so you use the saga pattern: break the workflow into local transactions, one per service, and define a compensating action to undo each if a later step fails. If step three fails, you run the compensations for steps two and one to unwind, rather than rolling back a global lock.

Sagas are either choreographed (each service reacts to events) or orchestrated (a coordinator drives the steps). The consequence to accept is eventual consistency: the system is briefly inconsistent between steps, and you design for that instead of pretending you have cross-service ACID. Two-phase commit exists but is avoided at scale for its locking and availability cost.

Protocol Buffers are built for evolution if you follow the rules. Fields are identified by number, not name, so you can rename a field freely but must never reuse or change a field number. Add new fields as optional with new numbers, and old clients simply ignore what they don't know. Never remove a required field or repurpose a tag.

When you retire a field, reserve its number and name so no future change accidentally reuses them and misreads old data. These conventions are what let a producer and consumer deploy independently without a coordinated release, which is the whole reason a binary contract format is worth the tooling.

Set explicit timeouts on every outbound call so a slow dependency can't hang your service and cascade into a pileup. Retry only idempotent operations, and use exponential backoff with jitter so a wave of retries doesn't synchronize into a thundering herd that hammers a recovering service.

Wrap unreliable dependencies in a circuit breaker: after repeated failures it trips open and fails fast for a while instead of piling on a struggling service, then probes to see if it recovered. Combine that with bulkheads (isolating resource pools) so one failing dependency can't exhaust every thread. Blind infinite retries without backoff are how a small blip becomes an outage.

HATEOAS (Hypermedia As The Engine Of Application State) is the REST constraint where responses include links to the related actions and resources a client can take next, so the client discovers what's possible from the payload rather than hardcoding URLs. It's the level of REST that most APIs skip.

The honest senior take: it's theoretically elegant and helps decouple clients from URL structures, but in practice few teams implement full HATEOAS because clients usually hardcode routes anyway and the payoff rarely justifies the effort. Knowing what it is, and being able to say why most REST APIs stop short of it, is what the question checks.

Track the signals that reflect user experience: request rate, error rate, and latency percentiles (p50, p95, p99), broken down per endpoint. Averages hide pain, so watch the tail (p99) because that's where real users feel slowness. Alert on symptoms that map to user impact, like a rising 5xx rate or latency breaching an SLO, not on raw CPU.

Add distributed tracing with a correlation id propagated across services so you can follow one request through the whole call chain and find which hop was slow. Structured logs and dashboards fill in the detail. The combination lets you notice a problem with metrics, localize it with traces, and confirm it with logs.

GraphQL resolvers run per field, so a query that lists 50 users and asks for each user's posts can fire one query for the users and then 50 more for the posts, 51 queries where 2 would do. That's the N+1 problem, and it can quietly overwhelm a database as clients request nested data.

The standard fix is batching with a tool like DataLoader: it collects the individual per-item loads within a tick and issues one batched query (a single IN (...) instead of 50 lookups), and caches within the request so repeated ids aren't fetched twice. You also add query depth and complexity limits so a client can't request arbitrarily expensive nested data.

Content negotiation lets a client and server agree on the best representation of a resource. The client sends Accept headers stating what it can handle (Accept: application/json, Accept-Language: en, Accept-Encoding: gzip), and the server picks a matching format, language, or compression and responds, echoing its choice in Content-Type.

It's how one endpoint can serve JSON or XML, or compressed versus plain, based on what the caller asked for. Some APIs also use it for versioning by putting the version in a custom media type. The server should return 406 Not Acceptable if it can't satisfy the request's Accept constraints.

Design for partial failure. Isolate dependencies with timeouts and circuit breakers so a failing downstream service fails fast instead of hanging your requests. Where possible, degrade gracefully: serve a cached or default response, hide a non-essential feature, or return partial data rather than erroring the whole request when one dependency is down.

Use bulkheads to keep one struggling dependency from exhausting all your threads or connections, and shed load (return 503 with Retry-After) under overload rather than collapsing entirely. The principle is that the failure of one dependency should cause a small, contained loss of function, not a full outage.

Clarify first: who are the consumers, what's the limit per tier, and is it per-user or per-IP. Then lay out the shape: an API gateway in front handles auth (bearer tokens or API keys) and rate limiting before requests reach the services, so limits are enforced in one place. Use a token-bucket counter per key in a fast shared store like Redis so all gateway instances agree on the count.

On the response, return remaining-quota headers (X-RateLimit-Remaining, X-RateLimit-Reset) and reply 429 with Retry-After when a client is over. Version the API in the URL, return consistent JSON errors and correct status codes, paginate collections with cursors, and put observability (per-endpoint latency and error rate) on everything. The structure that scores is clarify, gateway for cross-cutting concerns, shared-store counting, correct status codes and headers, then observability.