How HTTP and the web work

An API is how one program asks another for data or for an action, and on the web that conversation runs over HTTP. Interviewers start here because every later API question (methods, status codes, authentication, test design) assumes you can read a request and a response and name their parts. This article builds that picture from zero.

Clients, servers and APIs

An API (application programming interface) is an agreed set of requests a program accepts and the answers it gives. A web API works over HTTP (Hypertext Transfer Protocol). The program that asks is the client: a mobile app, a web page, another service or your test. The program that answers is the server.

The client never sees how the server stores its data. It relies only on the agreement: "if I send this request, I get this kind of response". That is why a tester can test an API directly, without any screen. One address and method that the API offers, such as GET /products/42, is called an endpoint, and this word is used all through the API topics.

The parts of a URL

https://shop.example.com:443/api/products/42?currency=INR&fields=name,price

• Scheme: https, meaning HTTP inside an encrypted TLS connection (TLS is the standard that scrambles the data so others cannot read it on the way). Plain http is not encrypted.
• Host: shop.example.com. DNS, the internet's address book, turns it into an IP address.
• Port: 443 is the default for HTTPS (80 for HTTP), so it is usually left out.
• Path: /api/products/42 names a resource. Here 42 is a path parameter: it picks one product.
• Query string: everything after ?, as name=value pairs joined with &. Query parameters usually filter, sort or page the results.

Special characters inside a value must be percent-encoded: a space becomes %20 (or + in a query) and & becomes %26. Test tools do this for you when you pass parameters separately.

A request and a response

A request has a method, a target, headers and sometimes a body:

POST /api/orders HTTP/1.1
Host: shop.example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...

{"productId": 42, "quantity": 2}

The response has a status code, headers and usually a body:

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/orders/9001

{"id": 9001, "productId": 42, "quantity": 2, "status": "NEW"}

Headers carry information about the message. Content-Type says what format the body is in, Accept says which formats the client wants back, and Authorization carries credentials, such as a token (a long text string that proves who you are; the authentication topic explains tokens). The status code gives the result in a short number: 2xx means success, 4xx a problem with the request, 5xx a problem on the server.

JSON in five minutes

Most APIs send JSON (JavaScript Object Notation). It has objects ({ } holding "key": value pairs), arrays ([ ]), strings in double quotes, numbers, true/false and null. Keys must be in double quotes; single quotes, comments and trailing commas are not allowed. Types matter in tests: "price": 10 and "price": "10" are different values, and a client written for one may break on the other.

Nested data is read as a path. In {"user": {"address": {"city": "Pune"}}} the city is at user.address.city, and in an array items[0] is the first element. Older enterprise services, such as SOAP services (an older API style, compared in the contracts topic), send XML instead. XML is a text format with tags like <city>Pune</city>, and you read a value from it with XPath, a path of element names such as /user/address/city.

What REST means

REST is a style for designing HTTP APIs. In tester terms:

• Resources have URLs: /orders is the collection, /orders/9001 one order.
• Standard methods act on them: GET reads, POST creates, PUT replaces, PATCH changes part, DELETE removes.
• The API is stateless: each request carries everything the server needs, including the token, so you can test each call on its own.
• Status codes and headers keep their standard meanings, so any client or tool understands them.

What happens on the way

Before the request is sent, the client looks up the IP address through DNS, opens a TCP connection (a reliable link between the two computers) and, for HTTPS, performs a TLS handshake (the first exchange that sets up the encryption) in which the server proves its identity with a certificate, a digital ID card for the website. Each step fails in its own way: "could not resolve host" is DNS, "connection refused" means nothing listens on that port, and a certificate error is a TLS problem, not a bug in the API logic.

How to answer in an interview

For "What is an API?", give the one-line definition, then walk through one call: "The app sends GET /products/42 with an Accept header, and the server answers 200 OK with the product as JSON." For "Why test APIs?", name speed and stability, then one bug only an API test finds, such as the server accepting a quantity of 0 that the order form blocks. Short, concrete answers beat long lists.

Common mistakes

• Mixing up path and query parameters: the path picks the resource, the query filters it.
• Swapping Content-Type and Accept: the first describes the body you send, the second asks for a format back.
• Accepting JSON with single quotes or a trailing comma as valid.
• Believing HTTPS makes secrets in URLs safe: URLs still end up in server logs.

Recap

A client sends a request (method, URL, headers, optional body), and the server returns a response (status code, headers, usually a JSON body). REST APIs name resources with URLs, act on them with standard methods, and treat each request on its own. The next topic covers the methods and their rules.