Web and internet jargon decoded: from IP address to API

When a developer says, “the API is returning a 500 because the CDN cache is stale”, it can sound like a foreign language. In fact, it describes an everyday journey that your request takes in a fraction of a second. If you know the stages of that journey, most web jargon becomes easy to place.

This article walks through what happens when you open a web page, naming each part, and then collects the terms you will meet most often.

The journey of one web page

1. 01You type an address, such as example.com, into a browser. The browser is the client: the program that asks for things on your behalf.
2. 02The browser needs to know where that name lives. It asks a DNS service, the internet’s phone book, which replies with an IP address, a number that identifies a computer on the network.
3. 03The browser connects to that computer, called a server, over a secure channel. The padlock in the address bar signals that the connection is encrypted with HTTPS.
4. 04It sends a request: “please give me the home page”.
5. 05The server may ask a database for information, and a program to put the page together.
6. 06It sends back a response containing the page, its images and its code. A CDN, a network of nearby copies, may serve the heavy files from a place close to you.
7. 07The browser assembles everything, and draws the page.

Addresses and names

• IP address. The numeric address of a device on the network, like a street number.
• Domain name. The human-friendly name, such as example.com, that points to an IP address.
• DNS (domain name system). The service that translates names into IP addresses.
• URL. The full address of a page or file, including the protocol and the path, such as https://example.com/about.
• Hosting. Renting space on a server where your website’s files live.
• SSL or TLS certificate. A digital document that proves a site is who it says it is and enables encryption.

The conversation

• Client and server. The client asks. The server answers. A phone app, a browser or another program can be the client.
• HTTP and HTTPS. The rules for the conversation. HTTPS is the secure version, which scrambles the data in transit.
• Request and response. One question and its answer.
• Status codes. Short numbers in the reply. 200 means success, 404 means “not found”, and 500 means the server failed.
• Cookie. A small note that a site stores in your browser, to remember you between visits.
• Session. The period during which the site recognises you as the same visitor.
• Latency. The delay before a response begins. Bandwidth is how much data can flow at once. A road can be long (latency) or narrow (bandwidth).

The two halves of a website

• Front end. What you see and touch in the browser: layout, buttons, animations. It is built with HTML for structure, CSS for style and JavaScript for behaviour.
• Back end. What runs on the server out of sight: logic, logins, calculations and talking to databases.
• Database. Where information is stored in an organised way, such as users and orders.
• Framework. A ready-made toolkit that gives developers a standard way to build, so they do not start from scratch.
• Content management system (CMS). A tool that lets non-developers edit pages and posts.
• Responsive design. A layout that adapts to phones, tablets and desktops.

APIs and the language of integration

An API, or application programming interface, is a menu that a program offers to other programs. It lists what you can ask for, how to ask and what shape the answer will take. A weather service’s API lets your app ask, “what is the forecast for this place?”, and receive an answer, with no human involved.

• Endpoint. One address on an API that does one thing, such as “get forecast”.
• REST. A common style of API that uses simple web addresses and standard verbs, such as GET to read and POST to create.
• JSON. A lightweight text format for sending data, using named fields. Programs love it.
• API key. A secret code that identifies who is calling, so the provider can control and charge for use.
• Rate limit. A cap on how many requests you can make in a period.
• Webhook. The reverse of a request. Instead of you asking repeatedly, the service calls you when something happens.
• SDK. A software development kit: ready-made code that makes using an API easier.

Speed, scale and reliability

• Caching. Keeping a copy of something that is asked for often, so it can be served quickly.
• CDN (content delivery network). A worldwide web of servers that hold copies of your files near your visitors.
• Load balancer. A traffic controller that spreads requests across several servers.
• Uptime. The share of time a service is available. “99.9 percent” allows about 9 hours of downtime a year.
• Scalability. How well a system copes when many more people use it.
• Downtime and outage. When a service is not available.
• SLA (service level agreement). A written promise about availability or response time, with consequences if missed.

Jargon that hides simple ideas

• “Serverless” still uses servers. It means you do not manage them.
• “Headless” means the content is separate from how it is displayed, so it can feed a website, an app and more.
• “Real time” rarely means instant. It means fast enough for the purpose.
• “Scalable” is only a promise until it is tested.
• “Web 3”, “the metaverse” and similar labels are marketing terms with changing meanings. Ask what is concretely being built.

Questions that cut through the buzz

• Where will it run, and who looks after it?
• What happens if it goes down, and how fast will it recover?
• Which other systems does it talk to, and through what APIs?
• What will it cost to run each month at our expected use?
• Who owns the domain, the hosting account and the code?

Frequently asked questions

What is the difference between the internet and the web?

The internet is the global network of connected computers. The web is one service that runs on it, made of pages and links. Email and video calls use the internet but are not the web.

What is a 404?

A status code meaning the server could not find what was requested, usually because the page moved or the address is wrong.

Why do websites slow down?

Common causes are large images, slow servers, too many scripts, distance from the server and heavy use. A CDN and good optimisation help.

Is HTTPS enough for security?

It protects data in transit. It does not make a site safe on its own. Passwords, updates and careful programming matter too.

You do not need to build websites to understand them. Hold on to the picture of a client asking and a server answering, with helpers along the way, and most web jargon falls into place.