API & Web Services
Interview Questions

An API (Application Programming Interface) is a logical contract and software intermediary that enables distinct applications or systems to communicate and exchange data. It exposes specific inputs and expected outputs while abstracting the underlying backend implementation details, database queries, and business logic.

API Testing is a QA methodology that directly verifies the functionality, security, reliability, performance, and contract compliance of application interfaces. By bypassing visual presentation layers, API testing enables early shifts-left validation of backend calculations, data storage operations, third-party integrations, and authorization checks.

Postman is an API collaboration and testing platform that simplifies the API lifecycle. It enables engineers to manually execute requests, organize them into folders and collections, manage environments, mock endpoints, and write automated validation assertions using a sandbox JavaScript environment powered by Chai and PM libraries.

APIs are classified into multiple scopes: Web APIs (network-dependent protocols like REST, SOAP, GraphQL, and gRPC), Operating System APIs (Win32, POSIX handling local resource orchestration), Database APIs (JDBC, ODBC standardizing query connectivity), and Library/Hardware APIs exposing specific code frameworks or hardware behaviors to developers.

SOAP (Simple Object Access Protocol) is a rigid, XML-only protocol that enforces precise, contract-based schemas (WSDL) and point-to-point security. REST (Representational State Transfer) is a lightweight architectural style that models resources and permits multiple formats (JSON, XML) using standard HTTP methods. SOAP provides built-in enterprise standards, whereas REST is highly decoupled and faster for public web applications.

HTTP methods represent semantic actions executed on target resources. The most common methods are: GET (retrieve data), POST (create a new resource), PUT (replace an existing resource entirely), PATCH (apply partial updates to a resource), and DELETE (remove a resource from the server).

The primary difference lies in resource mutation and idempotency. GET retrieves data without altering server state. POST creates a new resource, appending record instances on duplicate calls. PUT overwrites an existing resource entirely (or creates it if absent). DELETE completely removes the resource. Both GET, PUT, and DELETE are idempotent; POST is not.

PUT is designed for full resource replacement. If you submit a PUT request with only one field, the remaining fields of the resource are typically erased or reset to defaults. PATCH is designed for delta updates, modifying only the specific properties included in the request body while leaving other resource properties untouched.

An endpoint is the specific digital location and network address where an API receives requests and exposes its resources. It represents the combination of the base URI and the resource path (e.g., `https://api.careerraah.com/v1/jobs`), directing client requests to the correct backend controller.

An HTTP Request is an electronic message sent by a client to a server to trigger an action or retrieve resources. Its key components include the Request Line (Method, Path, HTTP Version), Request Headers (metadata like Authorization, Accept, Content-Type), Request Parameters (Query or Path parameters), and the Request Body containing the payload.

An HTTP Response is the message returned by a server to a client in response to an HTTP request. Its core components are the Status Line (containing the status code and text description), Response Headers (providing caching rules, dates, and server types), and the Response Body containing the requested data or error details.

HTTP Status Codes are standardized three-digit integers returned by servers to indicate whether a request succeeded or failed. They are categorized into five ranges: 1xx (Informational), 2xx (Success), 3xx (Redirection), 4xx (Client Errors), and 5xx (Server Errors). Common examples include 200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 403 Forbidden, and 500 Internal Server Error.

The primary difference is the source and nature of the response. 2xx codes indicate successful execution. 3xx codes represent redirects where the client must perform extra hops. 4xx codes indicate that the client made an error (e.g., bad payload, missing auth). 5xx codes show that the server crashed or encountered a runtime exception while processing a structurally valid request.

HTTP (Hypertext Transfer Protocol) transmits data between client and server in plain, unencrypted text. HTTPS (HTTP Secure) wraps standard HTTP communication in an SSL/TLS encryption layer. This prevents man-in-the-middle attacks, encrypting headers, tokens, and payloads in transit, while validating server identity through SSL certificates.

