Glossary

URL

A URL gives browsers, API clients and servers a shared address for a resource. Its individual parts specify the protocol, destination, path and any parameters; it also commonly appears in logs, browser history and analytics.

Short definition

The address of a resource, not the content itself or a DNS record.

A URL is a common type of URI. While a URI is a general identifier for a resource, a URL also provides a way to locate it, such as HTTPS. The address https://api.example.cz/orders?state=paid#history therefore specifies more than the server name: it also says which scheme to use for the connection, where to send the HTTP request and which context the client application should use.

A URL does not necessarily contain an IP address directly. Before a network connection is established, a hostname such as api.example.cz is usually resolved through DNS. Only then does the client connect to a specific server and send an HTTP request. DNS, a TLS certificate, a reverse proxy and an application route therefore work together, but they are not the same thing.

What it is used for

Stable addresses for pages, API resources and integration callbacks

A predictable URL is part of both the user interface and the technical contract between systems.

the address of a public page, category, product or article that can be shared and indexed
identifying an API resource and its subresources, such as /orders/123/items
filtering, paginating or sorting a read endpoint through a limited set of query parameters
a callback URL for OAuth, a webhook or a redirect after a payment process is complete
routing domains and paths through nginx or other HTTP infrastructure to the correct application

Practical example

A catalogue read endpoint without sensitive parameters

A catalogue API offers brand filtering, pagination and sorting through a clearly defined set of permitted query parameters. The path identifies the products resource, the query modifies the read view and a fragment serves no purpose here. The server-side application verifies that page is a positive integer, that sort is on an allowlist and that the client cannot pass an arbitrary database expression through the URL.

The access token in this example is not part of the URL: it is sent in the HTTP Authorization header. This makes the address safer to store in documentation and access logs and to share among developers without automatically disclosing a secret.

https://api.example.cz/products?brand=acme&page=2&sort=price_desc
\_____/   \____________/ \________________________________________/
 scheme          host                 path a query parametry

How it works

From a URL on the client to an HTTP response

A URL connects resource identification with several separate networking steps.

Parsing the URL The client separates the scheme, the authority with its host and port, the path, query and fragment. It may first resolve a relative link against the document base URL.
Resolving the hostname A DNS resolver looks up the record for the hostname and may use a cached response based on its TTL. This gives the URL a network destination, but DNS does not decide how to handle the /orders path.
Connection and TLS The https scheme tells the client to establish an encrypted HTTP connection. The certificate verifies the hostname, not query parameters or business-level permissions.
HTTP request The client sends the method, Host header, path and query to the web server. The server may route the URL to a static file, a reverse proxy or an application.
Handling the fragment The part after # is generally used by the client, for example as an anchor in a document. It is not sent in a normal HTTP request, so the server must not use it for authorization or data selection.

Parts of a URL

Each delimiter has a different meaning.

Understanding the parts of a URL prevents broken links, incorrect caching and unintended data leaks.

Scheme

https means HTTP over TLS. This is not merely cosmetic: redirects between http and https, secure cookies and the generation of absolute addresses must all account for the protocol.

Host and port

The host is a domain name or IP address, while the port identifies the network service. DNS resolves the hostname; the URL path and query are not part of a DNS record.

Path

The path typically selects a page or API resource. It should be designed to remain stable and readable, because changing it can break bookmarks, integrations and search engines.

Query and encoding

The query carries parameter pairs. Reserved characters and data outside the permitted set use percent-encoding; values should be processed with a URL encoder rather than assembled into a string by hand.

Fragment

The fragment identifies part of a document on the client side. It is not part of the request sent to the server and must not carry data that the backend needs to process securely.

Benefits and limitations

A stable address is an interface that needs to be protected.

Benefits

unambiguous sharing of links and API contracts
readable addresses make navigation, debugging and documentation easier
the path and query can describe a public read view without a custom format
a well-designed URL supports caching, redirects and traffic audits

Risks and mistakes

a password, access token or personal detail in the query can appear in history, logs, referrers or analytics
unrestricted query parameters create an unclear contract, cache fragmentation or injection vulnerabilities
changing a path without a redirect breaks existing links and integration clients
comparing URLs as plain strings can overlook encoding, parameter order or canonicalisation

Where to draw the line

A URL should contain an address and limited context, not confidential state.

A path is suitable for the stable identity of a resource, such as /products/123. A query works well for optional filters, pagination and sorting when the parameters are validated and their scope is documented. State-changing commands, large payloads and sensitive values belong in the body of an appropriate HTTP request or in secure server-side storage, not in a freely shareable link.

A URL may contain a public order identifier in an administration interface, but the identifier itself must never be the only form of authorization. The application verifies the signed-in user, tenant and permissions on the server. Different URLs for a language, store or API version must be intentional and reflected in both the cache key and documentation.

What to consider

Generate, validate and log addresses with their visibility in mind.

A clear URL design limits sensitive content and gives clients a stable, long-term contract.

use HTTPS for external addresses and generate the correct scheme behind a reverse proxy
never put passwords, API keys, personal data or long-lived tokens in the query or path
build URL parameters with a standard encoder and validate their type, range and permitted values on the server
change stable URLs through a documented migration and an appropriate HTTP redirect
distinguish public, cacheable queries from personalised content and authorized operations
mask sensitive parts of addresses in logs and monitoring, or do not collect them at all

Common questions

How to use URLs safely and clearly

Is a URL the same as DNS?

No. A URL describes the complete address of a resource, including its scheme, hostname and path. DNS handles only the hostname and its network records.

Can I put a token in a query parameter?

Not if it is long-lived or sensitive. URLs are commonly stored in history, logs, referrers and analytics. Authentication is usually passed through a header or a secure session.

Does a browser send the fragment after # to the server?

Normally it does not. The client interprets the fragment, for example to scroll to part of a document. The backend therefore cannot reliably use it for decision-making.

Is a URL always the same as a URI?

A URL is commonly understood as a type of URI that also provides a way to locate the resource. The terms are sometimes used loosely in practical web communication, but URI is the broader concept.

How I design APIs in practice

I build HTTP contracts around readable addresses, permissions and predictable behaviour.

For integration and e-commerce backends, I treat URLs, input validation, authentication and public documentation as one connected whole.

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