Why this matters
Your device does not hold the websites you visit. Between clicking and seeing, a message went somewhere and an answer came back. That exchange has a fixed shape, and once you know it you can read what a browser's network tab is telling you.
The idea
The client asks; the server answers. Browsers and phone apps are clients. The server receives the request, does the work, and returns a response. Every web application is that loop, repeated.
HTTP is the protocol, the shared rules for the exchange. HTTPS is HTTP with
TLS encryption added, so the contents cannot be read in transit. A URL beginning
https:// is using it.
A request carries an HTTP method saying what kind of operation is wanted:
| Method | Role | Example |
|---|---|---|
| GET | Retrieve data from the server | Loading a page, fetching search results |
| POST | Send data to the server | Submitting a login, posting a form |
The response carries a status code reporting how it went:
| Code | Meaning |
|---|---|
| 200 | Success |
| 404 | Not found; that URL does not exist |
| 500 | Server error; something broke on the server side |
The families are worth noticing: 200s mean it worked, 400s mean the request was wrong (404 is the client asking for something that is not there), 500s mean the server itself failed. That distinction tells you whose problem it is.
An API is an agreed way for different software to exchange data. Inside a web application, the frontend usually talks to the backend through one rather than asking for whole pages, and what comes back is usually JSON, a format readable by both people and machines.
Picture it
sequenceDiagram participant C as Client (browser) participant S as Server C->>S: GET /products?q=shoes Note over S: look up matching products S-->>C: 200 OK, JSON list of products C->>S: POST /login (username, password) S-->>C: 200 OK, or 404 / 500 if it fails
Worked example
You submit a login form and the page reports a problem. Which part failed?
Read the status code, because it points at a different culprit each time. A 200 with an "incorrect password" message means the exchange worked perfectly; the server processed the request and its answer happens to be no. Nothing is broken. A 404 means the browser asked for an address the server does not have, so the form is posting to the wrong URL, a front-end mistake. A 500 means the server reached your request and then fell over inside its own code, so nothing about the form will fix it.
Notice also that this form must use POST, not GET. GET is for retrieving, and its parameters sit in the URL, which lands in browser history and server logs. A password does not belong in either.
Your turn
Try the practice questions for this lesson. Judge statements about clients, servers and methods, match each description to the right protocol or interface, and read a status code correctly.
Take it further
A school wants a web app where students log in, view a timetable, and download a PDF. Should it send everything over plain HTTP, or use HTTPS with the right method for each action?
- Choose the method. For loading a grade history, submitting the login form, and requesting today's schedule from another school's system, say whether GET or POST fits, and for the last whether an API is involved.
- Choose the protocol. Decide whether the login should use HTTP or HTTPS, and say why.
- Decide. Recommend the communication design and give two reasons.
A password in a GET request ends up in the URL, and therefore in browser history and server logs.
Recap
- The client requests, the server responds, and HTTP is the shared rule set.
- HTTPS is HTTP plus encryption.
- GET retrieves, POST sends. 200 is success, 404 not found, 500 a server error.
- An API lets software exchange data, usually as JSON.