A Request Header is a key-value metadata pair sent within the HTTP request header block. It provides essential metadata to the server, detailing the client's identity, authenticating access tokens, configuring payload content formats (via `Content-Type`), declaring expected response formats (via `Accept`), and passing cookie states.

The Request Body (or payload) is the raw data content transmitted in an HTTP request to create or update server resources. Typically associated with POST, PUT, and PATCH methods, the request body is serialized in formats like JSON or XML, allowing the server to process complex, nested structures.

The Response Body is the serialized data payload returned by the server to the client upon processing an HTTP request. It represents the state of the requested resource (in GET requests) or the result of a mutation (in POST/PUT requests), primarily serialized in JSON for modern web architectures.

Query Parameters are key-value pairs appended to the end of a URL (after a `?` separator) used to control the search scope, filter outputs, sort attributes, or navigate pages of a resource catalog without altering the primary resource route.

Path Parameters are variable placeholders embedded directly inside the URL path, separated by slashes (e.g., `/users/{userId}`). They act as primary keys to identify a specific, unique instance of a resource on the server.

Path Parameters are mandatory routing segments embedded in the URL path to locate a specific, unique resource instance. Query Parameters are optional key-value pairs appended to the URL end to filter, sort, or paginate resource collections.

API testing in Postman involves composing an HTTP request by selecting the method, entering the endpoint URL, injecting headers or bodies, and clicking "Send". After receiving the response, you analyze the status codes, headers, and body payload, using Postman's JS Sandbox to write automated validation assertions.

To verify responses in Postman, you write assertions in the "Tests" tab of the request. Using the `pm.test` wrapper and `pm.expect` library, you can programmatically validate that the status code is correct, response latency meets SLAs, headers are secure, and JSON properties contain correct values.

Manual API testing involves individual request execution using graphical tools to explore endpoints and verify behaviors. Automated API testing uses scripts, frameworks (JUnit, Rest-Assured), and test runners (Newman) to execute complete sequences of calls, passing dynamic variables and running assertions without manual human interaction.

JSON (JavaScript Object Notation) is a lightweight, text-based data interchange format based on key-value pairs and ordered lists. It has become the industry standard for web service payloads because it is easily readable by humans, fast to parse by browsers and microservices, and utilizes minimal network bandwidth compared to XML.

XML (Extensible Markup Language) is a highly structured, tag-based markup language used to store and transport data. Unlike JSON, XML allows developers to define custom tags and enforces strict validation through DTD or XSD schemas. It remains the core transport format for SOAP protocols and legacy enterprise integrations.

API Authentication verifies the identity of the calling client. The main types include Basic Auth (sending credentials encoded in Base64), API Keys (unique keys validated by API gateways), Bearer Tokens/JWT (signed tokens detailing client scopes), and OAuth 2.0 (delegated authorization flows generating dynamic access and refresh tokens).

Basic Authentication is a straightforward security scheme built into the HTTP protocol. The client sends credentials formatted as `username:password`, encoded in Base64, within the `Authorization` header. In Postman, you select "Basic Auth" in the Authorization tab, enter your username and password, and Postman automatically base64-encodes the credentials.

API Key Authentication restricts access to identified clients using a static, unique string token. This key is passed either in a query parameter or inside a custom header (e.g., `x-api-key`). In Postman, you configure this in the Authorization tab under "API Key", defining the key name, key value, and whether it belongs in the header or query string.

OAuth 2.0 is an industry-standard authorization framework that enables third-party applications to obtain limited access to user resources without acquiring their login credentials. It operates by delegating user authentication to an Authorization Server, which issues a short-lived, scoped access token to the client application for access checks.

A JSON Web Token (JWT) is an open standard that defines a compact, self-contained, stateless format for transmitting securely signed claims between parties. A JWT consists of a Header (containing algorithm info), a Payload (containing dynamic claims like user ID, roles, and expiration), and a Signature verified using a shared secret or public/private key pair.

