Glossary

HTTP

HTTP gives the client and server a shared language for requests, responses and their meaning. It does not define the domain model, database or user permissions.

Short definition

A uniform interface between clients, servers and intermediaries.

HTTP is a family of stateless request-response application protocols. The client sends a request for a specific resource, such as a product page or an order API endpoint. The server evaluates it and returns a response with a status code, headers and, where appropriate, a body such as HTML or JSON.

The fundamental meaning of methods, status codes and headers is shared by HTTP/1.1, HTTP/2 and HTTP/3. The versions differ in how messages are transported and handled concurrently, not by giving POST or 404 a different application meaning. HTTP can run over different transports; on the web, it is generally used over TLS as HTTPS.

What it is used for

From a document in a browser to an integration API

HTTP does not depend on whether the client is a person, application or automated worker.

loading a web page, CSS, JavaScript, an image or a file
calling a REST API from a frontend, mobile application or partner integration
receiving a webhook from a marketplace, carrier or payment gateway
communication between a reverse proxy, gateway and internal HTTP service
health checks, API documentation and machine-readable error responses

Practical example

Retrieving an order status through an API

An administration interface needs to display an order. It sends GET to a resource identified by the order ID and includes authentication information in a header. The API checks whether the user may read the order in the given tenant and returns a JSON representation or an appropriate error. Status 200 alone is not proof of permission; the backend made that decision.

The example deliberately uses HTTP/1.1 notation for readability. In HTTP/2 or HTTP/3, the messages may travel differently, but the meaning of the method, headers and response remains the same.

GET /api/orders/ORD-2026-42 HTTP/1.1
Host: api.example.cz
Accept: application/json
Authorization: Bearer <token>

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{"id":"ORD-2026-42","status":"paid"}

How it works

From the client's intent to an interpreted response

HTTP carries a message; its correct meaning emerges only from the combination of the method, URI, headers, body and documented contract.

The client builds a request It selects a method, target URI, headers and optional body. The method describes the intent, such as reading or creating a resource.
Network and intermediaries DNS, TLS, a reverse proxy or a cache can deliver the request onward. A proxy must not infer the business meaning of an operation from its path alone.
The server evaluates the resource The application performs authentication, authorization, validation and its own logic. HTTP does not provide these checks by itself.
The server returns a response The status code describes the result, headers carry metadata and the body returns a resource representation or error details.
The client decides what to do next Based on the code, headers and documented format, it displays the result, redirects the user, refreshes a cache or handles an error.

Main parts and concepts

The method, resource and message play separate roles.

Understanding these boundaries prevents vague API responses and stops infrastructure from taking on application rules.

Resource and representation

A URI identifies the target of communication. A response can return its HTML, JSON or another representation; the URI itself need not reveal the internal structure of tables or classes.

Methods

GET reads a representation, POST often creates or initiates an action, PUT replaces the target state, PATCH changes it in part and DELETE requests removal. The API itself must define the precise business rules.

Statelessness

Each request should be understandable on its own. A server may hold a session or database data, but the meaning of a new request should not depend on a hidden sequence of previous HTTP messages on the connection.

Safety and idempotency

A safe method should not change state; repeating an idempotent operation should have the same intended effect. This does not mean that GET cannot fail or that repeated DELETE requests must return identical responses.

HTTP versions and caching

HTTP/2 and HTTP/3 change transport properties, not application semantics. Caching is governed by specific headers and response rules; a GET request must not be assumed to be automatically safe to cache.

Benefits and limitations

A general interface enables interoperability but does not create a domain contract.

Benefits

shared rules for the web, APIs, clients and intermediaries
a clear separation of requests, responses, metadata and content
the ability to use standard tools for caching, proxies, monitoring and documentation
HTTP meaning independent of a specific programming language or framework

Limitations and common mistakes

treating an HTTP status as a complete description of a business outcome
putting sensitive data in a URL where it can appear in logs or history
using GET for a state-changing action
retrying a write after a timeout without an idempotent design
confusing a secure HTTPS connection with API authentication and authorization

When it makes sense

For public and internal interfaces that need a clear contract.

HTTP is a natural interface for the web and APIs because clients, browsers, proxies and monitoring systems understand its model. In e-commerce, the same principles can deliver a catalogue to a user, accept an order webhook or offer a partner API; the specific data model and rules differ in each case.

A different protocol or message queue may suit high-volume internal communication. Even there, HTTP is not inherently “too simple”: what matters is the need for a real-time response, contract versioning, retries, security and observability across the entire flow.

What to consider

The meaning of a request must be clear to both the client and operations.

A good HTTP interface uses standard semantics where they help and defines the rest through a specific contract.

choose a method according to the intended effect and document non-trivial actions
use an appropriate status, content type and stable error format for the response
do not send secrets or personal data in URLs or expose internal errors to the client
design timeouts and retries together with idempotency for write operations
measure statuses, latency, response size and errors at both the proxy and application

Common questions

HTTP without common misconceptions

Is HTTP the same as an API?

No. An API is an interface between programs and can use HTTP, other protocols or direct library calls. HTTP is a communication protocol.

Is HTTP stateless when an application supports sign-in?

Yes, in the sense that each request must carry the information needed to understand its meaning. The server can store a session and the request can identify it with a cookie or token.

Is POST always non-idempotent?

Not automatically. The method does not generally guarantee idempotency, but a specific API can use an idempotency key so a repeated POST has the same effect.

Does HTTP transmit a password securely?

No. Plain HTTP does not encrypt data. HTTPS, which is HTTP over TLS, is used for transport over an untrusted network.

How I work with APIs in practice

I design HTTP contracts together with integrations, security and retries.

For e-commerce and integration services, I address endpoint semantics, errors, authentication, idempotency and operational behaviour between the client and backend.

How I work with APIs and integrations Discuss your project without obligation