Stage 1. HTTP Methods: GET, POST, PUT, DELETE
When a beginner sees an API for the first time, it may look like a random set of URLs. In reality, API communication follows a protocol. A protocol is simply a set of shared rules. The browser, mobile app, and server can work together only because they all understand the same rules.
In web development, the base protocol is HTTP. HTTP defines how a client sends a request and how a server sends a response back. The client can be a browser tab, a mobile app, or another backend service. The server receives the request, runs business logic, and returns a result.
HTTPS is the secure version of HTTP. The “S” means TLS encryption is used. With plain HTTP, traffic can be read or changed by someone in the middle of the network. With HTTPS, request and response data are encrypted in transit. For real products, login and personal data must go through HTTPS.
A request usually contains three beginner-level parts:
- method (
GET,POST,PUT,DELETE) - path (for example,
/tasks) - optional body (data sent to the server)
The response usually contains:
- status code (
200,201,404, and so on) - optional response body
Now the key idea: HTTP method shows the intent of the operation.
| Method | Simple meaning | Typical beginner use |
|---|---|---|
GET | Read data | Load a page or list of items |
POST | Create data | Add a new item |
PUT | Replace existing data | Update an existing item fully |
DELETE | Remove data | Delete an existing item |
To make this practical, use one realistic scenario: a simple task list app.
A user opens the app and wants to see all tasks. The client sends GET /tasks. The server returns the current list. This operation should only read data, not change it.
Then the user creates a new task: “Buy milk”. The client sends POST /tasks with data in the body, for example task text. The server creates a new task record and returns the created task.
Later the user edits a task. The app already knows task id 7, so it sends PUT /tasks/7 with a new full state, for example updated text and completed flag. The server replaces the current stored state for this task.
Finally, the user removes a task and the app sends DELETE /tasks/7. The server deletes it and confirms success.
One frequent beginner mistake is using POST for everything. At first it works, but soon the API becomes hard to understand: every route looks like “do something”, and clients cannot predict behavior from protocol semantics.
Another mistake is changing data through GET. For example, if GET /tasks/7/complete marks a task as completed, then page refreshes, prefetching, or retries can trigger accidental state changes. GET should stay read-only.
You do not need advanced patterns at this stage. For now, remember a safe baseline:
- Need to read data: use
GET. - Need to create a new record: use
POST. - Need to replace an existing record by known id: use
PUT. - Need to remove a record: use
DELETE.
If this mapping is consistent, your API is easier to read, easier to debug, and safer for beginners to extend. The main win is not “academic correctness”. The main win is predictable behavior for both developer and user.