Authentication verifies client identity (e.g., logging in with credentials or tokens). Authorization checks the permissions of the verified client to ensure they are allowed to perform the requested operation. Failed authentication returns HTTP 401; failed authorization yields HTTP 403.

Handling authentication failures requires verifying that requests with missing, invalid, or expired credentials are systematically rejected with an HTTP 401 status code. Additionally, the response payload must be verified to confirm that it returns a clean error message without exposing backend stack traces.

An Environment in Postman is a key-value store of variable mappings representing deployment targets. By defining variables like `{{baseUrl}}` or `{{authClientId}}`, developers can execute the same collections across local, dev, staging, and production environments by simply switching the active configuration.

Environment Variables in Postman are scoped variables that are active only when their corresponding environment is selected. They are ideal for environment-specific variables like base URLs, database ports, dynamic login credentials, or environment-specific auth scopes.

Global Variables in Postman are workspace-wide variables accessible across all collections, requests, and environments. While useful for quick prototyping or sharing global constants (e.g., standard timezones), they represent a broad scope that should be used sparingly to prevent naming conflicts.

Collection Variables are variables scoped exclusively to a single Postman Collection, accessible by all requests in that collection regardless of the active environment. They are perfect for storing collection-wide constants, such as API versions, static schemas, headers, or test iteration limits.

Dynamic Variables are built-in generators in Postman that populate random data on the fly. Syntactically represented using double curly braces and a dollar prefix (e.g. `{{$randomEmail}}`, `{{$guid}}`), they are ideal for generating unique payloads, preventing database constraint failures during automated test runs.

A Postman Collection is created by clicking the "+" icon in the Collections tab. Best practices include organizing requests into logical folders, applying authentication at the collection root to inherit credentials automatically across all requests, and configuring collection-level scripts to run before and after every request.

A collection can be executed in three ways: manually using the "Run Collection" feature in the Postman UI (Collection Runner), headlessly using the Newman CLI (`newman run collection.json`), or on a scheduled monitor using Postman Cloud servers.

Postman Monitors execute collections on a configured schedule (e.g., hourly, daily) in the Postman cloud. They track availability, latency, and assertion states over time, alerting teams when endpoints return errors or fail performance SLAs.

A Pre-request Script is a JavaScript block executed in Postman's sandbox before the request is dispatched. Typical use cases include generating dynamic payloads, calculating cryptographic HMAC signatures, fetching dynamic access tokens, or formatting dates to inject into header variables.

A Test Script in Postman is a JavaScript block executed immediately after an HTTP response is received. It is the primary location for writing assertions to validate status codes, response times, headers, and body structures, while also extracting dynamic values for chaining.

Assertions in Postman are written in the Tests tab using the `pm.test` wrapper and Chai BDD syntax. You deserialize the response payload into a JSON object, then write descriptive assertions to evaluate its properties, lengths, and data types.

Common Postman assertions validate essential properties of the response contract, including status code structures, payload data types, expected headers (e.g., Content-Type), and SLA performance thresholds.

To extract response values, you parse the body of the response (typically using `pm.response.json()`), navigate through the keys or arrays, and assign the target value to an active environment or collection variable for reuse in subsequent requests.

Passing data between requests (API chaining) involves programmatically extracting a value from Request A's response payload, storing it in an environment variable, and referencing that variable in Request B's URL, headers, or body using the `{{variableName}}` syntax.

Postman Workspaces are collaborative areas that group collections, environments, mocks, and monitors. They allow engineering teams to collaborate in real-time, separating internal projects from public sandboxes while providing role-based access control.

You can share collections by inviting developers to your shared Postman workspace, exporting the collection as a JSON file, or generating a shareable URL link. Enterprise teams use shared workspaces to maintain a single source of truth for their test suites.

Postman supports multiple request body formats: `form-data` (for mixed key-value strings and binary file uploads), `x-www-form-urlencoded` (url-encoded forms), `raw` (for text, JSON, or XML payloads), and `binary` (for direct file streams like images or PDFs).

A Mock Server in Postman simulates live API endpoints by matching request paths against pre-configured examples, returning static mock payloads without a real backend database. This allows frontend teams to start developing and writing tests against an API specification before the backend developers write a single line of code.

API Chaining is the process of executing a dependent sequence of API requests where the response of one request (e.g., extracting an ID or session token) is captured dynamically, stored as a variable, and passed as input into subsequent requests.

Newman is the official CLI command-line runner for Postman collections. Built on Node.js, it enables headless execution of Postman suites by parsing exported collection and environment JSON files, executing requests, and generating detailed test reports.

You integrate Postman with Jenkins by using Newman. You configure a Jenkins pipeline build step to install Newman, execute the test suite via the command line, and export a JUnit XML report. Jenkins parses this report to dynamically mark the build as passed or failed.

API tests can be scheduled in the cloud using Postman Monitors on a recurring timeline. Alternatively, you can schedule headless runs on local infrastructure by configuring cron jobs in Jenkins, GitLab CI, or GitHub Actions to execute the Newman CLI.

The purpose of Newman is to act as a lightweight command-line execution engine for Postman. By bypassing the desktop GUI, Newman consumes minimal memory and system resources, making it suitable for headless execution inside Docker containers, terminal shells, and CI/CD automation pipelines.

To run Postman tests via the command line, you export your collection and environment files as JSON, install the Newman runner package via Node.js, and execute `newman run` referencing the files in your terminal.

You generate API documentation in Postman by adding descriptive notes to collections, folders, and individual requests. Once ready, you click "Publish Docs", and Postman generates a web portal that displays endpoints, request details, and copy-pasteable code snippets.

To handle and test API pagination in Postman, you extract pagination metadata (e.g. `next_page_url` or `total_pages`) from the response payload. You then use `postman.setNextRequest()` in the Tests tab to loop and call the next page until a target condition or page limit is reached.

Postman scripts are JavaScript segments that run inside Postman's sandbox. You debug them by adding `console.log()` statements to output variables and opening the Postman Console window (or terminal when running Newman) to inspect logs, variables, and network exchanges.

To test GraphQL APIs in Postman, you send an HTTP POST request to the central `/graphql` endpoint, selecting "GraphQL" as the body format. You define your query or mutation schema inside the editor, passing variables and verifying the response structures.

To test SOAP APIs in Postman, you configure an HTTP POST request, set the `Content-Type` header to `text/xml`, and paste the structured XML SOAP Envelope inside the raw request body. You then write XML-based assertions to validate the response.

RESTful APIs expose separate endpoints representing distinct resources, using standard HTTP methods and status codes. GraphQL APIs expose a single endpoint, allowing clients to submit queries that define the exact data fields they need, preventing over-fetching at the cost of caching complexity.

You create a Mock API in Postman by adding requests to a collection and saving specific responses as "Examples". You then create a Mock Server in the Postman UI, which generates a public URL to route client calls, returning the saved example payloads based on path matches.

API automation in Postman is achieved by organizing requests into structured collections, writing comprehensive JavaScript assertions in the Tests tab, using environment variables to chain data between steps, and executing the suite headlessly in CI/CD using the Newman CLI.

The Postman Runner is a built-in tool that automates the execution of a collection of requests in sequence. It allows developers to configure the run order, delay times, iteration counts, and run data-driven tests by feeding CSV or JSON data files to assert multiple test scenarios.

API security risks, as defined by the OWASP API Security Top 10, include BOLA (Broken Object Level Authorization), broken authentication, mass assignment, injection vulnerabilities, and rate limit failures. Security testing involves trying to bypass validation parameters, escalate scopes, and access unauthorized data.

CORS (Cross-Origin Resource Sharing) is a browser-enforced security mechanism that restricts web applications from requesting resources from a different origin domain than the one that served the initial page. Web APIs must explicitly return headers like `Access-Control-Allow-Origin` defining permitted client domains to enable web access.

Testing API security involves fuzzing inputs with malicious SQL/XSS payloads, manipulating JWT signature strings to check for vulnerabilities, performing BOLA checks by modifying target path IDs, and simulating rate-limit exhaustion to verify threshold controls.

CSRF (Cross-Site Request Forgery) is a vulnerability where an attacker tricks a user's browser into executing state-changing requests (like money transfers) on an active, authenticated application. APIs prevent CSRF by enforcing custom headers, using cryptographic anti-CSRF tokens, or setting authentication cookies to `SameSite=Strict`.

Rate Limiting restricts the number of API requests a client can make within a specified timeframe (e.g., 60 requests per minute). To test this, you write automated loop scripts to bombard the endpoint with requests, verifying that once the threshold is crossed, the server returns an HTTP 429 status code.

Testing access control (RBAC) involves executing every endpoint in your API using authentication tokens from different user privilege levels. You map out expected access rules (e.g., Guest can read, Admin can delete), and assert that the API rejects unauthorized operations with an HTTP 403 Forbidden.

Symmetric encryption uses a single shared secret key to encrypt and decrypt data (e.g. AES), requiring secure key distribution. Asymmetric encryption uses a public/private key pair (e.g. RSA, Elliptic Curve), where anyone can encrypt data using the public key, but only the holder of the private key can decrypt it.

Testing token expiration involves generating a token with a very short time-to-live (TTL), waiting for it to expire, and asserting that the API rejects it with an HTTP 401 status. You then verify the refresh flow, ensuring the client can use the refresh token to retrieve a new active access token.

Testing error handling ensures that when an exception occurs, the server responds with a standard HTTP error status (4xx or 5xx) and returns a clean, secure error payload. You verify that internal backend details, database schemas, and stack traces are suppressed from client responses.

Ensuring security best practices requires adopting a defense-in-depth model: enforcing HTTPS, validating all inputs against strict JSON schemas, securing APIs with OAuth2/JWT tokens, configuring secure CORS origin headers, implementing rate limiting, and running regular automated security scans.

In Postman, response time is captured automatically and is accessible in the Tests tab using `pm.response.responseTime`. You write assertions to ensure the server meets your Service Level Agreements (SLA), marking runs as failed if latency exceeds limits.

Load testing involves simulating concurrent user traffic using tools like k6, JMeter, or Gatling. You define test scenarios (ramp-up periods, steady-state load, and ramp-down phases) and execute requests, monitoring performance indicators like throughput (RPS), error rates, and CPU metrics.

Yes, Postman supports lightweight performance testing inside its desktop runner, allowing you to run collections with multiple virtual users. However, for massive, distributed load testing (simulating thousands of concurrent connections), dedicated CLI-driven engines like k6 or JMeter are recommended.

The leading tools for API load testing are k6 (modern JavaScript scripts), Apache JMeter (powerful Java GUI), Gatling (high-performance Scala/Java code-first), and Locust (Python-based). k6 is favored in modern pipelines due to its lightweight developer-first script structure and native integrations.

Testing concurrency requires using load generation engines to fire multiple requests in the exact same millisecond. This evaluates how the backend handles parallel transactions, ensuring that database locks prevent race conditions, dirty reads, or thread pool exhaustion.

You test rate limiting in Postman by writing loop scripts inside the Tests tab. By calling the request recursively using `postman.setNextRequest()`, you can fire requests in quick succession, verifying that the server returns an HTTP 429 Too Many Requests once the rate threshold is crossed.

Throughput is measured as the volume of requests the API can process per second (RPS). Latency measures the round-trip connection time. During load runs, engineers analyze these metrics using percentiles (p95, p99) rather than simple averages to identify slow requests.

Load testing evaluates API behavior under expected normal and peak traffic loads. Stress testing pushes the system past its defined limits until it breaks, verifying how the application handles resource starvation and whether it recovers gracefully once the load spike subsides.

Handling timeouts involves setting explicit limits on connection and read times in your test scripts. This ensures that slow or unresponsive endpoints fail quickly rather than hanging, allowing you to verify that the client receives a clear error response.

Analyzing API logs involves using aggregation platforms (Splunk, ELK, Datadog) to isolate transaction paths. By searching for a unique Correlation ID injected in the headers, you can trace requests as they navigate multiple microservices and databases, identifying the exact origin of failures.

To debug API failures in Postman, you open the built-in Postman Console to inspect full network exchanges (including request headers, SSL details, and payload streams). You then write `console.log()` statements inside your scripts to inspect variable states and try-catch blocks.

Common API errors are classified by HTTP status code groups. Troubeshooting involves checking the status code, verifying that the client payload matches the server's schema expectations (400), confirming access credentials (401/403), or inspecting backend logs when encountering server-side failures (500).

An HTTP 400 Bad Request error indicates that the server cannot process the request due to a client-side mistake (such as malformed JSON syntax, invalid data types, or missing mandatory attributes). Troubleshooting involves validating the request headers and checking response details to identify the invalid field.

An HTTP 401 Unauthorized error indicates that the request lack valid credentials or the client identity cannot be verified. Troubleshooting requires checking the spelling of the `Authorization` header, verifying that the token hasn't expired, and renewing the session using a refresh token flow.

An HTTP 403 Forbidden error indicates that the client's identity is authenticated, but they lack the permissions or roles required to access the target resource. Troubleshooting involves verifying token claims and checking access control matrices in the backend.

An HTTP 404 Not Found error indicates that the server cannot locate the requested resource. This can occur because the endpoint URL is misspelled, or the dynamic path parameter (like a user ID) does not exist in the database.

An HTTP 500 Internal Server Error indicates that the server encountered an unhandled exception or crash while processing the request. Troubleshooting requires inspecting the backend application server logs to locate the raw stack trace and identify the failed database query or null pointer exception.

When a request takes too long to respond, it triggers connection timeouts. The client-side connection is terminated, and intermediate load balancers or proxies (like Nginx, Cloudflare) abort the connection, returning an HTTP 504 Gateway Timeout to the client.

Testing retry mechanisms involves using mock engines (like WireMock) to simulate network failures or HTTP 503 errors. You assert that the client application retries the call according to your retry configuration, incorporating exponential backoff delays to prevent overloading the server.

Logging API test results involves using reporters (like `htmlextra` or `junit` in Newman) to generate structured files. These files are parsed by CI/CD pipelines to display status dashboards, with metrics exported to log analysis platforms for long-term tracking.

Integrating API testing into CI/CD involves configuring a pipeline build stage to execute your test runner (such as Newman or Rest-Assured) headlessly after a deployment succeeds. The pipeline evaluates the test exit code, automatically blocking the release if any assertions fail.

Using Postman in a DevOps workflow involves version-controlling your collection JSON files in your application's git repository. During automated pipeline execution, Newman pulls these collections to validate deployed endpoints, providing continuous feedback on API health.

To run API tests in Jenkins, you install Newman on your Jenkins agent, configure a pipeline build stage to pull your collections, execute the test runner via the command line, and use the JUnit plugin to parse and display the test results.

You trigger API tests as part of the build process by using pipeline orchestrators (like Jenkins, GitHub Actions, or GitLab CI). You configure the pipeline to run fast API smoke suites immediately after a build compiles, using these results to decide whether to permit the deployment to proceed.

The golden rules for API automation are: Enforce absolute autonomy by automating authentication and dynamic token refreshes, design tests to be stateless so they can run in parallel without data collision, validate structural schemas (JSON/XML) to catch contract shifts, mock external dependencies using WireMock, and integrate suites headlessly inside CI/CD gates.